Thread (3 messages) 3 messages, 3 authors, 2026-05-23

Re: [PATCH net] net/iucv: fix locking in .getsockopt

flat view

From: Alexandra Winter <wintera@linux.ibm.com>
Date: 2026-05-22 13:37:09
Also in: linux-s390, lkml


On 21.05.26 16:11, Breno Leitao wrote:
Mirror iucv_sock_setsockopt() and wrap the whole switch in
lock_sock()/release_sock(). The pre-existing SO_MSGLIMIT-only lock
becomes redundant and is removed.

Any AF_IUCV HIPER user can potentially crash the kernel by racing
recvmsg() with getsockopt(SO_MSGSIZE): the SO_MSGSIZE arm dereferences
iucv->hs_dev->mtu after iucv_sock_close() (called from the racing
recvmsg()) has set hs_dev to NULL, producing a NULL pointer dereference
oops.

Suggested-by: Stanislav Fomichev <redacted>
Fixes: 51363b8751a6 ("af_iucv: allow retrieval of maximum message size")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Note1: Not using goto/label to simplify the merge conflict that might
happen with the migration of af_iucv to getsockopt_iter

Note2: This was only compile-tested.
---
Thank you very much Breno.

I ran some regression tests which call IUCV getsockopt(SO_MSGSIZE) while
sending and receiving data via IUCV. I have not created a specific
reproducer testcase of the described race, which would require enforcing
a problem in IUCV over HS congestion management which triggers an error
path in recvmsg().

Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Tested-by: Alexandra Winter <wintera@linux.ibm.com>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help