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.
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.
Metrics
Affected Vendors & Products
| Vendors | Products |
|---|---|
| Linux |
|
Configuration 1 [-]
|
No data.
No data.
Advisories
| Source | ID | Title |
|---|---|---|
 Debian DLA |
DLA-4178-1 | linux security update |
| Debian DLA |
DLA-4193-1 | linux-6.1 security update |
 Debian DSA |
DSA-5907-1 | linux security update |
 EUVD |
EUVD-2025-11818 | 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. |
 Ubuntu USN |
USN-7585-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7585-2 | Linux kernel (FIPS) vulnerabilities |
| Ubuntu USN |
USN-7585-3 | Linux kernel (FIPS) vulnerabilities |
| Ubuntu USN |
USN-7585-4 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-7585-5 | Linux kernel (HWE) vulnerabilities |
| Ubuntu USN |
USN-7585-6 | Linux kernel (BlueField) vulnerabilities |
| Ubuntu USN |
USN-7585-7 | Linux kernel (Raspberry Pi) vulnerabilities |
| Ubuntu USN |
USN-7591-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7591-2 | Linux kernel (FIPS) vulnerabilities |
| Ubuntu USN |
USN-7591-3 | Linux kernel (Real-time) vulnerabilities |
| Ubuntu USN |
USN-7591-4 | Linux kernel (AWS) vulnerabilities |
| Ubuntu USN |
USN-7591-5 | Linux kernel (Intel IoTG) vulnerabilities |
| Ubuntu USN |
USN-7591-6 | Linux kernel (Raspberry Pi) vulnerabilities |
| Ubuntu USN |
USN-7592-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7593-1 | Linux kernel (HWE) vulnerabilities |
| Ubuntu USN |
USN-7594-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7594-2 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-7594-3 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7597-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-7597-2 | Linux kernel (Azure FIPS) vulnerabilities |
| Ubuntu USN |
USN-7598-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-7602-1 | Linux kernel (Xilinx ZynqMP) vulnerabilities |
| Ubuntu USN |
USN-7605-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7605-2 | Linux kernel (Low Latency) vulnerabilities |
| Ubuntu USN |
USN-7606-1 | Linux kernel (OEM) vulnerabilities |
| Ubuntu USN |
USN-7628-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-7640-1 | Linux kernel (IoT) vulnerabilities |
| Ubuntu USN |
USN-7655-1 | Linux kernel (Intel IoTG) vulnerabilities |
| Ubuntu USN |
USN-7835-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7835-2 | Linux kernel (Real-time) vulnerabilities |
| Ubuntu USN |
USN-7835-3 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7835-4 | Linux kernel (HWE) vulnerabilities |
| Ubuntu USN |
USN-7835-5 | Linux kernel (Oracle) vulnerabilities |
| Ubuntu USN |
USN-7835-6 | Linux kernel (AWS) vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Mon, 03 Nov 2025 20:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Wed, 01 Oct 2025 17:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Mon, 28 Apr 2025 15:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
Tue, 22 Apr 2025 02:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-125 | |
| Metrics |
cvssV3_1
|
cvssV3_1
|
Sat, 19 Apr 2025 02:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Fri, 18 Apr 2025 07:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | jfs: fix slab-out-of-bounds read in ea_get() | |
| References |
|
|
MITRE
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-11-03T19:58:46.112Z
Reserved: 2025-04-16T07:20:57.119Z
Link: CVE-2025-39735
Vulnrichment
Updated: 2025-10-01T14:42:03.710Z
NVD
Status : Modified
Published: 2025-04-18T07:15:44.150
Modified: 2025-11-03T20:18:47.320
Link: CVE-2025-39735
Redhat
OpenCVE Enrichment
No data.