Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog<br /> <br /> Syzbot reported [1] crash that happens for following tracing scenario:<br /> <br /> - create tracepoint perf event with attr.inherit=1, attach it to the<br /> process and set bpf program to it<br /> - attached process forks -&gt; chid creates inherited event<br /> <br /> the new child event shares the parent&amp;#39;s bpf program and tp_event<br /> (hence prog_array) which is global for tracepoint<br /> <br /> - exit both process and its child -&gt; release both events<br /> - first perf_event_detach_bpf_prog call will release tp_event-&gt;prog_array<br /> and second perf_event_detach_bpf_prog will crash, because<br /> tp_event-&gt;prog_array is NULL<br /> <br /> The fix makes sure the perf_event_detach_bpf_prog checks prog_array<br /> is valid before it tries to remove the bpf program from it.<br /> <br /> [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer<br /> <br /> Considering that in some extreme cases,<br /> when u_serial driver is accessed by multiple threads,<br /> Thread A is executing the open operation and calling the gs_open,<br /> Thread B is executing the disconnect operation and calling the<br /> gserial_disconnect function,The port-&gt;port_usb pointer will be set to NULL.<br /> <br /> E.g.<br /> Thread A Thread B<br /> gs_open() gadget_unbind_driver()<br /> gs_start_io() composite_disconnect()<br /> gs_start_rx() gserial_disconnect()<br /> ... ...<br /> spin_unlock(&amp;port-&gt;port_lock)<br /> status = usb_ep_queue() spin_lock(&amp;port-&gt;port_lock)<br /> spin_lock(&amp;port-&gt;port_lock) port-&gt;port_usb = NULL<br /> gs_free_requests(port-&gt;port_usb-&gt;in) spin_unlock(&amp;port-&gt;port_lock)<br /> Crash<br /> <br /> This causes thread A to access a null pointer (port-&gt;port_usb is null)<br /> when calling the gs_free_requests function, causing a crash.<br /> <br /> If port_usb is NULL, the release request will be skipped as it<br /> will be done by gserial_disconnect.<br /> <br /> So add a null pointer check to gs_start_io before attempting<br /> to access the value of the pointer port-&gt;port_usb.<br /> <br /> Call trace:<br /> gs_start_io+0x164/0x25c<br /> gs_open+0x108/0x13c<br /> tty_open+0x314/0x638<br /> chrdev_open+0x1b8/0x258<br /> do_dentry_open+0x2c4/0x700<br /> vfs_open+0x2c/0x3c<br /> path_openat+0xa64/0xc60<br /> do_filp_open+0xb8/0x164<br /> do_sys_openat2+0x84/0xf0<br /> __arm64_sys_openat+0x70/0x9c<br /> invoke_syscall+0x58/0x114<br /> el0_svc_common+0x80/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x38/0x68

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 /> 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 /> Bluetooth: hci_event: Fix using rcu_read_(un)lock while iterating<br /> <br /> The usage of rcu_read_(un)lock while inside list_for_each_entry_rcu is<br /> not safe since for the most part entries fetched this way shall be<br /> treated as rcu_dereference:<br /> <br /> Note that the value returned by rcu_dereference() is valid<br /> only within the enclosing RCU read-side critical section [1]_.<br /> For example, the following is **not** legal::<br /> <br /> rcu_read_lock();<br /> p = rcu_dereference(head.next);<br /> rcu_read_unlock();<br /> x = p-&gt;address; /* BUG!!! */<br /> rcu_read_lock();<br /> y = p-&gt;data; /* BUG!!! */<br /> rcu_read_unlock();

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 /> bnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips<br /> <br /> The 5760X (P7) chip&amp;#39;s HW GRO/LRO interface is very similar to that of<br /> the previous generation (5750X or P5). However, the aggregation ID<br /> fields in the completion structures on P7 have been redefined from<br /> 16 bits to 12 bits. The freed up 4 bits are redefined for part of the<br /> metadata such as the VLAN ID. The aggregation ID mask was not modified<br /> when adding support for P7 chips. Including the extra 4 bits for the<br /> aggregation ID can potentially cause the driver to store or fetch the<br /> packet header of GRO/LRO packets in the wrong TPA buffer. It may hit<br /> the BUG() condition in __skb_pull() because the SKB contains no valid<br /> packet header:<br /> <br /> kernel BUG at include/linux/skbuff.h:2766!<br /> Oops: invalid opcode: 0000 1 PREEMPT SMP NOPTI<br /> CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Kdump: loaded Tainted: G OE 6.12.0-rc2+ #7<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: Dell Inc. PowerEdge R760/0VRV9X, BIOS 1.0.1 12/27/2022<br /> RIP: 0010:eth_type_trans+0xda/0x140<br /> Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 d0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48<br /> RSP: 0018:ff615003803fcc28 EFLAGS: 00010283<br /> RAX: 00000000000022d2 RBX: 0000000000000003 RCX: ff2e8c25da334040<br /> RDX: 0000000000000040 RSI: ff2e8c25c1ce8000 RDI: ff2e8c25869f9000<br /> RBP: ff2e8c258c31c000 R08: ff2e8c25da334000 R09: 0000000000000001<br /> R10: ff2e8c25da3342c0 R11: ff2e8c25c1ce89c0 R12: ff2e8c258e0990b0<br /> R13: ff2e8c25bb120000 R14: ff2e8c25c1ce89c0 R15: ff2e8c25869f9000<br /> FS: 0000000000000000(0000) GS:ff2e8c34be300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055f05317e4c8 CR3: 000000108bac6006 CR4: 0000000000773ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? die+0x33/0x90<br /> ? do_trap+0xd9/0x100<br /> ? eth_type_trans+0xda/0x140<br /> ? do_error_trap+0x65/0x80<br /> ? eth_type_trans+0xda/0x140<br /> ? exc_invalid_op+0x4e/0x70<br /> ? eth_type_trans+0xda/0x140<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? eth_type_trans+0xda/0x140<br /> bnxt_tpa_end+0x10b/0x6b0 [bnxt_en]<br /> ? bnxt_tpa_start+0x195/0x320 [bnxt_en]<br /> bnxt_rx_pkt+0x902/0xd90 [bnxt_en]<br /> ? __bnxt_tx_int.constprop.0+0x89/0x300 [bnxt_en]<br /> ? kmem_cache_free+0x343/0x440<br /> ? __bnxt_tx_int.constprop.0+0x24f/0x300 [bnxt_en]<br /> __bnxt_poll_work+0x193/0x370 [bnxt_en]<br /> bnxt_poll_p5+0x9a/0x300 [bnxt_en]<br /> ? try_to_wake_up+0x209/0x670<br /> __napi_poll+0x29/0x1b0<br /> <br /> Fix it by redefining the aggregation ID mask for P5_PLUS chips to be<br /> 12 bits. This will work because the maximum aggregation ID is less<br /> than 4096 on all P5_PLUS chips.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: control: Avoid WARN() for symlink errors<br /> <br /> Using WARN() for showing the error of symlink creations don&amp;#39;t give<br /> more information than telling that something goes wrong, since the<br /> usual code path is a lregister callback from each control element<br /> creation. More badly, the use of WARN() rather confuses fuzzer as if<br /> it were serious issues.<br /> <br /> This patch downgrades the warning messages to use the normal dev_err()<br /> instead of WARN(). For making it clearer, add the function name to<br /> the prefix, too.

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 /> net: lapb: increase LAPB_HEADER_LEN<br /> <br /> It is unclear if net/lapb code is supposed to be ready for 8021q.<br /> <br /> We can at least avoid crashes like the following :<br /> <br /> skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:206 !<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024<br /> RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]<br /> RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216<br /> Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3<br /> RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282<br /> RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600<br /> RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000<br /> RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60<br /> R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140<br /> R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016<br /> FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> skb_push+0xe5/0x100 net/core/skbuff.c:2636<br /> nr_header+0x36/0x320 net/netrom/nr_dev.c:69<br /> dev_hard_header include/linux/netdevice.h:3148 [inline]<br /> vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83<br /> dev_hard_header include/linux/netdevice.h:3148 [inline]<br /> lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257<br /> lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447<br /> lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149<br /> lapb_establish_data_link+0x84/0xd0<br /> lapb_device_event+0x4e0/0x670<br /> notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93<br /> __dev_notify_flags+0x207/0x400<br /> dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922<br /> devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188<br /> inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003<br /> sock_do_ioctl+0x158/0x460 net/socket.c:1227<br /> sock_ioctl+0x626/0x8e0 net/socket.c:1346<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83

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