linux-kernel - Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <943f2045-a89e-4d00-958d-e27c22918820@oracle.com>
Date: Tue, 10 Sep 2024 09:55:03 -0700
From: Shoaib Rao <rao.shoaib@...cle.com>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        pabeni@...hat.com,
        syzbot+8811381d455e3e9ec788@...kaller.appspotmail.com,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [net?] KASAN: slab-use-after-free Read in
 unix_stream_read_actor (2)



On 9/9/2024 5:48 PM, Kuniyuki Iwashima wrote:
> From: Shoaib Rao <rao.shoaib@...cle.com>
> 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@kernel.org/__;!!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.
>