CVE-2023-52637 in Linux
Summary
by MITRE • 04/03/2024
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...) modifies jsk->filters while receiving packets.
Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
Read of size 4 at addr ffff888012144014 by task j1939/350
CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
__asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
j1939_sk_recv+0x20b/0x320 [can_j1939]
? __kasan_check_write+0x18/0x20 ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
? j1939_simple_recv+0x69/0x280 [can_j1939]
? j1939_ac_recv+0x5e/0x310 [can_j1939]
j1939_can_recv+0x43f/0x580 [can_j1939]
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
? raw_rcv+0x42/0x3c0 [can_raw]
? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
can_rcv_filter+0x11f/0x350 [can]
can_receive+0x12f/0x190 [can]
? __pfx_can_rcv+0x10/0x10 [can]
can_rcv+0xdd/0x130 [can]
? __pfx_can_rcv+0x10/0x10 [can]
__netif_receive_skb_one_core+0x13d/0x150 ? __pfx___netif_receive_skb_one_core+0x10/0x10 ? __kasan_check_write+0x18/0x20 ? _raw_spin_lock_irq+0x8c/0xe0 __netif_receive_skb+0x23/0xb0 process_backlog+0x107/0x260 __napi_poll+0x69/0x310 net_rx_action+0x2a1/0x580 ? __pfx_net_rx_action+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10 ? handle_irq_event+0x7d/0xa0 __do_softirq+0xf3/0x3f8 do_softirq+0x53/0x80 __local_bh_enable_ip+0x6e/0x70 netif_rx+0x16b/0x180 can_send+0x32b/0x520 [can]
? __pfx_can_send+0x10/0x10 [can]
? __check_object_size+0x299/0x410 raw_sendmsg+0x572/0x6d0 [can_raw]
? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
? apparmor_socket_sendmsg+0x2f/0x40 ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
sock_sendmsg+0xef/0x100 sock_write_iter+0x162/0x220 ? __pfx_sock_write_iter+0x10/0x10 ? __rtnl_unlock+0x47/0x80 ? security_file_permission+0x54/0x320 vfs_write+0x6ba/0x750 ? __pfx_vfs_write+0x10/0x10 ? __fget_light+0x1ca/0x1f0 ? __rcu_read_unlock+0x5b/0x280 ksys_write+0x143/0x170 ? __pfx_ksys_write+0x10/0x10 ? __kasan_check_read+0x15/0x20 ? fpregs_assert_state_consistent+0x62/0x70 __x64_sys_write+0x47/0x60 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6d/0x90 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x79/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Allocated by task 348: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x1f/0x30 __kasan_kmalloc+0xb5/0xc0 __kmalloc_node_track_caller+0x67/0x160 j1939_sk_setsockopt+0x284/0x450 [can_j1939]
__sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Freed by task 349: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_free_info+0x2f/0x50 __kasan_slab_free+0x12e/0x1c0 __kmem_cache_free+0x1b9/0x380 kfree+0x7a/0x120 j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
__sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/07/2025
The vulnerability CVE-2023-52637 represents a use-after-free condition within the Linux kernel's J1939 CAN protocol implementation, specifically affecting the j1939_sk_match_filter function during execution of the setsockopt system call with the SO_J1939_FILTER option. This flaw arises from insufficient synchronization mechanisms when modifying socket filter structures while concurrently processing incoming packets, creating a race condition that allows for memory corruption and potential privilege escalation. The issue manifests through KASAN (Kernel Address Sanitizer) reporting a slab-use-after-free error during j1939_sk_recv_match_one function execution, indicating that memory previously freed by one thread is accessed by another thread during packet reception. The root cause lies in the lack of proper locking around the jsk->filters structure, which is modified by the j1939_sk_setsockopt function while other threads may be reading from it during packet processing. This vulnerability directly maps to CWE-416 Use After Free, a well-documented weakness in software security that occurs when a program continues to use a pointer after the memory it points to has been freed. The attack scenario involves an attacker who can execute setsockopt with SO_J1939_FILTER on a J1939 socket, potentially triggering a race condition that results in memory corruption. The operational impact includes potential system crashes, denial of service, and in scenarios where the memory corruption affects critical kernel structures, arbitrary code execution. This vulnerability aligns with ATT&CK technique T1068, which involves exploiting legitimate credentials to gain access to privileged systems, as the flaw could be leveraged to escalate privileges within the kernel. The fix implemented involves adding appropriate locking mechanisms around the jsk->sk structure to prevent concurrent access during filter modifications, ensuring that packet reception threads cannot access freed memory. The patch follows standard kernel security practices by using spinlocks or mutexes to serialize access to shared data structures. The vulnerability affects all Linux kernel versions that support the J1939 CAN protocol implementation, particularly those using kernel versions 6.5 and earlier, making it a critical issue for embedded automotive systems, industrial control environments, and any systems utilizing J1939 protocol for vehicle communication. The security implications extend beyond simple denial of service, as the use-after-free condition could potentially be exploited to execute arbitrary code within kernel space, compromising the entire system integrity. The presence of this vulnerability in automotive and industrial environments is particularly concerning given the safety-critical nature of these systems and the potential for remote exploitation through network interfaces that support J1939 protocol communication. The fix demonstrates proper kernel security engineering by ensuring that concurrent access to socket filter structures is properly synchronized, preventing the race condition that led to the use-after-free scenario. This vulnerability highlights the importance of proper locking mechanisms in kernel space programming and the critical need for thorough testing of concurrent access patterns in network protocol implementations. The mitigation strategy involves applying the kernel patch that introduces the necessary locking around socket filter modifications, ensuring that no thread can modify the filter structure while another thread is accessing it during packet reception, thus preventing the use-after-free condition from occurring.