[BUG] net/sched: act_csum can checksum beyond a short IPv6 jumbogram skb

[BUG] net/sched: act_csum can checksum beyond a short IPv6 jumbogram skb

[shaos]

Hello,

An unprivileged process with namespace-scoped CAP_NET_ADMIN and CAP_NET_RAW installs a csum action for UDP-Lite and sends a 300-byte IPv6 frame with a Jumbo Payload value of 0xffffffca and UDP-Lite coverage longer than the bytes present. The jumbo-length addition wraps the pull-length check, while the later checksum path still uses the unwrapped length.

HEAD commit:    c03c1a14507dfaf8b856c2608f9ac216021fc222
git tree:       30fd2ef82912c26cf3a58ad0ba6afc375fa851ac
source version: Linux 7.3.0, local master
compiler:       gcc 11.4.0, GNU ld 2.38

console output:
https://gist.githubusercontent.com/shaos26/6522612a4cac2b4db3e4cfc32ec8ea8f/raw/5b12fad1d38c90b7a8214e02bffeb7bfd0994ebe/console-output.txt
kernel config:
https://gist.githubusercontent.com/shaos26/6522612a4cac2b4db3e4cfc32ec8ea8f/raw/f6506700a588fd394fdd662c4bd91115e0cb8c3b/kernel-config.txt
reproducer sources:
https://gist.githubusercontent.com/shaos26/ef3fd748f2329565eca96a4f4e3b2c85/raw/7694fd571c683bb1f98793979b7bf2fe09559bd4/poc.c
https://gist.githubusercontent.com/shaos26/ef3fd748f2329565eca96a4f4e3b2c85/raw/200625ab70731666abbb27f0e233a42626ac7c58/run-unpriv.c
https://gist.githubusercontent.com/shaos26/ef3fd748f2329565eca96a4f4e3b2c85/raw/7c17996d150eb55421fd88cf62b4a71b8ba14207/seed-secret.c

Build the tested kernel with the attached configuration and boot a disposable QEMU guest. The linked userspace sources seed the skb allocation, drop privileges, enter fresh user and network namespaces, install the action, and capture checksum responses.

Impact and prerequisites:
The checksum oracle consumes 42 bytes beyond the skb's logical data. In two fresh boots, checksum output matched the checksum of a marker seeded by a different initial-namespace UID in 75/512 and 85/512 trials; two wrong-pattern controls had 0/512 matches. This demonstrates that data from a prior root-owned skb allocation can influence output readable by an unprivileged namespace process. The oracle is limited; no arbitrary-address read or privilege escalation is demonstrated.

Validation: Two fresh user/network-namespace positives matched the root-seeded marker checksum in 75/512 and 85/512 trials. Two wrong-pattern controls returned 0/512 matches.

Thanks,

shaos

Re: [BUG] net/sched: act_csum can checksum beyond a short IPv6 jumbogram skb

[Andrew Lunn]

On Thu, Oct 22, 2026 at 02:46:53PM +0000, shaos wrote:
> Hello,
> 
> An unprivileged process with namespace-scoped CAP_NET_ADMIN and CAP_NET_RAW installs a csum action for UDP-Lite and sends a 300-byte IPv6 frame with a Jumbo Payload value of 0xffffffca and UDP-Lite coverage longer than the bytes present. The jumbo-length addition wraps the pull-length check, while the later checksum path still uses the unwrapped length.

Please configure your editor to wrap lines at around 70
characters. Standard netiquette rules should be used on mailing lists.

Flooding the netdev list with bug reports like this will just result
in them being directed to /dev/null.

If you want to do something useful, fix the issue. Please do it
slowly, one bug report at a time, so you can learn how to do it
correctly without wasting peoples time.

   Andrew

Re: [BUG] net/sched: act_csum can checksum beyond a short IPv6 jumbogram skb

[Jamal Hadi Salim]

On Thu, Oct 22, 2026 at 11:36 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Thu, Oct 22, 2026 at 02:46:53PM +0000, shaos wrote:
> > Hello,
> >
> > An unprivileged process with namespace-scoped CAP_NET_ADMIN and CAP_NET_RAW installs a csum action for UDP-Lite and sends a 300-byte IPv6 frame with a Jumbo Payload value of 0xffffffca and UDP-Lite coverage longer than the bytes present. The jumbo-length addition wraps the pull-length check, while the later checksum path still uses the unwrapped length.
>
> Please configure your editor to wrap lines at around 70
> characters. Standard netiquette rules should be used on mailing lists.
>
> Flooding the netdev list with bug reports like this will just result
> in them being directed to /dev/null.
>
> If you want to do something useful, fix the issue. Please do it
> slowly, one bug report at a time, so you can learn how to do it
> correctly without wasting peoples time.
>

And worse:
1) cross-posting to the security mailing list on bugs that require
CAP_NET_ADMIN and CAP_NET_RAW
2) Parroting quiet a few bugs that are already posted on the list and
undergoing revision adding more work to reviewers.

Which LLM do you use? Teach them to read the mailing list before
declaring an issue unknown. Just because it is not already patched in
the kernel does not mean work isn't already underway. If you fix these
issues, post again.

cheers,
jamal

>    Andrew