This post dives deep into CVE-2024-40960, a critical bug in the Linux kernel's IPv6 code that could lead to a crash and possible system instability. We'll go through what happened, why it was dangerous, how it got fixed, and show you details straight from the actual kernel code and logs.
What is CVE-2024-40960?
On recent Linux versions (6.10-rc2 and likely earlier), a serious bug in the networking stack was uncovered by automated fuzz testing (using syzbot). In short: The kernel could try to use a pointer that wasn’t set, leading to a NULL pointer dereference and an instant system crash.
This could be triggered via manipulation of IPv6 routes by a local user or process — no special hardware or root required in some cases.
The bug was in the function rt6_probe() inside net/ipv6/route.c. If __in6_dev_get() returned NULL (which can happen in some corner cases involving network devices), the code wouldn’t check before using the result, leading to a kernel panic.
It calls __in6_dev_get() to get IPv6 device info needed for routing decisions.
- On some events (like device changes, or address removal), __in6_dev_get() can return NULL (meaning info doesn't exist).
Crash log snippet (from syzbot)
Oops: general protection fault, probably for non-canonical address xdffffc00000000cb: 000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [x0000000000000658-x000000000000065f]
...
RIP: 001:rt6_probe net/ipv6/route.c:656 [inline]
...
Code: ... f b6 14 02 ... 38 d 7c 08 84 d2 f 85 19
...
Call Trace:
rt6_nh_find_match+xfa/x1a net/ipv6/route.c:784
...
Translation: The kernel accessed memory it shouldn't (address ending with "cb"), caused by dereferencing a NULL pointer returned from __in6_dev_get().
Where Was The Bug in the Code?
Before the fix: (Bad)
struct in6_device *idev = __in6_dev_get(dev);
/* ... no NULL check ... */
if (idev->cnf.forwarding)
... // use 'idev'
The kernel developers patched rt6_probe() to safely handle this corner case
After the fix: (Good)
struct in6_device *idev = __in6_dev_get(dev);
if (!idev) // <--- THE FIX!
return; // Bail out if no device info
if (idev->cnf.forwarding)
... // safe to use 'idev' now
How Was This Vulnerability Triggered?
The bug was most easily found using syzbot, an automated tool that fuzzes kernel interfaces. However, with knowledge of the code, an attacker (or accidental local process) could provoke the crash by:
Causing route probes (rt6_probe) while the device is in an inconsistent state.
4. Result: The kernel would try to access device-specific IPv6 info that wasn’t initialized, leading to panic.
Sample userspace steps
ip link add dummy type dummy
ip link set dummy up
ip -6 addr add 2001:db8::1/64 dev dummy
ip -6 addr del 2001:db8::1/64 dev dummy
# ... force a IPv6 route probe via pings/other traffic ...
What's the risk?
- Any unprivileged user or process able to manipulate IPv6 addresses/routes might trigger this bug and crash the system (Denial of Service).
- There is no direct info leak or privilege escalation, but crashing production servers could have huge impact.
Linux kernel v6.10-rc2 and likely earlier (upstream mainline).
- Distros might backport this bug — check your vendor’s security advisories if you run custom or rolling kernels.
Patch & Mitigation
- Patch available: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6e2e669ed592
Mitigation: Upgrade to a kernel including this fix, or apply the patch and rebuild.
- Workaround: If you can't upgrade immediately, restricting IPv6 network manipulations and network namespaces for untrusted users can reduce risk.
References
- Upstream commit fixing CVE-2024-40960
- syzbot crash report (example, may not be persistent)
- Linux Kernel Mailing List
- CVE entry (MITRE) (may not be published yet)
Simple Summary
- CVE-2024-40960 is a Linux IPv6 network bug where the kernel could crash due to not checking for a missing device info structure.
Upgrade your kernel, especially if your systems depend on IPv6 or allow non-root network activity.
Stay safe! If you run Linux servers or desktops, make sure your system is up to date, especially on networking and kernel security patches.
If you have kernel development or security responsibilities, the diff for the official fix is a must-see.
Share with your team – and keep an eye out for more memory safety issues in the networking stack!
Timeline
Published on: 07/12/2024 13:15:18 UTC
Last modified on: 08/21/2024 16:53:01 UTC