GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel iomap: memory corruption when recording I/O errors during writeback

CVSS 7.8CVE-2022-50406Kernel, userspace & hypervisorcurated

Impact

When writeback hit an I/O error, iomap recorded the error against a mapping that could already have been torn down, producing a NULL dereference inside errseq_set()/__filemap_set_wb_err() and memory corruption in the writeback worker. The reporter reproduced it as a repeatable kernel oops on XFS over device-mapper under fsstress plus block errors. For an operator this is a stability and integrity problem on any node whose local or shared filesystem sees write errors - a flaky NVMe, a failing dm/LVM path, or a storage target that returns errors - and the crash lands in the writeback kthread, so the node is lost rather than the workload. There is no tenant-facing attack path in the record; it requires a filesystem that is already reporting I/O errors.

Who can reach it

Local. A user able to generate filesystem writeback traffic on a volume whose backing device returns I/O errors. Authentication to the node is required; the trigger is a storage fault, not attacker input alone.

What to do

Update to a stable kernel carrying the fix (five stable commits are linked; the record names no single fixed version) and reboot the node. On GPU nodes with local scratch NVMe this is a drain-and-reboot per node; schedule it with the next kernel maintenance rather than on its own. Until then, treat nodes logging I/O errors plus writeback oopses as hardware replacement candidates - the crash is a symptom of a device that is already failing.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.