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>