jfs: fix slab-out-of-bounds read in ea_get()
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.4.292, 5.10.236, 5.15.180, 6.1.134, 6.6.87, and 3 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds read in ea_get() During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump(). Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped: int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328). The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration: for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize; hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii); ... } The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop: for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto overflow2; ch = ptr[j]; ... } To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 5.4.287 · fixed in 5.4.292; From 5.10.231 · fixed in 5.10.236; From 5.15.174 · fixed in 5.15.180; From 6.1.120 · fixed in 6.1.134; From 6.6.64 · fixed in 6.6.87; From 6.12.2 · fixed in 6.12.23; From 4.19.325 · fixed in 4.20; From 6.11.11 · fixed in 6.12
- Linux Linux
6.13
References 9
git.kernel.org
- stable/c/3d6fd5b9c6acbc005e53d0211c7381f566babec1
- stable/c/50afcee7011155933d8d5e8832f52eeee018cfd3
- stable/c/78c9cbde8880ec02d864c166bcb4fe989ce1d95f
- stable/c/46e2c031aa59ea65128991cbca474bd5c0c2ecdb
- stable/c/a8c31808925b11393a6601f534bb63bac5366bab
- stable/c/0beddc2a3f9b9cf7d8887973041e36c2d0fa3652
- stable/c/16d3d36436492aa248b2d8045e75585ebcc2f34d
- stable/c/5263822558a8a7c0d0248d5679c2dcf4d5cda61f
- stable/c/fdf480da5837c23b146c4743c18de97202fcab37