CVE-2025-39735 Affecting kernel package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL6-KERNEL-9779335
  • published19 Apr 2025
  • disclosed18 Apr 2025

Introduced: 18 Apr 2025

NewCVE-2025-39735  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:6 kernel.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel package and not the kernel package as distributed by RHEL. See How to fix? for RHEL:6 relevant fixed versions and status.

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 &lt; len; j++) {
        if (linebuflen &lt; lx + 2)
            goto overflow2;
        ch = ptr[j];
    ...
}

To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised.

CVSS Base Scores

version 3.1