Re: [PATCH net] net/iucv: fix use-after-free of a severed iucv_path

On 24.07.26 11:33, Bryam Vargas wrote:

Alexandra,

quoted

After iucv_sever_path it should not be possible to call
iucv_process_message_q() anymore.

For the close path, yes -- iucv_sock_close() ends at IUCV_CLOSED/SOCK_ZAPPED
and recvmsg() is out, so message_q just leaks. The peer-sever path is
different: iucv_callback_connrej() severs and then sets IUCV_DISCONN, leaving
the socket open. recvmsg()'s early return needs message_q.list empty; with a
saved entry it falls through, and if a datagram is still on sk_receive_queue it
reaches iucv_process_message_q() and hands the freed path to message_receive()
-- pathid is the read.

Thank you very much for the explanation. I overlooked that one. I think this
was a design bug in f0703c80e515 ("[AF_IUCV]: postpone receival of iucv-packets").
It doesn't make sense to check the message_q if IUCV_DISCONN.
I'm taking notes for future cleanups.

[...]

I'll fold the reachability point into the receive-path locking rework and send
that RFC to netdev and linux-s390, as you asked.

Looking forward to that, thank you.

Thanks,
Bryam