CVE-2024-46782 in Linux
Summary
by MITRE • 09/18/2024
In the Linux kernel, the following vulnerability has been resolved:
ila: call nf_unregister_net_hooks() sooner
syzbot found an use-after-free Read in ila_nf_input [1]
Issue here is that ila_xlat_exit_net() frees the rhashtable, then call nf_unregister_net_hooks().
It should be done in the reverse way, with a synchronize_rcu().
This is a good match for a pre_exit() method.
[1]
BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]
BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]
BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]
BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16
CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline]
print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rht_key_hashfn include/linux/rhashtable.h:159 [inline]
__rhashtable_lookup include/linux/rhashtable.h:604 [inline]
rhashtable_lookup include/linux/rhashtable.h:646 [inline]
rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]
ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]
ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline]
NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [inline]
__netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline]
net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620 flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) page_type: 0xbfffffff(buddy) raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000 raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187 set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 prep_new_page mm/page_alloc.c:1501 [inline]
get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103 __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [inline]
__kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [inline]
rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071 ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613 ops_ini ---truncated---
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/21/2026
The vulnerability described in CVE-2024-46782 affects the Linux kernel's Ingress Layer Access (ILA) module, specifically within the network filtering subsystem. This issue arises from an improper sequence of operations during the cleanup of network hooks and hash table resources, leading to a use-after-free condition. The root cause is in the `ila_xlat_exit_net()` function, where the rhashtable is freed before `nf_unregister_net_hooks()` is called, creating a race condition that allows network hook functions to access freed memory. This misordering violates standard kernel cleanup practices and introduces a potential attack vector for privilege escalation or denial of service. The vulnerability was identified by syzbot, a kernel fuzzer, which detected a KASAN (Kernel Address Sanitizer) report indicating a use-after-free read operation during network packet processing.
The technical flaw manifests in the incorrect resource management order within the ILA module's network namespace cleanup routine. When `ila_xlat_exit_net()` is invoked during network namespace destruction, it first frees the rhashtable data structure and then calls `nf_unregister_net_hooks()` to remove the network hooks. This sequence creates a window where network packets can still be processed by hook functions that reference the now-freed hash table entries. The system uses a `rhashtable_lookup_fast` function to access hash table entries, which triggers the use-after-free when the underlying memory has already been deallocated. The call trace shows that the access occurs during `ila_nf_input`, a network hook function, when processing packets through the softirq context, indicating that the vulnerability can be exploited during active network traffic processing. This pattern aligns with CWE-416: Use After Free, a common vulnerability in kernel memory management.
The operational impact of this vulnerability is significant, as it can lead to system instability, potential privilege escalation, or denial of service conditions. An attacker could potentially exploit this condition to cause kernel crashes or execute arbitrary code with kernel privileges. The vulnerability is particularly concerning because it affects network packet processing functions that are invoked frequently, making it a high-risk issue for network servers and systems handling substantial traffic. The use-after-free condition can result in memory corruption that may be leveraged to gain unauthorized access to system resources or disrupt network services. The specific context where this occurs is during network namespace cleanup, which means it can be triggered by network configuration changes, container operations, or system shutdown procedures. The vulnerability represents a failure to properly synchronize resource cleanup operations, which is a fundamental requirement for kernel stability and security.
Mitigation strategies for this vulnerability involve correcting the resource cleanup sequence in the ILA module to ensure proper ordering of operations. The fix requires calling `nf_unregister_net_hooks()` before freeing the rhashtable and ensuring appropriate synchronization mechanisms such as `synchronize_rcu()` are employed to prevent hook functions from accessing freed memory. The recommended approach is to implement a pre_exit() method pattern that properly sequences the cleanup operations and ensures all network hooks are unregistered before any associated data structures are freed. Kernel developers should also consider adding additional validation checks and memory barriers to prevent similar issues in other network subsystem modules. System administrators should apply the relevant kernel patches as soon as they become available, and monitor for any unusual network behavior or system instability that might indicate exploitation attempts. This vulnerability underscores the importance of following established kernel development practices for resource management and proper synchronization, as outlined in the Linux kernel documentation and security guidelines. The fix aligns with ATT&CK technique T1068: Exploitation for Privilege Escalation, as it addresses a memory corruption vulnerability that could be leveraged for elevated privileges.