Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: route: hold key-&gt;lock in mctp_flow_prepare_output()<br /> <br /> mctp_flow_prepare_output() checks key-&gt;dev and may call<br /> mctp_dev_set_key(), but it does not hold key-&gt;lock while doing so.<br /> <br /> mctp_dev_set_key() and mctp_dev_release_key() are annotated with<br /> __must_hold(&amp;key-&gt;lock), so key-&gt;dev access is intended to be<br /> serialized by key-&gt;lock. The mctp_sendmsg() transmit path reaches<br /> mctp_flow_prepare_output() via mctp_local_output() -&gt; mctp_dst_output()<br /> without holding key-&gt;lock, so the check-and-set sequence is racy.<br /> <br /> Example interleaving:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> mctp_flow_prepare_output(key, devA)<br /> if (!key-&gt;dev) // sees NULL<br /> mctp_flow_prepare_output(<br /> key, devB)<br /> if (!key-&gt;dev) // still NULL<br /> mctp_dev_set_key(devB, key)<br /> mctp_dev_hold(devB)<br /> key-&gt;dev = devB<br /> mctp_dev_set_key(devA, key)<br /> mctp_dev_hold(devA)<br /> key-&gt;dev = devA // overwrites devB<br /> <br /> Now both devA and devB references were acquired, but only the final<br /> key-&gt;dev value is tracked for release. One reference can be lost,<br /> causing a resource leak as mctp_dev_release_key() would only decrease<br /> the reference on one dev.<br /> <br /> Fix by taking key-&gt;lock around the key-&gt;dev check and<br /> mctp_dev_set_key() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: fix type confusion in bond_setup_by_slave()<br /> <br /> kernel BUG at net/core/skbuff.c:2306!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306<br /> RSP: 0018:ffffc90004aff760 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e<br /> RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900<br /> RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780<br /> R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900<br /> dev_hard_header include/linux/netdevice.h:3439 [inline]<br /> packet_snd net/packet/af_packet.c:3028 [inline]<br /> packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg net/socket.c:742 [inline]<br /> ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592<br /> ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646<br /> __sys_sendmsg+0x170/0x220 net/socket.c:2678<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fe1a0e6c1a9<br /> <br /> When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond,<br /> bond_setup_by_slave() directly copies the slave&amp;#39;s header_ops to the<br /> bond device:<br /> <br /> bond_dev-&gt;header_ops = slave_dev-&gt;header_ops;<br /> <br /> This causes a type confusion when dev_hard_header() is later called<br /> on the bond device. Functions like ipgre_header(), ip6gre_header(),all use<br /> netdev_priv(dev) to access their device-specific private data. When<br /> called with the bond device, netdev_priv() returns the bond&amp;#39;s private<br /> data (struct bonding) instead of the expected type (e.g. struct<br /> ip_tunnel), leading to garbage values being read and kernel crashes.<br /> <br /> Fix this by introducing bond_header_ops with wrapper functions that<br /> delegate to the active slave&amp;#39;s header_ops using the slave&amp;#39;s own<br /> device. This ensures netdev_priv() in the slave&amp;#39;s header functions<br /> always receives the correct device.<br /> <br /> The fix is placed in the bonding driver rather than individual device<br /> drivers, as the root cause is bond blindly inheriting header_ops from<br /> the slave without considering that these callbacks expect a specific<br /> netdev_priv() layout.<br /> <br /> The type confusion can be observed by adding a printk in<br /> ipgre_header() and running the following commands:<br /> <br /> ip link add dummy0 type dummy<br /> ip addr add 10.0.0.1/24 dev dummy0<br /> ip link set dummy0 up<br /> ip link add gre1 type gre local 10.0.0.1<br /> ip link add bond1 type bond mode active-backup<br /> ip link set gre1 master bond1<br /> ip link set gre1 up<br /> ip link set bond1 up<br /> ip addr add fe80::1/64 dev bond1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: i2c: fix skb memory leak in receive path<br /> <br /> When &amp;#39;midev-&gt;allow_rx&amp;#39; is false, the newly allocated skb isn&amp;#39;t consumed<br /> by netif_rx(), it needs to free the skb directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: caif: hold tty-&gt;link reference in ldisc_open and ser_release<br /> <br /> A reproducer triggers a KASAN slab-use-after-free in pty_write_room()<br /> when caif_serial&amp;#39;s TX path calls tty_write_room(). The faulting access<br /> is on tty-&gt;link-&gt;port.<br /> <br /> Hold an extra kref on tty-&gt;link for the lifetime of the caif_serial line<br /> discipline: get it in ldisc_open() and drop it in ser_release(), and<br /> also drop it on the ldisc_open() error path.<br /> <br /> With this change applied, the reproducer no longer triggers the UAF in<br /> my testing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-core: flush delayed work before removing DAIs and widgets<br /> <br /> When a sound card is unbound while a PCM stream is open, a<br /> use-after-free can occur in snd_soc_dapm_stream_event(), called from<br /> the close_delayed_work workqueue handler.<br /> <br /> During unbind, snd_soc_unbind_card() flushes delayed work and then<br /> calls soc_cleanup_card_resources(). Inside cleanup,<br /> snd_card_disconnect_sync() releases all PCM file descriptors, and<br /> the resulting PCM close path can call snd_soc_dapm_stream_stop()<br /> which schedules new delayed work with a pmdown_time timer delay.<br /> Since this happens after the flush in snd_soc_unbind_card(), the<br /> new work is not caught. soc_remove_link_components() then frees<br /> DAPM widgets before this work fires, leading to the use-after-free.<br /> <br /> The existing flush in soc_free_pcm_runtime() also cannot help as it<br /> runs after soc_remove_link_components() has already freed the widgets.<br /> <br /> Add a flush in soc_cleanup_card_resources() after<br /> snd_card_disconnect_sync() (after which no new PCM closes can<br /> schedule further delayed work) and before soc_remove_link_dais()<br /> and soc_remove_link_components() (which tear down the structures the<br /> delayed work accesses).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: rockchip-sfc: Fix double-free in remove() callback<br /> <br /> The driver uses devm_spi_register_controller() for registration, which<br /> automatically unregisters the controller via devm cleanup when the<br /> device is removed. The manual call to spi_unregister_controller() in<br /> the remove() callback can lead to a double-free.<br /> <br /> And to make sure controller is unregistered before DMA buffer is<br /> unmapped, switch to use spi_register_controller() in probe().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: amlogic: spifc-a4: Fix DMA mapping error handling<br /> <br /> Fix three bugs in aml_sfc_dma_buffer_setup() error paths:<br /> 1. Unnecessary goto: When the first DMA mapping (sfc-&gt;daddr) fails,<br /> nothing needs cleanup. Use direct return instead of goto.<br /> 2. Double-unmap bug: When info DMA mapping failed, the code would<br /> unmap sfc-&gt;daddr inline, then fall through to out_map_data which<br /> would unmap it again, causing a double-unmap.<br /> 3. Wrong unmap size: The out_map_info label used datalen instead of<br /> infolen when unmapping sfc-&gt;iaddr, which could lead to incorrect<br /> DMA sync behavior.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix runtime suspend deadlock when there is pending job<br /> <br /> The runtime suspend callback drains the running job workqueue before<br /> suspending the device. If a job is still executing and calls<br /> pm_runtime_resume_and_get(), it can deadlock with the runtime suspend<br /> path.<br /> <br /> Fix this by moving pm_runtime_resume_and_get() from the job execution<br /> routine to the job submission routine, ensuring the device is resumed<br /> before the job is queued and avoiding the deadlock during runtime<br /> suspend.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: fix PTP use-after-free during reset<br /> <br /> Commit 7c01dbfc8a1c5f ("iavf: periodically cache PHC time") introduced a<br /> worker to cache PHC time, but failed to stop it during reset or disable.<br /> <br /> This creates a race condition where `iavf_reset_task()` or<br /> `iavf_disable_vf()` free adapter resources (AQ) while the worker is still<br /> running. If the worker triggers `iavf_queue_ptp_cmd()` during teardown, it<br /> accesses freed memory/locks, leading to a crash.<br /> <br /> Fix this by calling `iavf_ptp_release()` before tearing down the adapter.<br /> This ensures `ptp_clock_unregister()` synchronously cancels the worker and<br /> cleans up the chardev before the backing resources are destroyed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: Fix race bug in nvme_poll_irqdisable()<br /> <br /> In the following scenario, pdev can be disabled between (1) and (3) by<br /> (2). This sets pdev-&gt;msix_enabled = 0. Then, pci_irq_vector() will<br /> return MSI-X IRQ(&gt;15) for (1) whereas return INTx IRQ(cq_vector)) ...(1)<br /> enable_irq(pci_irq_vector(pdev, nvmeq-&gt;cq_vector)) ...(3)<br /> <br /> task 2:<br /> nvme_reset_work()<br /> nvme_dev_disable()<br /> pdev-&gt;msix_enable = 0; ...(2)<br /> <br /> crash log:<br /> <br /> ------------[ cut here ]------------<br /> Unbalanced enable for IRQ 10<br /> WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: kblockd blk_mq_timeout_work<br /> RIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753<br /> Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9<br /> RSP: 0018:ffffc900001bf550 EFLAGS: 00010046<br /> RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90<br /> RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0<br /> RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001<br /> R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000<br /> R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293<br /> FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> enable_irq+0x121/0x1e0 kernel/irq/manage.c:797<br /> nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494<br /> nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744<br /> blk_mq_rq_timed_out block/blk-mq.c:1653 [inline]<br /> blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721<br /> bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292<br /> __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline]<br /> sbitmap_for_each_set include/linux/sbitmap.h:290 [inline]<br /> bt_for_each block/blk-mq-tag.c:324 [inline]<br /> blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536<br /> blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763<br /> process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x65c/0xe60 kernel/workqueue.c:3421<br /> kthread+0x41a/0x930 kernel/kthread.c:463<br /> ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> irq event stamp: 74478<br /> hardirqs last enabled at (74477): [] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]<br /> hardirqs last enabled at (74477): [] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202<br /> hardirqs last disabled at (74478): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]<br /> hardirqs last disabled at (74478): [] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162<br /> softirqs last enabled at (74304): [] __do_softirq kernel/softirq.c:656 [inline]<br /> softirqs last enabled at (74304): [] invoke_softirq kernel/softirq.c:496 [inline]<br /> softirqs last enabled at (74304): [] __irq_exit_rcu+0xdc/0x120<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_set<br /> <br /> dev-&gt;online_queues is a count incremented in nvme_init_queue. Thus,<br /> valid indices are 0 through dev-&gt;online_queues − 1.<br /> <br /> This patch fixes the loop condition to ensure the index stays within the<br /> valid range. Index 0 is excluded because it is the admin queue.<br /> <br /> KASAN splat:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline]<br /> BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404<br /> Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74<br /> <br /> CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: nvme-reset-wq nvme_reset_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xce/0x5d0 mm/kasan/report.c:482<br /> kasan_report+0xdc/0x110 mm/kasan/report.c:595<br /> __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379<br /> nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline]<br /> nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404<br /> nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252<br /> process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x65c/0xe60 kernel/workqueue.c:3421<br /> kthread+0x41a/0x930 kernel/kthread.c:463<br /> ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> <br /> Allocated by task 34 on cpu 1 at 4.241550s:<br /> kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57<br /> kasan_save_track+0x1c/0x70 mm/kasan/common.c:78<br /> kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570<br /> poison_kmalloc_redzone mm/kasan/common.c:398 [inline]<br /> __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415<br /> kasan_kmalloc include/linux/kasan.h:263 [inline]<br /> __do_kmalloc_node mm/slub.c:5657 [inline]<br /> __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663<br /> kmalloc_array_node_noprof include/linux/slab.h:1075 [inline]<br /> nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline]<br /> nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534<br /> local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324<br /> pci_call_probe drivers/pci/pci-driver.c:392 [inline]<br /> __pci_device_probe drivers/pci/pci-driver.c:417 [inline]<br /> pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451<br /> call_driver_probe drivers/base/dd.c:583 [inline]<br /> really_probe+0x29b/0xb70 drivers/base/dd.c:661<br /> __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803<br /> driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833<br /> __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159<br /> async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129<br /> process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257<br /> process_scheduled_works kernel/workqueue.c:3340 [inline]<br /> worker_thread+0x65c/0xe60 kernel/workqueue.c:3421<br /> kthread+0x41a/0x930 kernel/kthread.c:463<br /> ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> The buggy address belongs to the object at ffff88800592a000<br /> which belongs to the cache kmalloc-2k of size 2048<br /> The buggy address is located 244 bytes to the right of<br /> allocated 1152-byte region [ffff88800592a000, ffff88800592a480)<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928<br /> head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff)<br /> page_type: f5(slab)<br /> raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001<br /> raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000<br /> head: 000fffffc0000040 ffff888001042000 00000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_cthelper: fix OOB read in nfnl_cthelper_dump_table()<br /> <br /> nfnl_cthelper_dump_table() has a &amp;#39;goto restart&amp;#39; that jumps to a label<br /> inside the for loop body. When the "last" helper saved in cb-&gt;args[1]<br /> is deleted between dump rounds, every entry fails the (cur != last)<br /> check, so cb-&gt;args[1] is never cleared. The for loop finishes with<br /> cb-&gt;args[0] == nf_ct_helper_hsize, and the &amp;#39;goto restart&amp;#39; jumps back<br /> into the loop body bypassing the bounds check, causing an 8-byte<br /> out-of-bounds read on nf_ct_helper_hash[nf_ct_helper_hsize].<br /> <br /> The &amp;#39;goto restart&amp;#39; block was meant to re-traverse the current bucket<br /> when "last" is no longer found, but it was placed after the for loop<br /> instead of inside it. Move the block into the for loop body so that<br /> the restart only occurs while cb-&gt;args[0] is still within bounds.<br /> <br /> BUG: KASAN: slab-out-of-bounds in nfnl_cthelper_dump_table+0x9f/0x1b0<br /> Read of size 8 at addr ffff888104ca3000 by task poc_cthelper/131<br /> Call Trace:<br /> nfnl_cthelper_dump_table+0x9f/0x1b0<br /> netlink_dump+0x333/0x880<br /> netlink_recvmsg+0x3e2/0x4b0<br /> sock_recvmsg+0xde/0xf0<br /> __sys_recvfrom+0x150/0x200<br /> __x64_sys_recvfrom+0x76/0x90<br /> do_syscall_64+0xc3/0x6e0<br /> <br /> Allocated by task 1:<br /> __kvmalloc_node_noprof+0x21b/0x700<br /> nf_ct_alloc_hashtable+0x65/0xd0<br /> nf_conntrack_helper_init+0x21/0x60<br /> nf_conntrack_init_start+0x18d/0x300<br /> nf_conntrack_standalone_init+0x12/0xc0