CVE-2026-89490
ocfs2: fix readdir position truncation on 32-bit kernels
Published Sep 11, 2026
CVSS 3.1 · 5.5 Medium
EPSS < 1%
KEV · Not listed
Description
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix readdir position truncation on 32-bit kernels
In ocfs2_dir_foreach_blk_el(), the directory cookie position is
rebuilt with
ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;
`ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is
unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask
~(sb->s_blocksize - 1)
is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB
block size). In the AND expression with the 64-bit `ctx->pos`, that
unsigned operand is zero-extended to 64 bits per the usual arithmetic
conversions, yielding 0x00000000fffff000. The high 32 bits of
`ctx->pos` are silently cleared, even though directory size is
allowed to exceed 4 GiB.
When readdir() crosses the 4 GiB boundary on a 32-bit kernel the
position is reset back into the first 4 GiB block, making the
re-validation path re-enumerate already-returned dirents indefinitely.
This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken
for all non-inline directories, so a directory large enough to cross
4 GiB reaches it.
This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
bitwise operation having different size") fixed in exfat, and the
fix mirrors the equivalent ext4 fix in this series. Cast the operand
to loff_t so the mask is 64-bit before the AND:
ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
64-bit kernels are unaffected.
ocfs2: fix readdir position truncation on 32-bit kernels
In ocfs2_dir_foreach_blk_el(), the directory cookie position is
rebuilt with
ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset;
`ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is
unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask
~(sb->s_blocksize - 1)
is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB
block size). In the AND expression with the 64-bit `ctx->pos`, that
unsigned operand is zero-extended to 64 bits per the usual arithmetic
conversions, yielding 0x00000000fffff000. The high 32 bits of
`ctx->pos` are silently cleared, even though directory size is
allowed to exceed 4 GiB.
When readdir() crosses the 4 GiB boundary on a 32-bit kernel the
position is reset back into the first 4 GiB block, making the
re-validation path re-enumerate already-returned dirents indefinitely.
This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken
for all non-inline directories, so a directory large enough to cross
4 GiB reaches it.
This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix
bitwise operation having different size") fixed in exfat, and the
fix mirrors the equivalent ext4 fix in this series. Cast the operand
to loff_t so the mask is 64-bit before the AND:
ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset;
64-bit kernels are unaffected.
Affected Products
-
CVE record
-
NVD configurations
No data
-
Red Hat packages
No data
-
OpenCVE enrichment
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
|||||||||||||||||||||||||||||||||
| Linux | Linux | affected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux Kernel |
|
||||||||||||||||||||||||||||
| Linux | Linux Kernel |
|
Remediation
Tracking
Advisories
| Source | ID | Title |
|---|---|---|
 Debian DLA |
DLA-4817-1 | linux-6.12 security update |
| Debian DLA |
DLA-4841-1 | linux security update |
 Debian DSA |
DSA-6528-1 | linux security update |
 Ubuntu USN |
USN-8961-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9019-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-9020-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9022-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9023-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9024-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9025-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-9026-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-9029-1 | Linux kernel (Raspberry Pi) vulnerabilities |
| Ubuntu USN |
USN-9039-1 | Linux kernel (Azure CVM) vulnerabilities |
| Ubuntu USN |
USN-9040-1 | Linux kernel (Low Latency NVIDIA) vulnerabilities |
| Ubuntu USN |
USN-9066-1 | Linux kernel (HWE) vulnerabilities |
| Ubuntu USN |
USN-9091-1 | Linux kernel (NVIDIA Tegra) vulnerabilities |
Metrics
No CVSS v4.0
Attack Vector Local
Attack Complexity Low
Privileges Required Low
Scope Unchanged
Confidentiality Impact None
Integrity Impact None
Availability Impact High
User Interaction None
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.177% probability within 30 days)
Key SSVC decision points have not yet been added.
References
History
Sep 14, 2026 12:30 PM
Added references
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Sep 12, 2026 12:15 AM
Weaknesses updated. Added references. Scoring metrics updated
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-190 | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Sep 11, 2026 11:45 PM
Description updated. Title updated. First appearance in the feed. Affected versions updated. Affected vendors updated. Added references
View changes
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix readdir position truncation on 32-bit kernels In ocfs2_dir_foreach_blk_el(), the directory cookie position is rebuilt with ctx->pos = (ctx->pos & ~(sb->s_blocksize - 1)) | offset; `ctx->pos` is loff_t (signed 64-bit), while `sb->s_blocksize` is unsigned long. On 32-bit kernels unsigned long is 32-bit, so the mask ~(sb->s_blocksize - 1) is computed as a 32-bit unsigned value (e.g. 0xfffff000 for a 4 KiB block size). In the AND expression with the 64-bit `ctx->pos`, that unsigned operand is zero-extended to 64 bits per the usual arithmetic conversions, yielding 0x00000000fffff000. The high 32 bits of `ctx->pos` are silently cleared, even though directory size is allowed to exceed 4 GiB. When readdir() crosses the 4 GiB boundary on a 32-bit kernel the position is reset back into the first 4 GiB block, making the re-validation path re-enumerate already-returned dirents indefinitely. This is ocfs2_dir_foreach_blk_el(), the extent-list readdir path taken for all non-inline directories, so a directory large enough to cross 4 GiB reaches it. This is the same class of bug that commit 3dce5bb82c97 ("exfat: Fix bitwise operation having different size") fixed in exfat, and the fix mirrors the equivalent ext4 fix in this series. Cast the operand to loff_t so the mask is 64-bit before the AND: ctx->pos = (ctx->pos & ~((loff_t)sb->s_blocksize - 1)) | offset; 64-bit kernels are unaffected. | |
| Title | ocfs2: fix readdir position truncation on 32-bit kernels | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
Subscriptions
Weaknesses
