Re: SECURITY PROBLEM: Any user can crash the kernel with TCP ZEROCOPY

["zhangpeng (AS)" <zhangpeng362@huawei.com>]

On 2024/1/23 1:39, Eric Dumazet wrote:

> On Mon, Jan 22, 2024 at 6:12 PM Matthew Wilcox<willy@infradead.org>  wrote:
>> On Mon, Jan 22, 2024 at 05:30:18PM +0100, Eric Dumazet wrote:
>>> On Mon, Jan 22, 2024 at 5:04 PM Matthew Wilcox<willy@infradead.org>  wrote:
>>>> I'm disappointed to have no reaction from netdev so far.  Let's see if a
>>>> more exciting subject line evinces some interest.
>>> Hmm, perhaps some of us were enjoying their weekend ?
>> I am all in favour of people taking time off!  However the report came
>> in on Friday at 9am UTC so it had been more than a work day for anyone
>> anywhere in the world without response.
>>
>>> I don't really know what changed recently, all I know is that TCP zero
>>> copy is for real network traffic.
>>>
>>> Real trafic uses order-0 pages, 4K at a time.
>>>
>>> If can_map_frag() needs to add another safety check, let's add it.
>> So it's your opinion that people don't actually use sendfile() from
>> a local file, and we can make this fail to zerocopy?
> Certainly we do not do that at Google.
> I am not sure if anybody else would have used this.
>
>
>
>   That's good
>> because I had a slew of questions about what expectations we had around
>> cache coherency between pages mapped this way and write()/mmap() of
>> the original file.  If we can just disallow this, we don't need to
>> have a discussion about it.
>>
>>> syzbot is usually quite good at bisections, was a bug origin found ?
>> I have the impression that Huawei run syzkaller themselves without
>> syzbot.  I suspect this bug has been there for a good long time.
>> Wonder why nobody's found it before; it doesn't seem complicated for a
>> fuzzer to stumble into.
> I is strange syzbot (The Google fuzzer) have not found this yet, I
> suspect it might be caused
> by a recent change somewhere ?
>
> A repro would definitely help, I could start a bisection.

By using git-bisect, the patch that introduces this issue is 05255b823a617
("tcp: add TCP_ZEROCOPY_RECEIVE support for zerocopy receive."). v4.18-rc1.

Currently, there are no other repro or c reproduction programs can reproduce
the issue. The syz log used to reproduce the issue is as follows:

r3 = socket$inet_tcp(0x2, 0x1, 0x0)
mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
r4 = socket$inet_tcp(0x2, 0x1, 0x0)
bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
0x181e42, 0x0)
fallocate(r5, 0x0, 0x0, 0x85b8818)
sendfile(r4, r5, 0x0, 0x3000)
getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
&(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x10)
r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00',
0x181e42, 0x0)

-- 
Best Regards,
Peng