PT-2026-52931 · Undefined · Undefined
Published
2026-06-26
·
Updated
2026-06-26
·
CVE-2026-53292
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
net: phonet: do not BUG ON() in pn socket autobind() on failed bind
syzbot reported a kernel BUG triggered from pn socket sendmsg() via
pn socket autobind():
kernel BUG at net/phonet/socket.c:213!
RIP: 0010:pn socket autobind net/phonet/socket.c:213 [inline]
RIP: 0010:pn socket sendmsg+0x240/0x250 net/phonet/socket.c:421
Call Trace:
sock sendmsg nosec+0x112/0x150 net/socket.c:797
sock sendmsg net/socket.c:812 [inline]
sys sendto+0x402/0x590 net/socket.c:2280
...
pn socket autobind() calls pn socket bind() with port 0 and, on
-EINVAL, assumes the socket was already bound and asserts that the
port is non-zero:
err = pn socket bind(sock, ..., sizeof(struct sockaddr pn));
if (err != -EINVAL)
return err;
BUG ON(!pn port(pn sk(sock->sk)->sobject));
return 0; /* socket was already bound */
However pn socket bind() also returns -EINVAL when sk->sk state is not
TCP CLOSE, even when the socket has never been bound and pn port() is
still 0. In that case the BUG ON() fires and panics the kernel from a
user-triggerable path.
Treat the "bind returned -EINVAL but pn port() 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
pn socket autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here
only changes behaviour from panic to a normal errno.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Undefined