[BUG] tipc: deleting an unacked group member leaves sender asleep

Hello,

A blocking TIPC group broadcast sender can remain asleep after the last outstanding member ACK is cleared by deleting that member. A new nonblocking send succeeds after the deletion, so group congestion has cleared, but the original blocking send is never woken.

In tipc_group_delete_member(), deleting a member that still owes a broadcast ACK decrements grp->bc_ackers to zero but does not open the group or request a writer wakeup. The ordinary final-ACK path updates the open state and wakes the socket. The PoC demonstrates the missed wakeup with a local receiver and a remote receiver whose GRP_ACK_MSG is dropped; after the remote node powers off, the original sender stays blocked while a fresh probe reaches the local receiver.

HEAD commit:    24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
source version: Linux 7.3.0-rc7
architecture:   x86-64
compiler:       gcc 11.4.0, GNU ld 2.38
QEMU:           6.2.0, two fresh 2-vCPU guests

console output: https://gist.githubusercontent.com/shaos26/370a79297e3334c58f8cb4be22b85a9c/raw/ab80f84de2b7dd0fc96f4cd95cf470951651cbe6/console-output.txt
kernel config: https://gist.githubusercontent.com/shaos26/370a79297e3334c58f8cb4be22b85a9c/raw/8a2ecf2e6af5db6c04703b2db8fb720d73cf586b/kernel-config.txt
reproducer: https://gist.githubusercontent.com/shaos26/370a79297e3334c58f8cb4be22b85a9c/raw/78e655795b3dd1aeffcc8d9d8cc3b482e25b2a97/poc.c
guest init: https://gist.githubusercontent.com/shaos26/370a79297e3334c58f8cb4be22b85a9c/raw/b753c09f565eb4fe17900df2e092f400d69169d9/guest-init.sh
host QEMU runner: https://gist.githubusercontent.com/shaos26/370a79297e3334c58f8cb4be22b85a9c/raw/8d3330b63e982be12b430c17554f7c051060f809/run_qemu_pair.c
QEMU 6.2 shim: https://gist.githubusercontent.com/shaos26/370a79297e3334c58f8cb4be22b85a9c/raw/3881f660adefc2b8f8e2fb93f6168a449d102c20/qemu_sockopt_shim.c
reproduction guide: https://gist.githubusercontent.com/shaos26/370a79297e3334c58f8cb4be22b85a9c/raw/8b588810ff864a00573269715498cd725ebe6adf/reproduction.md
sender initramfs (base64): https://gist.githubusercontent.com/shaos26/370a79297e3334c58f8cb4be22b85a9c/raw/initramfs-sender-v16.cpio.gz.b64
receiver initramfs (base64): https://gist.githubusercontent.com/shaos26/370a79297e3334c58f8cb4be22b85a9c/raw/initramfs-receiver-v16.cpio.gz.b64

Build the tested kernel and host helpers using the reproduction guide, then decode the supplied sender/receiver initramfs images. They contain the guest init script and the compiled PoC; the guide verifies both image hashes. The runner expects the kernel at build-tipc2/arch/x86/boot/bzImage. Each guest also needs BusyBox, ifconfig/route/ping and tipc from iproute2, and iptables-legacy with its runtime libraries. The runner starts both QEMU guests on a socketpair-backed virtio network and supports the positive run plus ACK-delivery and peer-stays-alive controls:

    ./run_qemu_pair
    ./run_qemu_pair control
    ./run_qemu_pair stay

The positive QEMU run twice showed the original child still blocked after node loss, a nonblocking send returning 5, delivery to the local receiver, and RESULT=TIPC_DELETE_ACK_MISSED_WAKE_OBSERVED. The ACK-delivery control completed the blocking send; the peer-stays-alive control kept both the old sender and new probe blocked. This demonstrates a missed wakeup for a sender under the stated ACK-loss/member-removal condition, not a kernel-wide denial of service or a privilege escalation. The affected path appears unchanged in upstream master f47d223627f8; runtime validation was on v7.3-rc7.

Thanks,

shaos