Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa/mlx5: Fix release of uninitialized resources on error path<br /> <br /> The commit in the fixes tag made sure that mlx5_vdpa_free()<br /> is the single entrypoint for removing the vdpa device resources<br /> added in mlx5_vdpa_dev_add(), even in the cleanup path of<br /> mlx5_vdpa_dev_add().<br /> <br /> This means that all functions from mlx5_vdpa_free() should be able to<br /> handle uninitialized resources. This was not the case though:<br /> mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx()<br /> were not able to do so. This caused the splat below when adding<br /> a vdpa device without a MAC address.<br /> <br /> This patch fixes these remaining issues:<br /> <br /> - Makes mlx5_vdpa_destroy_mr_resources() return early if called on<br /> uninitialized resources.<br /> <br /> - Moves mlx5_cmd_init_async_ctx() early on during device addition<br /> because it can&amp;#39;t fail. This means that mlx5_cmd_cleanup_async_ctx()<br /> also can&amp;#39;t fail. To mirror this, move the call site of<br /> mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free().<br /> <br /> An additional comment was added in mlx5_vdpa_free() to document<br /> the expectations of functions called from this context.<br /> <br /> Splat:<br /> <br /> mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned?<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0<br /> [...]<br /> Call Trace:<br /> <br /> ? __try_to_del_timer_sync+0x61/0x90<br /> ? __timer_delete_sync+0x2b/0x40<br /> mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa]<br /> mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa]<br /> vdpa_release_dev+0x1e/0x50 [vdpa]<br /> device_release+0x31/0x90<br /> kobject_cleanup+0x37/0x130<br /> mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa]<br /> vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa]<br /> genl_family_rcv_msg_doit+0xd8/0x130<br /> genl_family_rcv_msg+0x14b/0x220<br /> ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa]<br /> genl_rcv_msg+0x47/0xa0<br /> ? __pfx_genl_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x53/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x27b/0x3b0<br /> netlink_sendmsg+0x1f7/0x430<br /> __sys_sendto+0x1fa/0x210<br /> ? ___pte_offset_map+0x17/0x160<br /> ? next_uptodate_folio+0x85/0x2b0<br /> ? percpu_counter_add_batch+0x51/0x90<br /> ? filemap_map_pages+0x515/0x660<br /> __x64_sys_sendto+0x20/0x30<br /> do_syscall_64+0x7b/0x2c0<br /> ? do_read_fault+0x108/0x220<br /> ? do_pte_missing+0x14a/0x3e0<br /> ? __handle_mm_fault+0x321/0x730<br /> ? count_memcg_events+0x13f/0x180<br /> ? handle_mm_fault+0x1fb/0x2d0<br /> ? do_user_addr_fault+0x20c/0x700<br /> ? syscall_exit_work+0x104/0x140<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f0c25b0feca<br /> [...]<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb: scarlett2: Fix missing NULL check<br /> <br /> scarlett2_input_select_ctl_info() sets up the string arrays allocated<br /> via kasprintf(), but it misses NULL checks, which may lead to NULL<br /> dereference Oops. Let&amp;#39;s add the proper NULL check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx95-blk-ctl: Fix synchronous abort<br /> <br /> When enabling runtime PM for clock suppliers that also belong to a power<br /> domain, the following crash is thrown:<br /> error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP<br /> Workqueue: events_unbound deferred_probe_work_func<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : clk_mux_get_parent+0x60/0x90<br /> lr : clk_core_reparent_orphans_nolock+0x58/0xd8<br /> Call trace:<br /> clk_mux_get_parent+0x60/0x90<br /> clk_core_reparent_orphans_nolock+0x58/0xd8<br /> of_clk_add_hw_provider.part.0+0x90/0x100<br /> of_clk_add_hw_provider+0x1c/0x38<br /> imx95_bc_probe+0x2e0/0x3f0<br /> platform_probe+0x70/0xd8<br /> <br /> Enabling runtime PM without explicitly resuming the device caused<br /> the power domain cut off after clk_register() is called. As a result,<br /> a crash happens when the clock hardware provider is added and attempts<br /> to access the BLK_CTL register.<br /> <br /> Fix this by using devm_pm_runtime_enable() instead of pm_runtime_enable()<br /> and getting rid of the pm_runtime_disable() in the cleanup path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic<br /> <br /> The decompress_io_ctx may be released asynchronously after<br /> I/O completion. If this file is deleted immediately after read,<br /> and the kworker of processing post_read_wq has not been executed yet<br /> due to high workloads, It is possible that the inode(f2fs_inode_info)<br /> is evicted and freed before it is used f2fs_free_dic.<br /> <br /> The UAF case as below:<br /> Thread A Thread B<br /> - f2fs_decompress_end_io<br /> - f2fs_put_dic<br /> - queue_work<br /> add free_dic work to post_read_wq<br /> - do_unlink<br /> - iput<br /> - evict<br /> - call_rcu<br /> This file is deleted after read.<br /> <br /> Thread C kworker to process post_read_wq<br /> - rcu_do_batch<br /> - f2fs_free_inode<br /> - kmem_cache_free<br /> inode is freed by rcu<br /> - process_scheduled_works<br /> - f2fs_late_free_dic<br /> - f2fs_free_dic<br /> - f2fs_release_decomp_mem<br /> read (dic-&gt;inode)-&gt;i_compress_algorithm<br /> <br /> This patch store compress_algorithm and sbi in dic to avoid inode UAF.<br /> <br /> In addition, the previous solution is deprecated in [1] may cause system hang.<br /> [1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org

In mupen64plus v2.6.0 there is an array overflow vulnerability in the write_rdram_regs and write_rdram_regs functions, which enables executing arbitrary commands on the host machine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: pnv_php: Clean up allocated IRQs on unplug<br /> <br /> When the root of a nested PCIe bridge configuration is unplugged, the<br /> pnv_php driver leaked the allocated IRQ resources for the child bridges&amp;#39;<br /> hotplug event notifications, resulting in a panic.<br /> <br /> Fix this by walking all child buses and deallocating all its IRQ resources<br /> before calling pci_hp_remove_devices().<br /> <br /> Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so<br /> that it is only destroyed in pnv_php_free_slot(), instead of<br /> pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will<br /> now be called by workers triggered by hot unplug interrupts, so the<br /> workqueue needs to stay allocated.<br /> <br /> The abridged kernel panic that occurs without this patch is as follows:<br /> <br /> WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c<br /> CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2<br /> Call Trace:<br /> msi_device_data_release+0x34/0x9c (unreliable)<br /> release_nodes+0x64/0x13c<br /> devres_release_all+0xc0/0x140<br /> device_del+0x2d4/0x46c<br /> pci_destroy_dev+0x5c/0x194<br /> pci_hp_remove_devices+0x90/0x128<br /> pci_hp_remove_devices+0x44/0x128<br /> pnv_php_disable_slot+0x54/0xd4<br /> power_write_file+0xf8/0x18c<br /> pci_slot_attr_store+0x40/0x5c<br /> sysfs_kf_write+0x64/0x78<br /> kernfs_fop_write_iter+0x1b0/0x290<br /> vfs_write+0x3bc/0x50c<br /> ksys_write+0x84/0x140<br /> system_call_exception+0x124/0x230<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> [bhelgaas: tidy comments]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: pnv_php: Fix surprise plug detection and recovery<br /> <br /> The existing PowerNV hotplug code did not handle surprise plug events<br /> correctly, leading to a complete failure of the hotplug system after device<br /> removal and a required reboot to detect new devices.<br /> <br /> This comes down to two issues:<br /> <br /> 1) When a device is surprise removed, often the bridge upstream<br /> port will cause a PE freeze on the PHB. If this freeze is not<br /> cleared, the MSI interrupts from the bridge hotplug notification<br /> logic will not be received by the kernel, stalling all plug events<br /> on all slots associated with the PE.<br /> <br /> 2) When a device is removed from a slot, regardless of surprise or<br /> programmatic removal, the associated PHB/PE ls left frozen.<br /> If this freeze is not cleared via a fundamental reset, skiboot<br /> is unable to clear the freeze and cannot retrain / rescan the<br /> slot. This also requires a reboot to clear the freeze and redetect<br /> the device in the slot.<br /> <br /> Issue the appropriate unfreeze and rescan commands on hotplug events,<br /> and don&amp;#39;t oops on hotplug if pci_bus_to_OF_node() returns NULL.<br /> <br /> [bhelgaas: tidy comments]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: drop UFO packets in udp_rcv_segment()<br /> <br /> When sending a packet with virtio_net_hdr to tun device, if the gso_type<br /> in virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdr<br /> size, below crash may happen.<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:4572!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:skb_pull_rcsum+0x8e/0xa0<br /> Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc 0b 0f 0b 66 66 2e 0f 1f 84 00 000<br /> RSP: 0018:ffffc900001fba38 EFLAGS: 00000297<br /> RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948<br /> RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062<br /> RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001<br /> R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000<br /> R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900<br /> FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445<br /> udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475<br /> udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626<br /> __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690<br /> ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233<br /> ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579<br /> ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636<br /> ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670<br /> __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067<br /> netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210<br /> napi_complete_done+0x78/0x180 net/core/dev.c:6580<br /> tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909<br /> tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984<br /> vfs_write+0x300/0x420 fs/read_write.c:593<br /> ksys_write+0x60/0xd0 fs/read_write.c:686<br /> do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63<br /> <br /> <br /> To trigger gso segment in udp_queue_rcv_skb(), we should also set option<br /> UDP_ENCAP_ESPINUDP to enable udp_sk(sk)-&gt;encap_rcv. When the encap_rcv<br /> hook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will try<br /> to pull udphdr, but the skb size has been segmented to gso size, which<br /> leads to this crash.<br /> <br /> Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")<br /> introduces segmentation in UDP receive path only for GRO, which was never<br /> intended to be used for UFO, so drop UFO packets in udp_rcv_segment().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ti: j721e-csi2rx: fix list_del corruption<br /> <br /> If ti_csi2rx_start_dma() fails in ti_csi2rx_dma_callback(), the buffer is<br /> marked done with VB2_BUF_STATE_ERROR but is not removed from the DMA queue.<br /> This causes the same buffer to be retried in the next iteration, resulting<br /> in a double list_del() and eventual list corruption.<br /> <br /> Fix this by removing the buffer from the queue before calling<br /> vb2_buffer_done() on error.<br /> <br /> This resolves a crash due to list_del corruption:<br /> [ 37.811243] j721e-csi2rx 30102000.ticsi2rx: Failed to queue the next buffer for DMA<br /> [ 37.832187] slab kmalloc-2k start ffff00000255b000 pointer offset 1064 size 2048<br /> [ 37.839761] list_del corruption. next-&gt;prev should be ffff00000255bc28, but was ffff00000255d428. (next=ffff00000255b428)<br /> [ 37.850799] ------------[ cut here ]------------<br /> [ 37.855424] kernel BUG at lib/list_debug.c:65!<br /> [ 37.859876] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [ 37.866061] Modules linked in: i2c_dev usb_f_rndis u_ether libcomposite dwc3 udc_core usb_common aes_ce_blk aes_ce_cipher ghash_ce gf128mul sha1_ce cpufreq_dt dwc3_am62 phy_gmii_sel sa2ul<br /> [ 37.882830] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.16.0-rc3+ #28 VOLUNTARY<br /> [ 37.890851] Hardware name: Bosch STLA-GSRV2-B0 (DT)<br /> [ 37.895737] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 37.902703] pc : __list_del_entry_valid_or_report+0xdc/0x114<br /> [ 37.908390] lr : __list_del_entry_valid_or_report+0xdc/0x114<br /> [ 37.914059] sp : ffff800080003db0<br /> [ 37.917375] x29: ffff800080003db0 x28: 0000000000000007 x27: ffff800080e50000<br /> [ 37.924521] x26: 0000000000000000 x25: ffff0000016abb50 x24: dead000000000122<br /> [ 37.931666] x23: ffff0000016abb78 x22: ffff0000016ab080 x21: ffff800080003de0<br /> [ 37.938810] x20: ffff00000255bc00 x19: ffff00000255b800 x18: 000000000000000a<br /> [ 37.945956] x17: 20747562202c3832 x16: 6362353532303030 x15: 0720072007200720<br /> [ 37.953101] x14: 0720072007200720 x13: 0720072007200720 x12: 00000000ffffffea<br /> [ 37.960248] x11: ffff800080003b18 x10: 00000000ffffefff x9 : ffff800080f5b568<br /> [ 37.967396] x8 : ffff800080f5b5c0 x7 : 0000000000017fe8 x6 : c0000000ffffefff<br /> [ 37.974542] x5 : ffff00000fea6688 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 37.981686] x2 : 0000000000000000 x1 : ffff800080ef2b40 x0 : 000000000000006d<br /> [ 37.988832] Call trace:<br /> [ 37.991281] __list_del_entry_valid_or_report+0xdc/0x114 (P)<br /> [ 37.996959] ti_csi2rx_dma_callback+0x84/0x1c4<br /> [ 38.001419] udma_vchan_complete+0x1e0/0x344<br /> [ 38.005705] tasklet_action_common+0x118/0x310<br /> [ 38.010163] tasklet_action+0x30/0x3c<br /> [ 38.013832] handle_softirqs+0x10c/0x2e0<br /> [ 38.017761] __do_softirq+0x14/0x20<br /> [ 38.021256] ____do_softirq+0x10/0x20<br /> [ 38.024931] call_on_irq_stack+0x24/0x60<br /> [ 38.028873] do_softirq_own_stack+0x1c/0x40<br /> [ 38.033064] __irq_exit_rcu+0x130/0x15c<br /> [ 38.036909] irq_exit_rcu+0x10/0x20<br /> [ 38.040403] el1_interrupt+0x38/0x60<br /> [ 38.043987] el1h_64_irq_handler+0x18/0x24<br /> [ 38.048091] el1h_64_irq+0x6c/0x70<br /> [ 38.051501] default_idle_call+0x34/0xe0 (P)<br /> [ 38.055783] do_idle+0x1f8/0x250<br /> [ 38.059021] cpu_startup_entry+0x34/0x3c<br /> [ 38.062951] rest_init+0xb4/0xc0<br /> [ 38.066186] console_on_rootfs+0x0/0x6c<br /> [ 38.070031] __primary_switched+0x88/0x90<br /> [ 38.074059] Code: b00037e0 91378000 f9400462 97e9bf49 (d4210000)<br /> [ 38.080168] ---[ end trace 0000000000000000 ]---<br /> [ 38.084795] Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt<br /> [ 38.092197] SMP: stopping secondary CPUs<br /> [ 38.096139] Kernel Offset: disabled<br /> [ 38.099631] CPU features: 0x0000,00002000,02000801,0400420b<br /> [ 38.105202] Memory Limit: none<br /> [ 38.108260] ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception in interrupt ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zloop: fix KASAN use-after-free of tag set<br /> <br /> When a zoned loop device, or zloop device, is removed, KASAN enabled<br /> kernel reports "BUG KASAN use-after-free" in blk_mq_free_tag_set(). The<br /> BUG happens because zloop_ctl_remove() calls put_disk(), which invokes<br /> zloop_free_disk(). The zloop_free_disk() frees the memory allocated for<br /> the zlo pointer. However, after the memory is freed, zloop_ctl_remove()<br /> calls blk_mq_free_tag_set(&amp;zlo-&gt;tag_set), which accesses the freed zlo.<br /> Hence the KASAN use-after-free.<br /> <br /> zloop_ctl_remove()<br /> put_disk(zlo-&gt;disk)<br /> put_device()<br /> kobject_put()<br /> ...<br /> zloop_free_disk()<br /> kvfree(zlo)<br /> blk_mq_free_tag_set(&amp;zlo-&gt;tag_set)<br /> <br /> To avoid the BUG, move the call to blk_mq_free_tag_set(&amp;zlo-&gt;tag_set)<br /> from zloop_ctl_remove() into zloop_free_disk(). This ensures that<br /> the tag_set is freed before the call to kvfree(zlo).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: make rdev_addable usable for rcu mode<br /> <br /> Our testcase trigger panic:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000e0<br /> ...<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94<br /> PREEMPT(none)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.16.1-2.fc37 04/01/2014<br /> Workqueue: md_misc md_start_sync<br /> RIP: 0010:rdev_addable+0x4d/0xf0<br /> ...<br /> Call Trace:<br /> <br /> md_start_sync+0x329/0x480<br /> process_one_work+0x226/0x6d0<br /> worker_thread+0x19e/0x340<br /> kthread+0x10f/0x250<br /> ret_from_fork+0x14d/0x180<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Modules linked in: raid10<br /> CR2: 00000000000000e0<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:rdev_addable+0x4d/0xf0<br /> <br /> md_spares_need_change in md_start_sync will call rdev_addable which<br /> protected by rcu_read_lock/rcu_read_unlock. This rcu context will help<br /> protect rdev won&amp;#39;t be released, but rdev-&gt;mddev will be set to NULL<br /> before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by<br /> using READ_ONCE and check does rdev-&gt;mddev still alive.

spimsimulator spim v9.1.24 and before is vulnerable to Buffer Overflow in READ_STRING_SYSCALL.