From: Kuniyuki Iwashima <kuniyu@amazon.com>
To: <rao.shoaib@oracle.com>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<kuniyu@amazon.com>, <linux-kernel@vger.kernel.org>,
<netdev@vger.kernel.org>, <pabeni@redhat.com>,
<syzbot+8811381d455e3e9ec788@syzkaller.appspotmail.com>,
<syzkaller-bugs@googlegroups.com>
Subject: Re: [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2)
Date: Mon, 9 Sep 2024 17:48:29 -0700 [thread overview]
Message-ID: <20240910004829.38680-1-kuniyu@amazon.com> (raw)
In-Reply-To: <2dd7aea9-93a1-4fbb-91a8-b7f3acd02a60@oracle.com>
From: Shoaib Rao <rao.shoaib@oracle.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.
next prev parent reply other threads:[~2024-09-10 0:48 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 15:13 [syzbot] [net?] KASAN: slab-use-after-free Read in unix_stream_read_actor (2) syzbot
2024-09-04 15:32 ` Eric Dumazet
2024-09-04 17:32 ` Shoaib Rao
2024-09-05 7:35 ` Shoaib Rao
2024-09-05 8:04 ` Eric Dumazet
2024-09-05 19:06 ` Shoaib Rao
2024-09-05 19:46 ` Kuniyuki Iwashima
2024-09-05 20:15 ` Shoaib Rao
2024-09-05 20:35 ` Kuniyuki Iwashima
2024-09-05 20:48 ` Shoaib Rao
2024-09-05 21:03 ` Kuniyuki Iwashima
2024-09-06 12:37 ` Eric Dumazet
2024-09-06 16:48 ` Shoaib Rao
2024-09-07 5:06 ` Shoaib Rao
2024-09-07 5:39 ` Kuniyuki Iwashima
2024-09-10 0:29 ` Shoaib Rao
2024-09-10 0:48 ` Kuniyuki Iwashima [this message]
2024-09-10 16:55 ` Shoaib Rao
2024-09-10 17:57 ` Kuniyuki Iwashima
2024-09-10 18:16 ` Shoaib Rao
2024-09-10 18:33 ` Kuniyuki Iwashima
2024-09-10 18:49 ` Shoaib Rao
2024-09-10 19:49 ` Kuniyuki Iwashima
2024-09-10 20:57 ` Shoaib Rao
2024-09-10 21:53 ` Kuniyuki Iwashima
2024-09-10 22:30 ` Shoaib Rao
2024-09-10 22:59 ` Kuniyuki Iwashima
2024-09-10 23:42 ` Shoaib Rao
2024-09-11 0:16 ` Kuniyuki Iwashima
2024-09-05 20:37 ` Shoaib Rao
2024-09-05 20:41 ` Shoaib Rao
2024-09-05 20:42 ` Kuniyuki Iwashima
2024-09-05 5:25 ` Lizhi Xu
2024-09-05 5:57 ` syzbot
2024-09-05 6:59 ` Kuniyuki Iwashima
2024-09-05 7:46 ` syzbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240910004829.38680-1-kuniyu@amazon.com \
--to=kuniyu@amazon.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rao.shoaib@oracle.com \
--cc=syzbot+8811381d455e3e9ec788@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).