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] [day] [month] [year] [list]
Date:   Sat, 29 Apr 2023 14:47:58 -0700
From:   syzbot <>
Subject: Re: [syzbot] WARNING in ext4_dirty_folio

> #syz set subsystems: mm

Your commands are accepted, but please keep mailing list in CC next time. It serves as a history of what happened with each bug report. Thank you.

> On Wed, Jun 08, 2022 at 04:36:20AM -0700, syzbot wrote:
>> syzbot has found a reproducer for the following issue on:
>> HEAD commit:    cf67838c4422 selftests net: fix bpf build error
>> git tree:       net
>> console+strace:
>> kernel config:
>> dashboard link:
>> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
>> syz repro:
>> C reproducer:
> The root cause of this failure is a fundamental bug / design flaw in
> get_user_pages and related functions, which file system developers
> have been complaining about for literally **years**.  See the recent
> discussion at [1] and going back earlier to 2018[2][3] and 2019[4].
> [1]
> [2]
> [3]
> [4]
> I'm going to reassign this to the mm subsystem, since there's not much
> we can do on the file system end.  The WARNING is considered a good
> thing because users can see silent data corruption/loss if they use
> process_vm_writev() or RDMA to write to memory backed by a file.  And
> while most users at large hyperscale scientific compute farms probably
> won't be paying attention to the system logs, at least we've done
> something to warn them.
> Fortunately data corruption is rare (but when it happens it could
> really screw with your results!), but if they are doing some large
> scale simulation to evaluate the safety of nuclear weapons (for
> example), it would be nice if they got at least some hint.
> There is a potential solution discussed at [1], but there is push back
> since it could break users by disallowing the thing that might cause
> data corruption.  Why breaking user applications is bad, turning a
> possible silent data corruption to a very visible, hard failure is
> arguably a good thing....
> 						- Ted

Powered by blists - more mailing lists