Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: DR, prevent potential error pointer dereference<br /> <br /> The dr_domain_add_vport_cap() function generally returns NULL on error<br /> but sometimes we want it to return ERR_PTR(-EBUSY) so the caller can<br /> retry. The problem here is that "ret" can be either -EBUSY or -ENOMEM<br /> and if it&amp;#39;s and -ENOMEM then the error pointer is propogated back and<br /> eventually dereferenced in dr_ste_v0_build_src_gvmi_qpn_tag().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix NULL deref in cleanup_bearer()<br /> <br /> syzbot found [1] that after blamed commit, ub-&gt;ubsock-&gt;sk<br /> was NULL when attempting the atomic_dec() :<br /> <br /> atomic_dec(&amp;tipc_net(sock_net(ub-&gt;ubsock-&gt;sk))-&gt;wq_count);<br /> <br /> Fix this by caching the tipc_net pointer.<br /> <br /> [1]<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]<br /> CPU: 0 UID: 0 PID: 5896 Comm: kworker/0:3 Not tainted 6.13.0-rc1-next-20241203-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: events cleanup_bearer<br /> RIP: 0010:read_pnet include/net/net_namespace.h:387 [inline]<br /> RIP: 0010:sock_net include/net/sock.h:655 [inline]<br /> RIP: 0010:cleanup_bearer+0x1f7/0x280 net/tipc/udp_media.c:820<br /> Code: 18 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 3c f7 99 f6 48 8b 1b 48 83 c3 30 e8 f0 e4 60 00 48 89 d8 48 c1 e8 03 80 3c 28 00 74 08 48 89 df e8 1a f7 99 f6 49 83 c7 e8 48 8b 1b<br /> RSP: 0018:ffffc9000410fb70 EFLAGS: 00010206<br /> RAX: 0000000000000006 RBX: 0000000000000030 RCX: ffff88802fe45a00<br /> RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffc9000410f900<br /> RBP: ffff88807e1f0908 R08: ffffc9000410f907 R09: 1ffff92000821f20<br /> R10: dffffc0000000000 R11: fffff52000821f21 R12: ffff888031d19980<br /> R13: dffffc0000000000 R14: dffffc0000000000 R15: ffff88807e1f0918<br /> FS: 0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000556ca050b000 CR3: 0000000031c0c000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btmtk: avoid UAF in btmtk_process_coredump<br /> <br /> hci_devcd_append may lead to the release of the skb, so it cannot be<br /> accessed once it is called.<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in btmtk_process_coredump+0x2a7/0x2d0 [btmtk]<br /> Read of size 4 at addr ffff888033cfabb0 by task kworker/0:3/82<br /> <br /> CPU: 0 PID: 82 Comm: kworker/0:3 Tainted: G U 6.6.40-lockdep-03464-g1d8b4eb3060e #1 b0b3c1cc0c842735643fb411799d97921d1f688c<br /> Hardware name: Google Yaviks_Ufs/Yaviks_Ufs, BIOS Google_Yaviks_Ufs.15217.552.0 05/07/2024<br /> Workqueue: events btusb_rx_work [btusb]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xfd/0x150<br /> print_report+0x131/0x780<br /> kasan_report+0x177/0x1c0<br /> btmtk_process_coredump+0x2a7/0x2d0 [btmtk 03edd567dd71a65958807c95a65db31d433e1d01]<br /> btusb_recv_acl_mtk+0x11c/0x1a0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec]<br /> btusb_rx_work+0x9e/0xe0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec]<br /> worker_thread+0xe44/0x2cc0<br /> kthread+0x2ff/0x3a0<br /> ret_from_fork+0x51/0x80<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> Allocated by task 82:<br /> stack_trace_save+0xdc/0x190<br /> kasan_set_track+0x4e/0x80<br /> __kasan_slab_alloc+0x4e/0x60<br /> kmem_cache_alloc+0x19f/0x360<br /> skb_clone+0x132/0xf70<br /> btusb_recv_acl_mtk+0x104/0x1a0 [btusb]<br /> btusb_rx_work+0x9e/0xe0 [btusb]<br /> worker_thread+0xe44/0x2cc0<br /> kthread+0x2ff/0x3a0<br /> ret_from_fork+0x51/0x80<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> Freed by task 1733:<br /> stack_trace_save+0xdc/0x190<br /> kasan_set_track+0x4e/0x80<br /> kasan_save_free_info+0x28/0xb0<br /> ____kasan_slab_free+0xfd/0x170<br /> kmem_cache_free+0x183/0x3f0<br /> hci_devcd_rx+0x91a/0x2060 [bluetooth]<br /> worker_thread+0xe44/0x2cc0<br /> kthread+0x2ff/0x3a0<br /> ret_from_fork+0x51/0x80<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> The buggy address belongs to the object at ffff888033cfab40<br /> which belongs to the cache skbuff_head_cache of size 232<br /> The buggy address is located 112 bytes inside of<br /> freed 232-byte region [ffff888033cfab40, ffff888033cfac28)<br /> <br /> The buggy address belongs to the physical page:<br /> page:00000000a174ba93 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x33cfa<br /> head:00000000a174ba93 order:1 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> anon flags: 0x4000000000000840(slab|head|zone=1)<br /> page_type: 0xffffffff()<br /> raw: 4000000000000840 ffff888100848a00 0000000000000000 0000000000000001<br /> raw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888033cfaa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc<br /> ffff888033cfab00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb<br /> &gt;ffff888033cfab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff888033cfac00: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc<br /> ffff888033cfac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ==================================================================<br /> <br /> Check if we need to call hci_devcd_complete before calling<br /> hci_devcd_append. That requires that we check data-&gt;cd_info.cnt &gt;=<br /> MTK_COREDUMP_NUM instead of data-&gt;cd_info.cnt &gt; MTK_COREDUMP_NUM, as we<br /> increment data-&gt;cd_info.cnt only once the call to hci_devcd_append<br /> succeeds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/reg_sr: Remove register pool<br /> <br /> That pool implementation doesn&amp;#39;t really work: if the krealloc happens to<br /> move the memory and return another address, the entries in the xarray<br /> become invalid, leading to use-after-free later:<br /> <br /> BUG: KASAN: slab-use-after-free in xe_reg_sr_apply_mmio+0x570/0x760 [xe]<br /> Read of size 4 at addr ffff8881244b2590 by task modprobe/2753<br /> <br /> Allocated by task 2753:<br /> kasan_save_stack+0x39/0x70<br /> kasan_save_track+0x14/0x40<br /> kasan_save_alloc_info+0x37/0x60<br /> __kasan_kmalloc+0xc3/0xd0<br /> __kmalloc_node_track_caller_noprof+0x200/0x6d0<br /> krealloc_noprof+0x229/0x380<br /> <br /> Simplify the code to fix the bug. A better pooling strategy may be added<br /> back later if needed.<br /> <br /> (cherry picked from commit e5283bd4dfecbd3335f43b62a68e24dae23f59e4)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: defer final &amp;#39;struct net&amp;#39; free in netns dismantle<br /> <br /> Ilya reported a slab-use-after-free in dst_destroy [1]<br /> <br /> Issue is in xfrm6_net_init() and xfrm4_net_init() :<br /> <br /> They copy xfrm[46]_dst_ops_template into net-&gt;xfrm.xfrm[46]_dst_ops.<br /> <br /> But net structure might be freed before all the dst callbacks are<br /> called. So when dst_destroy() calls later :<br /> <br /> if (dst-&gt;ops-&gt;destroy)<br /> dst-&gt;ops-&gt;destroy(dst);<br /> <br /> dst-&gt;ops points to the old net-&gt;xfrm.xfrm[46]_dst_ops, which has been freed.<br /> <br /> See a relevant issue fixed in :<br /> <br /> ac888d58869b ("net: do not delay dst_entries_add() in dst_release()")<br /> <br /> A fix is to queue the &amp;#39;struct net&amp;#39; to be freed after one<br /> another cleanup_net() round (and existing rcu_barrier())<br /> <br /> [1]<br /> <br /> BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)<br /> Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0<br /> Dec 03 05:46:18 kernel:<br /> CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67<br /> Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:124)<br /> print_address_description.constprop.0 (mm/kasan/report.c:378)<br /> ? dst_destroy (net/core/dst.c:112)<br /> print_report (mm/kasan/report.c:489)<br /> ? dst_destroy (net/core/dst.c:112)<br /> ? kasan_addr_to_slab (mm/kasan/common.c:37)<br /> kasan_report (mm/kasan/report.c:603)<br /> ? dst_destroy (net/core/dst.c:112)<br /> ? rcu_do_batch (kernel/rcu/tree.c:2567)<br /> dst_destroy (net/core/dst.c:112)<br /> rcu_do_batch (kernel/rcu/tree.c:2567)<br /> ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491)<br /> ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406)<br /> rcu_core (kernel/rcu/tree.c:2825)<br /> handle_softirqs (kernel/softirq.c:554)<br /> __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637)<br /> irq_exit_rcu (kernel/softirq.c:651)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049)<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702)<br /> RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743)<br /> Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90<br /> RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246<br /> RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d<br /> R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000<br /> ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148)<br /> ? cpuidle_idle_call (kernel/sched/idle.c:186)<br /> default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)<br /> cpuidle_idle_call (kernel/sched/idle.c:186)<br /> ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168)<br /> ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848)<br /> ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406)<br /> ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59)<br /> do_idle (kernel/sched/idle.c:326)<br /> cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1))<br /> start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282)<br /> ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232)<br /> ? soft_restart_cpu (arch/x86/kernel/head_64.S:452)<br /> common_startup_64 (arch/x86/kernel/head_64.S:414)<br /> <br /> Dec 03 05:46:18 kernel:<br /> Allocated by task 12184:<br /> kasan_save_stack (mm/kasan/common.c:48)<br /> kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)<br /> __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)<br /> kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141)<br /> copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480)<br /> create_new_namespaces<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: do not defer rule destruction via call_rcu<br /> <br /> nf_tables_chain_destroy can sleep, it can&amp;#39;t be used from call_rcu<br /> callbacks.<br /> <br /> Moreover, nf_tables_rule_release() is only safe for error unwinding,<br /> while transaction mutex is held and the to-be-desroyed rule was not<br /> exposed to either dataplane or dumps, as it deactives+frees without<br /> the required synchronize_rcu() in-between.<br /> <br /> nft_rule_expr_deactivate() callbacks will change -&gt;use counters<br /> of other chains/sets, see e.g. nft_lookup .deactivate callback, these<br /> must be serialized via transaction mutex.<br /> <br /> Also add a few lockdep asserts to make this more explicit.<br /> <br /> Calling synchronize_rcu() isn&amp;#39;t ideal, but fixing this without is hard<br /> and way more intrusive. As-is, we can get:<br /> <br /> WARNING: .. net/netfilter/nf_tables_api.c:5515 nft_set_destroy+0x..<br /> Workqueue: events nf_tables_trans_destroy_work<br /> RIP: 0010:nft_set_destroy+0x3fe/0x5c0<br /> Call Trace:<br /> <br /> nf_tables_trans_destroy_work+0x6b7/0xad0<br /> process_one_work+0x64a/0xce0<br /> worker_thread+0x613/0x10d0<br /> <br /> In case the synchronize_rcu becomes an issue, we can explore alternatives.<br /> <br /> One way would be to allocate nft_trans_rule objects + one nft_trans_chain<br /> object, deactivate the rules + the chain and then defer the freeing to the<br /> nft destroy workqueue. We&amp;#39;d still need to keep the synchronize_rcu path as<br /> a fallback to handle -ENOMEM corner cases though.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ipv6: release expired exception dst cached in socket<br /> <br /> Dst objects get leaked in ip6_negative_advice() when this function is<br /> executed for an expired IPv6 route located in the exception table. There<br /> are several conditions that must be fulfilled for the leak to occur:<br /> * an ICMPv6 packet indicating a change of the MTU for the path is received,<br /> resulting in an exception dst being created<br /> * a TCP connection that uses the exception dst for routing packets must<br /> start timing out so that TCP begins retransmissions<br /> * after the exception dst expires, the FIB6 garbage collector must not run<br /> before TCP executes ip6_negative_advice() for the expired exception dst<br /> <br /> When TCP executes ip6_negative_advice() for an exception dst that has<br /> expired and if no other socket holds a reference to the exception dst, the<br /> refcount of the exception dst is 2, which corresponds to the increment<br /> made by dst_init() and the increment made by the TCP socket for which the<br /> connection is timing out. The refcount made by the socket is never<br /> released. The refcount of the dst is decremented in sk_dst_reset() but<br /> that decrement is counteracted by a dst_hold() intentionally placed just<br /> before the sk_dst_reset() in ip6_negative_advice(). After<br /> ip6_negative_advice() has finished, there is no other object tied to the<br /> dst. The socket lost its reference stored in sk_dst_cache and the dst is<br /> no longer in the exception table. The exception dst becomes a leaked<br /> object.<br /> <br /> As a result of this dst leak, an unbalanced refcount is reported for the<br /> loopback device of a net namespace being destroyed under kernels that do<br /> not contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"):<br /> unregister_netdevice: waiting for lo to become free. Usage count = 2<br /> <br /> Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). The<br /> patch that introduced the dst_hold() in ip6_negative_advice() was<br /> 92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22<br /> merely refactored the code with regards to the dst refcount so the issue<br /> was present even before 92f1655aa2b22. The bug was introduced in<br /> 54c1a859efd9f ("ipv6: Don&amp;#39;t drop cache route entry unless timer actually<br /> expired.") where the expired cached route is deleted and the sk_dst_cache<br /> member of the socket is set to NULL by calling dst_negative_advice() but<br /> the refcount belonging to the socket is left unbalanced.<br /> <br /> The IPv4 version - ipv4_negative_advice() - is not affected by this bug.<br /> When the TCP connection times out ipv4_negative_advice() merely resets the<br /> sk_dst_cache of the socket while decrementing the refcount of the<br /> exception dst.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: j1939: j1939_session_new(): fix skb reference counting<br /> <br /> Since j1939_session_skb_queue() does an extra skb_get() for each new<br /> skb, do the same for the initial one in j1939_session_new() to avoid<br /> refcount underflow.<br /> <br /> [mkl: clean up commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: avoid possible NULL deref in modify_prefix_route()<br /> <br /> syzbot found a NULL deref [1] in modify_prefix_route(), caused by one<br /> fib6_info without a fib6_table pointer set.<br /> <br /> This can happen for net-&gt;ipv6.fib6_null_entry<br /> <br /> [1]<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]<br /> CPU: 1 UID: 0 PID: 5837 Comm: syz-executor888 Not tainted 6.12.0-syzkaller-09567-g7eef7e306d3c #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> RIP: 0010:__lock_acquire+0xe4/0x3c40 kernel/locking/lockdep.c:5089<br /> Code: 08 84 d2 0f 85 15 14 00 00 44 8b 0d ca 98 f5 0e 45 85 c9 0f 84 b4 0e 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 3c 02 00 0f 85 96 2c 00 00 49 8b 04 24 48 3d a0 07 7f 93 0f 84<br /> RSP: 0018:ffffc900035d7268 EFLAGS: 00010006<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000006 RSI: 1ffff920006bae5f RDI: 0000000000000030<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001<br /> R10: ffffffff90608e17 R11: 0000000000000001 R12: 0000000000000030<br /> R13: ffff888036334880 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000555579e90380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007ffc59cc4278 CR3: 0000000072b54000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5849<br /> __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]<br /> _raw_spin_lock_bh+0x33/0x40 kernel/locking/spinlock.c:178<br /> spin_lock_bh include/linux/spinlock.h:356 [inline]<br /> modify_prefix_route+0x30b/0x8b0 net/ipv6/addrconf.c:4831<br /> inet6_addr_modify net/ipv6/addrconf.c:4923 [inline]<br /> inet6_rtm_newaddr+0x12c7/0x1ab0 net/ipv6/addrconf.c:5055<br /> rtnetlink_rcv_msg+0x3c7/0xea0 net/core/rtnetlink.c:6920<br /> netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2541<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]<br /> netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1347<br /> netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1891<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg net/socket.c:726 [inline]<br /> ____sys_sendmsg+0xaaf/0xc90 net/socket.c:2583<br /> ___sys_sendmsg+0x135/0x1e0 net/socket.c:2637<br /> __sys_sendmsg+0x16e/0x220 net/socket.c:2669<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fd1dcef8b79<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffc59cc4378 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd1dcef8b79<br /> RDX: 0000000000040040 RSI: 0000000020000140 RDI: 0000000000000004<br /> RBP: 00000000000113fd R08: 0000000000000006 R09: 0000000000000006<br /> R10: 0000000000000006 R11: 0000000000000246 R12: 00007ffc59cc438c<br /> R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Fix icmp host relookup triggering ip_rt_bug<br /> <br /> arp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:<br /> <br /> WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:ip_rt_bug+0x14/0x20<br /> Call Trace:<br /> <br /> ip_send_skb+0x14/0x40<br /> __icmp_send+0x42d/0x6a0<br /> ipv4_link_failure+0xe2/0x1d0<br /> arp_error_report+0x3c/0x50<br /> neigh_invalidate+0x8d/0x100<br /> neigh_timer_handler+0x2e1/0x330<br /> call_timer_fn+0x21/0x120<br /> __run_timer_base.part.0+0x1c9/0x270<br /> run_timer_softirq+0x4c/0x80<br /> handle_softirqs+0xac/0x280<br /> irq_exit_rcu+0x62/0x80<br /> sysvec_apic_timer_interrupt+0x77/0x90<br /> <br /> The script below reproduces this scenario:<br /> ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \<br /> dir out priority 0 ptype main flag localok icmp<br /> ip l a veth1 type veth<br /> ip a a 192.168.141.111/24 dev veth0<br /> ip l s veth0 up<br /> ping 192.168.141.155 -c 1<br /> <br /> icmp_route_lookup() create input routes for locally generated packets<br /> while xfrm relookup ICMP traffic.Then it will set input route<br /> (dst-&gt;out = ip_rt_bug) to skb for DESTUNREACH.<br /> <br /> For ICMP err triggered by locally generated packets, dst-&gt;dev of output<br /> route is loopback. Generally, xfrm relookup verification is not required<br /> on loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).<br /> <br /> Skip icmp relookup for locally generated packets to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: avoid potential out-of-bound access in fill_frame_info()<br /> <br /> syzbot is able to feed a packet with 14 bytes, pretending<br /> it is a vlan one.<br /> <br /> Since fill_frame_info() is relying on skb-&gt;mac_len already,<br /> extend the check to cover this case.<br /> <br /> BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline]<br /> BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724<br /> fill_frame_info net/hsr/hsr_forward.c:709 [inline]<br /> hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724<br /> hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235<br /> __netdev_start_xmit include/linux/netdevice.h:5002 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5011 [inline]<br /> xmit_one net/core/dev.c:3590 [inline]<br /> dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606<br /> __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434<br /> dev_queue_xmit include/linux/netdevice.h:3168 [inline]<br /> packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3146 [inline]<br /> packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:726<br /> __sys_sendto+0x594/0x750 net/socket.c:2197<br /> __do_sys_sendto net/socket.c:2204 [inline]<br /> __se_sys_sendto net/socket.c:2200 [inline]<br /> __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200<br /> x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slub.c:4091 [inline]<br /> slab_alloc_node mm/slub.c:4134 [inline]<br /> kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587<br /> __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678<br /> alloc_skb include/linux/skbuff.h:1323 [inline]<br /> alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612<br /> sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881<br /> packet_alloc_skb net/packet/af_packet.c:2995 [inline]<br /> packet_snd net/packet/af_packet.c:3089 [inline]<br /> packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x30f/0x380 net/socket.c:726<br /> __sys_sendto+0x594/0x750 net/socket.c:2197<br /> __do_sys_sendto net/socket.c:2204 [inline]<br /> __se_sys_sendto net/socket.c:2200 [inline]<br /> __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200<br /> x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: enetc: Do not configure preemptible TCs if SIs do not support<br /> <br /> Both ENETC PF and VF drivers share enetc_setup_tc_mqprio() to configure<br /> MQPRIO. And enetc_setup_tc_mqprio() calls enetc_change_preemptible_tcs()<br /> to configure preemptible TCs. However, only PF is able to configure<br /> preemptible TCs. Because only PF has related registers, while VF does not<br /> have these registers. So for VF, its hw-&gt;port pointer is NULL. Therefore,<br /> VF will access an invalid pointer when accessing a non-existent register,<br /> which will cause a crash issue. The simplified log is as follows.<br /> <br /> root@ls1028ardb:~# tc qdisc add dev eno0vf0 parent root handle 100: \<br /> mqprio num_tc 4 map 0 0 1 1 2 2 3 3 queues 1@0 1@1 1@2 1@3 hw 1<br /> [ 187.290775] Unable to handle kernel paging request at virtual address 0000000000001f00<br /> [ 187.424831] pc : enetc_mm_commit_preemptible_tcs+0x1c4/0x400<br /> [ 187.430518] lr : enetc_mm_commit_preemptible_tcs+0x30c/0x400<br /> [ 187.511140] Call trace:<br /> [ 187.513588] enetc_mm_commit_preemptible_tcs+0x1c4/0x400<br /> [ 187.518918] enetc_setup_tc_mqprio+0x180/0x214<br /> [ 187.523374] enetc_vf_setup_tc+0x1c/0x30<br /> [ 187.527306] mqprio_enable_offload+0x144/0x178<br /> [ 187.531766] mqprio_init+0x3ec/0x668<br /> [ 187.535351] qdisc_create+0x15c/0x488<br /> [ 187.539023] tc_modify_qdisc+0x398/0x73c<br /> [ 187.542958] rtnetlink_rcv_msg+0x128/0x378<br /> [ 187.547064] netlink_rcv_skb+0x60/0x130<br /> [ 187.550910] rtnetlink_rcv+0x18/0x24<br /> [ 187.554492] netlink_unicast+0x300/0x36c<br /> [ 187.558425] netlink_sendmsg+0x1a8/0x420<br /> [ 187.606759] ---[ end trace 0000000000000000 ]---<br /> <br /> In addition, some PFs also do not support configuring preemptible TCs,<br /> such as eno1 and eno3 on LS1028A. It won&amp;#39;t crash like it does for VFs,<br /> but we should prevent these PFs from accessing these unimplemented<br /> registers.