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.