CVE-2025-38710
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk4th percentile - higher than 4% of all known CVEs
Summary
W jądrze Linuxa rozwiązano podatność dotyczącą walidacji i_depth dla katalogów exhash. W wyniku testu fuzzingowego doszło do uszkodzenia, które skutkowało głębokością równą 0 w funkcji dir_e_read(), co prowadziło do nieokreślonego przesunięcia.
Risk Assessment
Podatność ta może prowadzić do nieprzewidywalnego zachowania systemu, co może skutkować awarią lub naruszeniem integralności danych w systemach korzystających z katalogów exhash.
Recommendation
Zaleca się aktualizację jądra Linuxa do najnowszej wersji, aby usunąć tę podatność oraz wprowadzenie dodatkowych kontroli głębokości w funkcji gfs2_dinode_in().
Related vulnerabilities
- CVE-2026-96257Critical
A flaw has been found in Fast FAC1203R Gigabit Edition 2.0.4 in the copy_msg_element function of the Device Discovery Service component. Input manipulation can lead to a stack-based buffer overflow, and the attack can be executed remotely. The exploit has been published and may be used; the vendor did not respond to the disclosure.
- CVE-2026-18169Critical
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote authenticated attacker to obtain sensitive information due to improper validation of symbolic links.
- CVE-2026-18163Critical
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to execute arbitrary code due to improper deserialization of untrusted data.
- CVE-2026-18162Critical
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to execute arbitrary code due to improper neutralization of user-controlled input within the new Function constructor.
- CVE-2026-19202Critical
A caching flaw in the toolbox-core package of the mcp-toolbox-sdk-python SDK causes the same Google ID token to be cached and reused across different audiences. If an application uses the SDK to authenticate to two or more different audiences within the same process, the module-level token cache fails to key its cached tokens by the requested audience. Consequently, a valid, unexpired token minted for a sensitive service (Service A) can be retrieved from the cache and sent to a secondary service (Service B). An attacker who operates, compromises, or monitors traffic to Service B can capture this token and replay it to impersonate the victim application against Service A.
- CVE-2026-17645Critical
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote authenticated attacker to gain elevated privileges due to improper privilege management.
- CVE-2026-17635Critical
IBM Financial Transaction Manager (FTM) for RedHat OpenShift could allow a remote attacker to perform unauthorized actions due to improper configuration of HTTP method-based security constraints.
- CVE-2026-17472Critical
IBM Concert 1.0.0 through 3.0.0 could allow a remote authenticated attacker to access or modify unauthorized resources due to the use of wildcards in RBAC permission definitions.
- CVE-2026-16346Critical
IBM DataStage on Cloud Pak for Data 5.4.0.0 could allow a remote authenticated attacker to execute arbitrary commands due to improper neutralization of special elements used in an OS command.
- CVE-2026-77987Critical
A server-side request forgery (SSRF) vulnerability was identified in the notebook viewer of GitHub Enterprise Server. The notebook viewer validated the scheme and host of a user-supplied URL but did not validate the port, allowing requests to be directed to internal services listening on other ports of the same appliance. Response bodies were not returned to the requester, but response timing acted as an oracle that allowed instance secrets to be extracted character by character. An extracted secret could then be used in a separate interaction with an internal service to obtain remote code execution on the appliance. Exploitation required network access to the instance and was unauthenticated when private mode was disabled, or required any authenticated user when private mode was enabled. This vulnerability affected GitHub Enterprise Server versions 3.17 through 3.22 and was fixed in versions 3.22.1, 3.21.6, 3.20.8, 3.19.12, 3.18.15, and 3.17.21. This vulnerability was reported through the GitHub Bug Bounty program.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: gfs2: Validate i_depth for exhash directories A fuzzer test introduced corruption that ends up with a depth of 0 in dir_e_read(), causing an undefined shift by 32 at: index = hash >> (32 - dip->i_depth); As calculated in an open-coded way in dir_make_exhash(), the minimum depth for an exhash directory is ilog2(sdp->sd_hash_ptrs) and 0 is invalid as sdp->sd_hash_ptrs is fixed as sdp->bsize / 16 at mount time. So we can avoid the undefined behaviour by checking for depth values lower than the minimum in gfs2_dinode_in(). Values greater than the maximum are already being checked for there. Also switch the calculation in dir_make_exhash() to use ilog2() to clarify how the depth is calculated. Tested with the syzkaller repro.c and xfstests '-g quick'.

