Page MenuHomeFreeBSD

aio: Fix a race in sys_aio_cancel()
ClosedPublic

Authored by markj on Jul 29 2025, 7:12 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Oct 10, 12:33 PM
Unknown Object (File)
Fri, Oct 10, 12:33 PM
Unknown Object (File)
Fri, Oct 10, 12:33 PM
Unknown Object (File)
Fri, Oct 10, 12:33 PM
Unknown Object (File)
Fri, Oct 10, 5:43 AM
Unknown Object (File)
Wed, Sep 17, 7:15 AM
Unknown Object (File)
Tue, Sep 16, 5:14 PM
Unknown Object (File)
Sep 15 2025, 11:18 AM
Subscribers

Details

Summary

sys_aio_cancel() loops over pending jobs for the process, cancelling
some of them. To cancel a job with a cancel callback, it must drop the
job list mutex. It uses flags, KAIOCB_CANCELLING and KAIOCB_CANCELLED,
to make sure that a job isn't double-cancelled. However, when iterating
over the list it uses TAILQ_FOREACH_SAFE and thus assumes that the next
job isn't going to be removed while the lock is dropped. Of course,
this assumption is false.

We could simply start search from the beginning after cancelling a job,
but this might be quite expensive. Instead, introduce the notion of a
marker job, used to keep track of one's position in the queue. Use it
in sys_aio_cancel() to resume iteration after a job is cancelled.

Reported by: syzkaller

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

markj requested review of this revision.Jul 29 2025, 7:12 PM
kib added inline comments.
sys/kern/vfs_aio.c
588

This should be true because we single-thread the process on exit and exec, I suppose. Might be, add a comment.

This revision is now accepted and ready to land.Jul 29 2025, 7:37 PM
markj marked an inline comment as done.

Add a comment.

This revision now requires review to proceed.Jul 30 2025, 1:14 PM
This revision is now accepted and ready to land.Jul 30 2025, 1:37 PM
This revision was automatically updated to reflect the committed changes.