In the Linux kernel, the following vulnerability has been resolved:
net: phonet: do not BUGON() in pnsocket_autobind() on failed bind
syzbot reported a kernel BUG triggered from pnsocketsendmsg() via pnsocketautobind():
kernel BUG at net/phonet/socket.c:213! RIP: 0010:pnsocketautobind net/phonet/socket.c:213 [inline] RIP: 0010:pnsocketsendmsg+0x240/0x250 net/phonet/socket.c:421 Call Trace: socksendmsgnosec+0x112/0x150 net/socket.c:797 __sock_sendmsg net/socket.c:812 [inline] _syssendto+0x402/0x590 net/socket.c:2280 ...
pnsocketautobind() calls pnsocketbind() with port 0 and, on -EINVAL, assumes the socket was already bound and asserts that the port is non-zero:
err = pnsocketbind(sock, ..., sizeof(struct sockaddrpn)); if (err != -EINVAL) return err; BUGON(!pnport(pnsk(sock->sk)->sobject)); return 0; /* socket was already bound */
However pnsocketbind() also returns -EINVAL when sk->skstate is not TCPCLOSE, even when the socket has never been bound and pnport() is still 0. In that case the BUGON() fires and panics the kernel from a user-triggerable path.
Treat the "bind returned -EINVAL but pnport() is still 0" case as a regular error and propagate -EINVAL to the caller instead of crashing. Existing callers already translate a non-zero return from pnsocket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here only changes behaviour from panic to a normal errno.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53292.json",
"cna_assigner": "Linux"
}