Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
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 extendedattribute 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 exceedsINT_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 upperlimit 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" inprint_hex_dump()), it is passed as type size_t (an unsignedtype), this is then stored inside a variable called"int remaining", which is then assigned to "int linelen" whichis then passed to hex_dump_to_buffer(). In print_hex_dump()the for loop, iterates through 0 to len-1, where len is18446744073525002176, 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 brokensince len is corrupted and very large. This eventually leads tothe "ptr+i" being passed to hex_dump_to_buffer() to get closerto the end of the actual bounds of "ptr", eventually an out ofbounds access is done in hex_dump_to_buffer() in the followingfor 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.
No PoCs from references.
- https://github.com/runwhen-contrib/helm-charts
- https://github.com/w4zu/Debian_security