CVE-2025-39735: jfs: fix slab-out-of-bounds read in ea_get()

In the Linux kernel, the following vulnerability has been resolved:

jfs: fix slab-out-of-bounds read in eaget()

During the "sizecheck" label in eaget(), the code checks if the extended attribute list (xattr) size matches easize. If not, it logs "eaget: invalid extended attribute" and calls printhexdump().

Here, EALISTSIZE(eabuf->xattr) returns 4110417968, which exceeds INTMAX (2,147,483,647). Then easize is clamped:

int size = clampt(int, easize, 0, EALISTSIZE(eabuf->xattr));

Although clampt aims to bound easize 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 printhexdump() (called "len" in printhexdump()), it is passed as type sizet (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 hexdumptobuffer(). In printhexdump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hexdumptobuffer() on each iteration:

for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize;

hexdumptobuffer(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 hexdumptobuffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hexdumptobuffer() 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 "EALISTSIZE(eabuf->xattr)" before it is utilised.