From: Bryam Vargas <hexlabsecurity@proton.me>
To: Jan Kara <jack@suse.cz>
Cc: Michael Bommarito <michael.bommarito@gmail.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] isofs: bound Rock Ridge symlink components to the SL record
Date: Sat, 06 Jun 2026 22:29:03 +0000 [thread overview]
Message-ID: <20260606222857.193818-1-hexlabsecurity@proton.me> (raw)
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 both walk sites.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
---
Reproducer (crafted ISO-9660 image with Rock Ridge):
# a symlink whose SL component length byte is enlarged so the
# component overruns its SL record
ln -s "$(python3 -c 'print("A"*250)')" /tmp/iso/l
genisoimage -R -o rr.iso /tmp/iso
# repoint the symlink's CE record to a tight continuation block
# (cont_size = 7) holding one SL record:
# 53 4c 07 01 00 00 ff "SL", len 7, ver 1, comp flags 0, comp len 0xff
# so rock_continue() does kmalloc(7) and the component text begins at
# the end of that allocation.
mount -o loop,ro rr.iso /mnt
readlink /mnt/l
Without the patch, get_symlink_chunk() memcpy()s slp->len (0xff) bytes
starting one byte into the 7-byte allocation, so readlink() returns the
symlink target followed by adjacent in-kernel bytes (verified: the
returned link contains neighbouring directory-record / slab contents,
not just the target). On a tight continuation allocation the read
leaves the object and is a slab-out-of-bounds read that KASAN reports in
get_symlink_chunk(). With the patch the over-long component is rejected
(slp->len + 2 > slen) and readlink() returns only the valid prefix; a
well-formed Rock Ridge image is unaffected.
fs/isofs/rock.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/fs/isofs/rock.c b/fs/isofs/rock.c
index 1232fab59a4e..0fe781381e66 100644
--- a/fs/isofs/rock.c
+++ b/fs/isofs/rock.c
@@ -466,6 +466,9 @@ parse_rock_ridge_inode_internal(struct iso_directory_record *de,
inode->i_size = symlink_len;
while (slen > 1) {
rootflag = 0;
+ /* keep the component within the SL record */
+ if (slp->len + 2 > slen)
+ break;
switch (slp->flags & ~1) {
case 0:
inode->i_size +=
@@ -621,6 +624,14 @@ static char *get_symlink_chunk(char *rpnt, struct rock_ridge *rr, char *plimit)
slp = &rr->u.SL.link;
while (slen > 1) {
rootflag = 0;
+ /*
+ * A component is a two-byte header (flags, len) followed by
+ * len bytes of text, i.e. slp->len + 2 bytes. Stop if it does
+ * not fit in the bytes left in the SL record, otherwise the
+ * memcpy() of slp->text below reads past the record.
+ */
+ if (slp->len + 2 > slen)
+ break;
switch (slp->flags & ~1) {
case 0:
if (slp->len > plimit - rpnt)
--
2.43.0
next reply other threads:[~2026-06-06 22:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-06 22:29 Bryam Vargas [this message]
2026-06-06 23:44 ` Michael Bommarito
2026-06-07 1:18 ` Bryam Vargas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260606222857.193818-1-hexlabsecurity@proton.me \
--to=hexlabsecurity@proton.me \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.bommarito@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®