Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)

From: Shoaib Rao
Date: Thu Sep 05 2024 - 16:41:53 EST



On 9/5/2024 1:37 PM, Shoaib Rao wrote:

On 9/5/2024 1:15 PM, Shoaib Rao wrote:

On 9/5/2024 12:46 PM, Kuniyuki Iwashima wrote:
From: Shoaib Rao <rao.shoaib@xxxxxxxxxx>
Date: Thu, 5 Sep 2024 00:35:35 -0700
Hi All,

I am not able to reproduce the issue. I have run the C program at least
100 times in a loop. In the I do get an EFAULT, not sure if that is
intentional or not but no panic. Should I be doing something
differently? The kernel version I am using is
v6.11-rc6-70-gc763c4339688. Later I can try with the exact version.
The -EFAULT is the bug meaning that we were trying to read an consumed skb.

But the first bug is in recvfrom() that shouldn't be able to read OOB skb
without MSG_OOB, which doesn't clear unix_sk(sk)->oob_skb, and later
something bad happens.

   socketpair(AF_UNIX, SOCK_STREAM, 0, [3, 4]) = 0
   sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\333", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_DONTWAIT) = 1
   recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_controllen=0, msg_flags=MSG_OOB}, MSG_OOB|MSG_WAITFORONE) = 1
   sendmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\21", iov_len=1}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_OOB|MSG_NOSIGNAL|MSG_MORE) = 1
recvfrom(3, "\21", 125, MSG_DONTROUTE|MSG_TRUNC|MSG_DONTWAIT, NULL, NULL) = 1
   recvmsg(3, {msg_namelen=0}, MSG_OOB|MSG_ERRQUEUE) = -1 EFAULT (Bad address)

I posted a fix officially:
https://urldefense.com/v3/__https://lore.kernel.org/netdev/20240905193240.17565-5-kuniyu@xxxxxxxxxx/__;!!ACWV5N9M2RV99hQ!IJeFvLdaXIRN2ABsMFVaKOEjI3oZb2kUr6ld6ZRJCPAVum4vuyyYwUP6_5ZH9mGZiJDn6vrbxBAOqYI$

Thanks that is great. Isn't EFAULT,  normally indicative of an issue with the user provided address of the buffer, not the kernel buffer.

Shoaib

Can you provide the full test case that you used to reproduce the issue.

Thanks,

Shoaib


From the recvmsg man page


Return Value

These calls return the number of bytes received, or -1 if an error occurred. The return value will be 0 when the peer has performed an orderly shutdown.

*EFAULT*

The receive buffer*pointer*(s) point outside the process's address space.

I still do not understand why if I had all the check on and the issue occured, why the kernel did not panic. Maybe, running the exact test case will help me understand.

Shoaib