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

[Shoaib Rao]

On 9/9/2024 5:48 PM, Kuniyuki Iwashima wrote:
> From: Shoaib Rao <rao.shoaib@xxxxxxxxxx>
> Date: Mon, 9 Sep 2024 17:29:04 -0700
> > I have some more time investigating the issue. The sequence of packet
> > arrival and consumption definitely points to an issue with OOB handling
> > and I will be submitting a patch for that.
>
> It seems a bit late.
> My patches were applied few minutes before this mail was sent.
> https://urldefense.com/v3/__https://lore.kernel.org/netdev/172592764315.3964840.16480083161244716649.git-patchwork-notify@xxxxxxxxxx/__;!!ACWV5N9M2RV99hQ!M806VrqNEGFgGXEoWG85msKAdFPXup7RzHy9Kt4q_HOfpPWsjNHn75KyFK3a3jWvOb9EEQuFGOjpqgk$

That is a subpar fix. I am not sure why the maintainers accepted the fix 
when it was clear that I was still looking into the issue. Plus the 
claim that it fixes the panic is absolutely wrong.
> > kasan does not report any issue because there are none. While the
> > handling is incorrect, at no point freed memory is accessed. EFAULT
> > error code is returned from __skb_datagram_iter()
> >
> > /* This is not really a user copy fault, but rather someone
> >
> >    * gave us a bogus length on the skb.  We should probably
> >
> >    * print a warning here as it may indicate a kernel bug.
> >
> >    */
> >
> >
> > fault:
> >
> >       iov_iter_revert(to, offset - start_off);
> >
> >       return -EFAULT;
> >
> > As the comment says, the issue is that the skb in question has a bogus
> > length. Due to the bug in handling, the OOB byte has already been read
> > as a regular byte, but oob pointer is not cleared, So when a read with
> > OOB flag is issued, the code calls __skb_datagram_iter with the skb
> > pointer which has a length of zero. The code detects it and returns the
> > error. Any doubts can be verified by checking the refcnt on the skb.
> >
> > My conclusion is that the bug report by syzbot is not caused by the
> > mishandling of OOB,
>
> It _is_ caused by mishandling of OOB as you wrote in your patch.
>
>    ---8<---
>    Send OOB
>    Read OOB
>    Send OOB
>    Read (Without OOB flag)
>
>    The last read returns the OOB byte, which is incorrect.
>    ---8<---

I never said that the panic was caused by the mishandling of the OOB. I 
specifically said it was NOT caused by the mishandling of the OOB.

I don't have time to argue about the fix. I am just disappointed that 
the maintainers accepted a patch that was still being discussed and is 
not the best fix.

Shoaib

> > unless there was code added to disregard the skb
> > length and read a byte.
> >
> > The error being returned is confusing. The callers should not pass this
> > error to the application. They should process the error.