In the Linux kernel, the following vulnerability has been resolved: pipe: preserve existing fasync…

Why it is Yellow

• CVSS 7.8 high
• On your watchlist: linux kernel

References

• https://git.kernel.org/stable/c/2259809e5b7043c4ba20af7b14ba3e471cf55521
• https://git.kernel.org/stable/c/40bb03d3ea6f6a915218508819ecc4d7a7fa260d
• https://git.kernel.org/stable/c/4c42ce499ce4b1c787e61082e3b13df4f30c4eaa
• https://git.kernel.org/stable/c/22c7f57b0c0b0b8e19cfb41a1bd85f55715ad386
• https://git.kernel.org/stable/c/6041bcd185d4df051490fe166e64feae6c3b8291
• https://git.kernel.org/stable/c/7cdbfa22a7e270b155ddb958b1583a999c0c8abb
• https://git.kernel.org/stable/c/94be790dd6fbe0912f35bb711bea8ef3687eaca9
• https://git.kernel.org/stable/c/9b0aa2a1d8df51f3dcb363c3a2d9531098e88dc6

Original description

In the Linux kernel, the following vulnerability has been resolved: pipe: preserve existing fasync readers on writer setup failure F_SETFL and FIOASYNC decide whether to invoke ->fasync() before pipe_fasync() takes pipe->mutex. Two enables of one O_RDWR FIFO can therefore both enter the callback. fasync_helper() allocates before checking for an existing entry. If the first enable installs both entries, a second enable can update the reader entry and then fail the allocation for the writer entry. The error path removes the pre-existing reader entry, clearing FASYNC while the writer entry remains registered. __fput() then skips ->fasync(), so a later pipe notification can dereference the freed file or its f_owner. An unprivileged memory-pressure reproducer triggers a KASAN slab-use-after-free in send_sigio() through this path. Keep the reader helper's result and undo the registration only if this call added it. The pipe mutex serializes changes to both lists, so a failed new registration still removes its reader, while a failed duplicate preserves the existing registrations and FASYNC. Successful duplicate enables continue to update fa_fd as before.