CVE-2021-47406
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2021-47406
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2021-47406.json
- JSON Data
- https://api.osv.dev/v1/vulns/CVE-2021-47406
- Related
- Published
- 2024-05-21T15:15:26Z
- Modified
- 2024-11-01T22:50:16.720043Z
- Summary
- [none]
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
ext4: add error checking to ext4extreplaysetiblocks()
If the call to ext4mapblocks() fails due to an corrupted file system, ext4extreplaysetiblocks() can get stuck in an infinite loop. This could be reproduced by running generic/526 with a file system that has inlinedata and fastcommit enabled. The system will repeatedly log to the console:
EXT4-fs warning (device dm-3): ext4blockto_path:105: block 1074800922 > max in inode 131076
and the stack that it gets stuck in is:
ext4blocktopath+0xe3/0x130 ext4indmapblocks+0x93/0x690 ext4mapblocks+0x100/0x660 skiphole+0x47/0x70 ext4extreplaysetiblocks+0x223/0x440 ext4fcreplayinode+0x29e/0x3b0 ext4fcreplay+0x278/0x550 doonepass+0x646/0xc10 jbd2journalrecover+0x14a/0x270 jbd2journalload+0xc4/0x150 ext4loadjournal+0x1f3/0x490 ext4fillsuper+0x22d4/0x2c00
With this patch, generic/526 still fails, but system is no longer locking up in a tight loop. It's likely the root casue is that fastcommit replay is corrupting file systems with inlinedata, and we probably need to add better error handling in the fast commit replay code path beyond what is done here, which essentially just breaks the infinite loop without reporting the to the higher levels of the code.
- References
Affected packages
Debian:11 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source
Debian:12 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source
Debian:13 / linux
Package
- Name
- linux
- Purl
- pkg:deb/debian/linux?arch=source