CVE-2024-53052

In the Linux kernel, the following vulnerability has been resolved:

iouring/rw: fix missing NOWAIT check for ODIRECT start write

When iouring starts a write, it'll call kiocbstartwrite() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But iouring unconditionally uses kiocbstartwrite(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write:

task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: _switchto+0x1d8/0x348 _schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpurwsemwait+0x1e8/0x3f8 _percpudownread+0xe8/0x500 iowrite+0xbb8/0xff8 ioissuesqe+0x10c/0x1020 iosubmitsqes+0x614/0x2110 _arm64sysiouringenter+0x524/0x1038 invokesyscall+0x74/0x268 el0svccommon.constprop.0+0x160/0x238 doel0svc+0x44/0x60 el0svc+0x44/0xb0 el0t64synchandler+0x118/0x128 el0t64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963

with the attempting freezer stuck trying to grab the rwsem:

task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: _switchto+0x1d8/0x348 _schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpudownwrite+0x2b0/0x680 freezesuper+0x248/0x8a8 dovfsioctl+0x149c/0x1b18 _arm64sysioctl+0xd0/0x1a0 invokesyscall+0x74/0x268 el0svccommon.constprop.0+0x160/0x238 doel0svc+0x44/0x60 el0svc+0x44/0xb0 el0t64synchandler+0x118/0x128 el0t64sync+0x168/0x170

Fix this by having the iouring side honor IOCBNOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCBNOWAIT would always be set, this returns -EAGAIN which will have iouring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress.

Since freezing requires CAPSYSADMIN in the first place, this isn't something that can be triggered by a regular user.