All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sasha Levin" <sashal@kernel.org>
Cc: linux-modules@vger.kernel.org
Subject: Re: [PATCH v6 3/4] kallsyms: delta-compress lineinfo tables for ~2.7x size reduction
Date: Mon, 06 Jul 2026 14:40:36 +0000	[thread overview]
Message-ID: <20260706144037.060841F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260706142914.2398993-4-sashal@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] lineinfo_read_sleb128 contains a signed left shift that can overflow on malformed or large data, triggering a UBSAN splat in NMI/panic contexts.
--

commit 3756e632dbdf4d6db79f0e2c8a39f6103ac6e8ad
Author: Sasha Levin <sashal@kernel.org>

kallsyms: delta-compress lineinfo tables for ~2.7x size reduction

This patch replaces the flat uncompressed parallel arrays for lineinfo with a
block-indexed, delta-encoded, ULEB128/SLEB128 varint compressed format to
significantly reduce size. Entries are grouped into blocks of 64 and decoded
entirely on the stack to ensure safety during NMI or panic contexts.

> diff --git a/include/linux/mod_lineinfo.h b/include/linux/mod_lineinfo.h
> index 9cda3263a0784..a3c7143433020 100644
> --- a/include/linux/mod_lineinfo.h
> +++ b/include/linux/mod_lineinfo.h

[ ... ]

> +/* Read an SLEB128 varint. Same safety guarantees as above. */
> +static inline int32_t lineinfo_read_sleb128(const u8 *data, u32 *pos, u32 end)
> +{
> +	int32_t result = 0;
> +	unsigned int shift = 0;
> +	u8 byte = 0;
> +
> +	while (*pos < end) {
> +		byte = data[*pos];
> +		(*pos)++;
> +		result |= (int32_t)(byte & 0x7f) << shift;

[Severity: High]
Can this signed left shift trigger a UBSAN splat on malformed or large data?

For the 5th byte of an SLEB128 varint, shift will be 28. If the decoded byte
has a value greater than 7 (e.g. 0x7F), 127 << 28 evaluates to 3409130496,
which exceeds INT32_MAX.

Since left-shifting into or past the sign bit of a signed integer is
undefined behavior in C, a corrupted or maliciously crafted .mod_lineinfo
section could trigger a CONFIG_UBSAN_SHIFT splat.

If this function is called by lineinfo_search() during an NMI or panic
context, would the resulting UBSAN splat attempt to take locks and call
printk, potentially causing a deadlock or nested panic?

Perhaps the shift should be performed as unsigned:
result |= (int32_t)((u32)(byte & 0x7f) << shift);

> +		shift += 7;
> +		if (!(byte & 0x80))
> +			break;
> +		if (shift >= 32) {
> +			while (*pos < end && (data[*pos] & 0x80))
> +				(*pos)++;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706142914.2398993-1-sashal@kernel.org?part=3

  reply	other threads:[~2026-07-06 14:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06 14:29 [PATCH v6 0/4] kallsyms: embed source file:line info in kernel stack traces Sasha Levin
2026-07-06 14:29 ` [PATCH v6 1/4] " Sasha Levin
2026-07-06 14:44   ` sashiko-bot
2026-07-06 14:29 ` [PATCH v6 2/4] kallsyms: extend lineinfo to loadable modules Sasha Levin
2026-07-06 14:41   ` sashiko-bot
2026-07-06 14:29 ` [PATCH v6 3/4] kallsyms: delta-compress lineinfo tables for ~2.7x size reduction Sasha Levin
2026-07-06 14:40   ` sashiko-bot [this message]
2026-07-06 14:29 ` [PATCH v6 4/4] kallsyms: add KUnit tests for lineinfo feature Sasha Levin
2026-07-06 14:45   ` sashiko-bot

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=20260706144037.060841F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.