netdev - 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: <20240910004829.38680-1-kuniyu@amazon.com>
Date: Mon, 9 Sep 2024 17:48:29 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <rao.shoaib@...cle.com>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<kuniyu@...zon.com>, <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)

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://lore.kernel.org/netdev/172592764315.3964840.16480083161244716649.git-patchwork-notify@kernel.org/


> 
> 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<---


> 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.