PT-2026-64657 · Linux · Linux

CVE-2026-64436

·

Published

2026-07-25

·

Updated

2026-07-25

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
net: af key: initialize alg key len for IPComp states
pfkey msg2xfrm state() handles the IPComp (SADB X SATYPE IPCOMP) case by allocating x->calg and copying only the algorithm name:
x->calg = kmalloc obj(*x->calg);
if (!x->calg) {
	err = -ENOMEM;
	goto out;
}
strcpy(x->calg->alg name, a->name);
x->props.calgo = sa->sadb sa encrypt;
Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->alg key len. IPComp carries no key and the allocation only reserves sizeof(struct xfrm algo) (i.e. no room for a key), so the field is left containing uninitialized slab data.
calg->alg key len is later used as a length by xfrm algo clone() when an IPComp state is cloned during XFRM MSG MIGRATE:
xfrm state migrate()
 xfrm state clone and setup()
  x->calg = xfrm algo clone(orig->calg);
   kmemdup(orig, xfrm alg len(orig));
where xfrm alg len() returns sizeof(*alg) + (alg key len + 7) / 8. With a non-zero garbage alg key len, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PF KEY and then migrating it triggers (net-next, KASAN, init on alloc=0):
BUG: KASAN: slab-out-of-bounds in kmemdup noprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: dump stack lvl+0x10e/0x1f0 print report+0xf7/0x600 kasan report+0xe4/0x120 kasan check range+0x105/0x1b0 asan memcpy+0x23/0x60 kmemdup noprof+0x44/0x60 xfrm state migrate+0x70a/0x1da0 xfrm migrate+0x753/0x18a0 xfrm do migrate+0xb47/0xf10 xfrm user rcv msg+0x411/0xb50 netlink rcv skb+0x158/0x420 xfrm netlink rcv+0x71/0x90 netlink unicast+0x584/0x850 netlink sendmsg+0x8b0/0xdc0 sys sendmsg+0x9f7/0xb90 sys sendmsg+0x134/0x1d0 sys sendmsg+0x16d/0x220 do syscall 64+0x116/0x7d0 entry SYSCALL 64 after hwframe+0x77/0x7f
Allocated by task 9287: kasan save stack+0x33/0x60 kasan save track+0x14/0x30 kasan kmalloc+0xaa/0xb0 pfkey add+0x2652/0x2ea0 pfkey process+0x6d0/0x830 pfkey sendmsg+0x42c/0x850 sys sendto+0x461/0x4b0 x64 sys sendto+0xe0/0x1c0 do syscall 64+0x116/0x7d0 entry SYSCALL 64 after hwframe+0x77/0x7f
The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4)
Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail.
The XFRM netlink path is not affected: verify one alg() rejects an XFRMA ALG COMP attribute shorter than xfrm alg len(), so a calg added via XFRM MSG NEWSA is always self-consistent.
Initialize calg->alg key len to 0, matching the aalg/ealg branches.
Found an issue in the description? Have something to add? Feel free to write us 👾
dbugs@ptsecurity.com

Related Identifiers

CVE-2026-64436

Affected Products

Linux