linux-kernel - Re: [PATCH] fs/aio: fix uaf in sys_io

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 for Android: free password hash cracker in your pocket

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

Message-ID: <5ee4df86-458f-4544-85db-81dc82c2df4c@acm.org>
Date: Mon, 4 Mar 2024 09:40:35 -0800
From: Bart Van Assche <bvanassche@....org>
To: Benjamin LaHaise <ben@...munityfibre.ca>
Cc: Edward Adam Davis <eadavis@...com>,
 syzbot+b91eb2ed18f599dd3c31@...kaller.appspotmail.com, brauner@...nel.org,
 jack@...e.cz, linux-aio@...ck.org, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
 viro@...iv.linux.org.uk
Subject: Re: [PATCH] fs/aio: fix uaf in sys_io_cancel

On 3/4/24 09:31, Benjamin LaHaise wrote:
> A revert is justified when a series of patches is buggy and had
> insufficient review prior to merging.

That's not how Linux kernel development works. If a bug can get fixed
easily, a fix is preferred instead of reverting + reapplying a patch.

> Using the "a kernel warning hit" approach for work on cancellation is
> very much a sign that the patches were half baked.
Is there perhaps a misunderstanding? My patches fix a kernel warning and
did not introduce any new WARN*() statements.

> Why are you touching the kiocb after ownership has already been
> passed on to another entity?
Touching the kiocb after ownership has been passed is the result of an
oversight. Whether or not kiocb->ki_cancel() transfers ownership depends
on the I/O type. The use-after-free was not introduced on purpose.

Bart.