In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk()… (CVE-2026-64317)
In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory. ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled. Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.
AI Analysis
Technical Summary
The Linux kernel's isofs module had a vulnerability in the handling of Rock Ridge symbolic link (SL) records. Functions get_symlink_chunk() and parse_rock_ridge_inode_internal() iterate over variable-length SL components without verifying that each component fits within the SL record boundary. A crafted SL record with a component length exceeding the record size triggers an out-of-bounds read of up to 255 bytes. When the SL record is at the end of its backing buffer, this read crosses the allocation boundary, causing get_symlink_chunk() to copy out-of-bounds kernel memory into the symlink body returned to user space by readlink(), resulting in kernel memory disclosure. The vulnerability is exploitable via mounting ISO 9660 images from untrusted media, which desktop environments often auto-mount without elevated privileges. The fix involves rejecting any SL component that does not fit within the remaining record bytes, causing readlink() to fail safely instead of leaking memory.
Potential Impact
An attacker controlling the contents of an ISO 9660 image can craft a malformed Rock Ridge SL record that causes the kernel to read and disclose adjacent kernel memory to user space. This memory disclosure could potentially leak sensitive kernel information, which might aid further attacks. The vulnerability is triggered by mounting and reading symbolic links from untrusted ISO 9660 images, a common scenario with removable media. There is no indication of code execution or privilege escalation from this vulnerability alone.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to add proper bounds checking on Rock Ridge SL components. This prevents out-of-bounds reads and kernel memory disclosure. Users should apply the official kernel updates that include this fix. Since this is a kernel vulnerability, patching the kernel is the recommended remediation. There is no vendor advisory provided here, so check the Linux kernel mailing lists or distribution security advisories for the official patch and update guidance. Until patched, avoid mounting untrusted ISO 9660 images or use mount options that disable Rock Ridge extensions if possible.
In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk()… (CVE-2026-64317)
Description
In the Linux kernel, the following vulnerability has been resolved: isofs: bound Rock Ridge symlink components to the SL record get_symlink_chunk() and the SL handling in parse_rock_ridge_inode_internal() walk the variable-length components of a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte header (flags, len) followed by len bytes of text, so it occupies slp->len + 2 bytes. Both loops read slp->len and advance to the next component, and get_symlink_chunk() additionally does memcpy(rpnt, slp->text, slp->len), but neither checks that the component lies within the SL record before dereferencing it. A crafted SL record whose component declares a len that runs past the record (rr->len) therefore triggers an out-of-bounds read of up to 255 bytes. When the record sits at the tail of its backing buffer - for example a small kmalloc()ed continuation block reached through a CE record - the read crosses the allocation; get_symlink_chunk() then copies the out-of-bounds bytes into the symlink body returned to user space by readlink(), disclosing adjacent kernel memory. ISO 9660 images are routinely mounted from untrusted removable media - desktop environments auto-mount them (e.g. via udisks2) without CAP_SYS_ADMIN - so the record contents are attacker-controlled. Reject any component that does not fit in the remaining record bytes before using it. In get_symlink_chunk() return NULL, like the existing output-buffer (plimit) checks, so a malformed record makes readlink() fail with -EIO rather than silently returning a truncated target; in parse_rock_ridge_inode_internal() stop the inode-size walk.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel's isofs module had a vulnerability in the handling of Rock Ridge symbolic link (SL) records. Functions get_symlink_chunk() and parse_rock_ridge_inode_internal() iterate over variable-length SL components without verifying that each component fits within the SL record boundary. A crafted SL record with a component length exceeding the record size triggers an out-of-bounds read of up to 255 bytes. When the SL record is at the end of its backing buffer, this read crosses the allocation boundary, causing get_symlink_chunk() to copy out-of-bounds kernel memory into the symlink body returned to user space by readlink(), resulting in kernel memory disclosure. The vulnerability is exploitable via mounting ISO 9660 images from untrusted media, which desktop environments often auto-mount without elevated privileges. The fix involves rejecting any SL component that does not fit within the remaining record bytes, causing readlink() to fail safely instead of leaking memory.
Potential Impact
An attacker controlling the contents of an ISO 9660 image can craft a malformed Rock Ridge SL record that causes the kernel to read and disclose adjacent kernel memory to user space. This memory disclosure could potentially leak sensitive kernel information, which might aid further attacks. The vulnerability is triggered by mounting and reading symbolic links from untrusted ISO 9660 images, a common scenario with removable media. There is no indication of code execution or privilege escalation from this vulnerability alone.
Mitigation Recommendations
A fix has been implemented in the Linux kernel to add proper bounds checking on Rock Ridge SL components. This prevents out-of-bounds reads and kernel memory disclosure. Users should apply the official kernel updates that include this fix. Since this is a kernel vulnerability, patching the kernel is the recommended remediation. There is no vendor advisory provided here, so check the Linux kernel mailing lists or distribution security advisories for the official patch and update guidance. Until patched, avoid mounting untrusted ISO 9660 images or use mount options that disable Rock Ridge extensions if possible.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-qvx5-h96v-vv5j
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64317"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a65420d9c2644c7f80856bd
Added to database: 07/25/2026, 23:09:01 UTC
Last enriched: 07/25/2026, 23:34:40 UTC
Last updated: 09/07/2026, 10:52:10 UTC
Views: 33
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.