Re: [PATCH v4] loop: Fix NULL pointer dereference in lo_rw_aio()

[Hillf Danton]

On Mon, 13 Jul 2026 20:02:52 +0900 Tetsuo Handa wrote:
>On 2026/07/13 12:04, Hillf Danton wrote:
>> On Tue, 9 Jun 2026 18:50:13 +0100 Al Viro wrote:
>>> On Sun, Jun 07, 2026 at 07:54:58PM +0900, Tetsuo Handa wrote:
>>>> syzbot is reporting NULL pointer dereference in lo_rw_aio() [1][2].
>>>> An analysis by the Gemini AI collaborator [3] considers that this problem
>>>> is caused by a timing shift primarily exposed by commit 65565ca5f99b
>>>> ("block: unify the synchronous bi_end_io callbacks"), along with helper
>>>> refactorings like commit 92c3737a2473 ("block: add a bio_submit_or_kill
>>>> helper").
>>>>
>>>> But due to difficulty of reproducing this race, discussion about what is
>>>> happening and how to fix this problem is stalling. Also, we haven't
>>>> identified how many filesystems are subjected to this problem.
>>>>
>>>> Therefore, this patch introduces a grace period for flushing pending I/O
>>>> requests (which should be a good thing from the perspective of defensive
>>>> programming) so that we won't hit NULL pointer dereference problem, and
>>>> also emits BUG: message in order to help filesystem developers identify
>>>> the caller of an I/O request that failed to wait for completion so that
>>>> filesystem developers can fix such caller to wait for completion.
>>>>
>>>> Note that emitting BUG: message is enabled only if CONFIG_KCOV=y, for
>>>> this check is a waste of computation resources for almost all users.
>>>
>>> Still breaks xfs/259, same as the version in next-20260605...
>>>
>> And syzbot report [1]
>> 
>> [1] https://lore.kernel.org/lkml/6a54399f.278cdcd2.e885.0023.GAE@xxxxxxxxxx/
>
> No. This report is from upstream tree where "loop: Fix NULL pointer dereference
> in lo_rw_aio()" is not yet applied.
>
The issue remains but this work stalls.