Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: fix potential use after free in hfs_correct_next_unused_CNID()<br /> <br /> This code calls hfs_bnode_put(node) which drops the refcount and then<br /> dreferences "node" on the next line. It&amp;#39;s only safe to use "node"<br /> when we&amp;#39;re holding a reference so flip these two lines around.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: netpoll: initialize work queue before error checks<br /> <br /> Prevent a kernel warning when netconsole setup fails on devices with<br /> IFF_DISABLE_NETPOLL flag. The warning (at kernel/workqueue.c:4242 in<br /> __flush_work) occurs because the cleanup path tries to cancel an<br /> uninitialized work queue.<br /> <br /> When __netpoll_setup() encounters a device with IFF_DISABLE_NETPOLL,<br /> it fails early and calls skb_pool_flush() for cleanup. This function<br /> calls cancel_work_sync(&amp;np-&gt;refill_wq), but refill_wq hasn&amp;#39;t been<br /> initialized yet, triggering the warning.<br /> <br /> Move INIT_WORK() to the beginning of __netpoll_setup(), ensuring the<br /> work queue is properly initialized before any potential failure points.<br /> This allows the cleanup path to safely cancel the work queue regardless<br /> of where the setup fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: starfive - Correctly handle return of sg_nents_for_len<br /> <br /> The return value of sg_nents_for_len was assigned to an unsigned long<br /> in starfive_hash_digest, causing negative error codes to be converted<br /> to large positive integers.<br /> <br /> Add error checking for sg_nents_for_len and return immediately on<br /> failure to prevent potential buffer overflows.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags<br /> <br /> When a filesystem is being automounted, it needs to preserve the<br /> user-set superblock mount options, such as the "ro" flag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()<br /> <br /> In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If the<br /> subsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the function<br /> returns an error without freeing sskb, leading to a memory leak.<br /> <br /> Fix this by calling dev_kfree_skb() on sskb in the error handling path<br /> to ensure it is properly released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()<br /> <br /> If irq_domain_translate_twocell() sets "hwirq" to &gt;= MCHP_EIC_NIRQ (2) then<br /> it results in an out of bounds access.<br /> <br /> The code checks for invalid values, but doesn&amp;#39;t set the error code. Return<br /> -EINVAL in that case, instead of returning success.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/fpu: Fix false-positive kmsan report in fpu_vstl()<br /> <br /> A false-positive kmsan report is detected when running ping command.<br /> <br /> An inline assembly instruction &amp;#39;vstl&amp;#39; can write varied amount of bytes<br /> depending on value of &amp;#39;index&amp;#39; argument. If &amp;#39;index&amp;#39; &gt; 0, &amp;#39;vstl&amp;#39; writes<br /> at least 2 bytes.<br /> <br /> clang generates kmsan write helper call depending on inline assembly<br /> constraints. Constraints are evaluated compile-time, but value of<br /> &amp;#39;index&amp;#39; argument is known only at runtime.<br /> <br /> clang currently generates call to __msan_instrument_asm_store with 1 byte<br /> as size. Manually call kmsan function to indicate correct amount of bytes<br /> written and fix false-positive report.<br /> <br /> This change fixes following kmsan reports:<br /> <br /> [ 36.563119] =====================================================<br /> [ 36.563594] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70<br /> [ 36.563852] virtqueue_add+0x35c6/0x7c70<br /> [ 36.564016] virtqueue_add_outbuf+0xa0/0xb0<br /> [ 36.564266] start_xmit+0x288c/0x4a20<br /> [ 36.564460] dev_hard_start_xmit+0x302/0x900<br /> [ 36.564649] sch_direct_xmit+0x340/0xea0<br /> [ 36.564894] __dev_queue_xmit+0x2e94/0x59b0<br /> [ 36.565058] neigh_resolve_output+0x936/0xb40<br /> [ 36.565278] __neigh_update+0x2f66/0x3a60<br /> [ 36.565499] neigh_update+0x52/0x60<br /> [ 36.565683] arp_process+0x1588/0x2de0<br /> [ 36.565916] NF_HOOK+0x1da/0x240<br /> [ 36.566087] arp_rcv+0x3e4/0x6e0<br /> [ 36.566306] __netif_receive_skb_list_core+0x1374/0x15a0<br /> [ 36.566527] netif_receive_skb_list_internal+0x1116/0x17d0<br /> [ 36.566710] napi_complete_done+0x376/0x740<br /> [ 36.566918] virtnet_poll+0x1bae/0x2910<br /> [ 36.567130] __napi_poll+0xf4/0x830<br /> [ 36.567294] net_rx_action+0x97c/0x1ed0<br /> [ 36.567556] handle_softirqs+0x306/0xe10<br /> [ 36.567731] irq_exit_rcu+0x14c/0x2e0<br /> [ 36.567910] do_io_irq+0xd4/0x120<br /> [ 36.568139] io_int_handler+0xc2/0xe8<br /> [ 36.568299] arch_cpu_idle+0xb0/0xc0<br /> [ 36.568540] arch_cpu_idle+0x76/0xc0<br /> [ 36.568726] default_idle_call+0x40/0x70<br /> [ 36.568953] do_idle+0x1d6/0x390<br /> [ 36.569486] cpu_startup_entry+0x9a/0xb0<br /> [ 36.569745] rest_init+0x1ea/0x290<br /> [ 36.570029] start_kernel+0x95e/0xb90<br /> [ 36.570348] startup_continue+0x2e/0x40<br /> [ 36.570703]<br /> [ 36.570798] Uninit was created at:<br /> [ 36.571002] kmem_cache_alloc_node_noprof+0x9e8/0x10e0<br /> [ 36.571261] kmalloc_reserve+0x12a/0x470<br /> [ 36.571553] __alloc_skb+0x310/0x860<br /> [ 36.571844] __ip_append_data+0x483e/0x6a30<br /> [ 36.572170] ip_append_data+0x11c/0x1e0<br /> [ 36.572477] raw_sendmsg+0x1c8c/0x2180<br /> [ 36.572818] inet_sendmsg+0xe6/0x190<br /> [ 36.573142] __sys_sendto+0x55e/0x8e0<br /> [ 36.573392] __s390x_sys_socketcall+0x19ae/0x2ba0<br /> [ 36.573571] __do_syscall+0x12e/0x240<br /> [ 36.573823] system_call+0x6e/0x90<br /> [ 36.573976]<br /> [ 36.574017] Byte 35 of 98 is uninitialized<br /> [ 36.574082] Memory access of size 98 starts at 0000000007aa0012<br /> [ 36.574218]<br /> [ 36.574325] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G B N 6.17.0-dirty #16 NONE<br /> [ 36.574541] Tainted: [B]=BAD_PAGE, [N]=TEST<br /> [ 36.574617] Hardware name: IBM 3931 A01 703 (KVM/Linux)<br /> [ 36.574755] =====================================================<br /> <br /> [ 63.532541] =====================================================<br /> [ 63.533639] BUG: KMSAN: uninit-value in virtqueue_add+0x35c6/0x7c70<br /> [ 63.533989] virtqueue_add+0x35c6/0x7c70<br /> [ 63.534940] virtqueue_add_outbuf+0xa0/0xb0<br /> [ 63.535861] start_xmit+0x288c/0x4a20<br /> [ 63.536708] dev_hard_start_xmit+0x302/0x900<br /> [ 63.537020] sch_direct_xmit+0x340/0xea0<br /> [ 63.537997] __dev_queue_xmit+0x2e94/0x59b0<br /> [ 63.538819] neigh_resolve_output+0x936/0xb40<br /> [ 63.539793] ip_finish_output2+0x1ee2/0x2200<br /> [ 63.540784] __ip_finish_output+0x272/0x7a0<br /> [ 63.541765] ip_finish_output+0x4e/0x5e0<br /> [ 63.542791] ip_output+0x166/0x410<br /> [ 63.543771] ip_push_pending_frames+0x1a2/0x470<br /> [ 63.544753] raw_sendmsg+0x1f06/0x2180<br /> [ 63.545033] inet_sendmsg+0xe6/0x190<br /> [ 63.546006] __sys_sendto+0x55e/0x8e0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Implement settime64 with -EOPNOTSUPP<br /> <br /> ptp_clock_settime() assumes every ptp_clock has implemented settime64().<br /> Stub it with -EOPNOTSUPP to prevent a NULL dereference.<br /> <br /> The fix is similar to commit 329d050bbe63 ("gve: Implement settime64<br /> with -EOPNOTSUPP").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: firewire-motu: add bounds check in put_user loop for DSP events<br /> <br /> In the DSP event handling code, a put_user() loop copies event data.<br /> When the user buffer size is not aligned to 4 bytes, it could overwrite<br /> beyond the buffer boundary.<br /> <br /> Fix by adding a bounds check before put_user().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtc: amlogic-a4: fix double free caused by devm<br /> <br /> The clock obtained via devm_clk_get_enabled() is automatically managed<br /> by devres and will be disabled and freed on driver detach. Manually<br /> calling clk_disable_unprepare() in error path and remove function<br /> causes double free.<br /> <br /> Remove the redundant clk_disable_unprepare() calls from the probe<br /> error path and aml_rtc_remove(), allowing the devm framework to<br /> automatically manage the clock lifecycle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: most: remove broken i2c driver<br /> <br /> The MOST I2C driver has been completely broken for five years without<br /> anyone noticing so remove the driver from staging.<br /> <br /> Specifically, commit 723de0f9171e ("staging: most: remove device from<br /> interface structure") started requiring drivers to set the interface<br /> device pointer before registration, but the I2C driver was never updated<br /> which results in a NULL pointer dereference if anyone ever tries to<br /> probe it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: Use RCU in blk_mq_[un]quiesce_tagset() instead of set-&gt;tag_list_lock<br /> <br /> blk_mq_{add,del}_queue_tag_set() functions add and remove queues from<br /> tagset, the functions make sure that tagset and queues are marked as<br /> shared when two or more queues are attached to the same tagset.<br /> Initially a tagset starts as unshared and when the number of added<br /> queues reaches two, blk_mq_add_queue_tag_set() marks it as shared along<br /> with all the queues attached to it. When the number of attached queues<br /> drops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and<br /> the remaining queues as unshared.<br /> <br /> Both functions need to freeze current queues in tagset before setting on<br /> unsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions<br /> hold set-&gt;tag_list_lock mutex, which makes sense as we do not want<br /> queues to be added or deleted in the process. This used to work fine<br /> until commit 98d81f0df70c ("nvme: use blk_mq_[un]quiesce_tagset")<br /> made the nvme driver quiesce tagset instead of quiscing individual<br /> queues. blk_mq_quiesce_tagset() does the job and quiesce the queues in<br /> set-&gt;tag_list while holding set-&gt;tag_list_lock also.<br /> <br /> This results in deadlock between two threads with these stacktraces:<br /> <br /> __schedule+0x47c/0xbb0<br /> ? timerqueue_add+0x66/0xb0<br /> schedule+0x1c/0xa0<br /> schedule_preempt_disabled+0xa/0x10<br /> __mutex_lock.constprop.0+0x271/0x600<br /> blk_mq_quiesce_tagset+0x25/0xc0<br /> nvme_dev_disable+0x9c/0x250<br /> nvme_timeout+0x1fc/0x520<br /> blk_mq_handle_expired+0x5c/0x90<br /> bt_iter+0x7e/0x90<br /> blk_mq_queue_tag_busy_iter+0x27e/0x550<br /> ? __blk_mq_complete_request_remote+0x10/0x10<br /> ? __blk_mq_complete_request_remote+0x10/0x10<br /> ? __call_rcu_common.constprop.0+0x1c0/0x210<br /> blk_mq_timeout_work+0x12d/0x170<br /> process_one_work+0x12e/0x2d0<br /> worker_thread+0x288/0x3a0<br /> ? rescuer_thread+0x480/0x480<br /> kthread+0xb8/0xe0<br /> ? kthread_park+0x80/0x80<br /> ret_from_fork+0x2d/0x50<br /> ? kthread_park+0x80/0x80<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> __schedule+0x47c/0xbb0<br /> ? xas_find+0x161/0x1a0<br /> schedule+0x1c/0xa0<br /> blk_mq_freeze_queue_wait+0x3d/0x70<br /> ? destroy_sched_domains_rcu+0x30/0x30<br /> blk_mq_update_tag_set_shared+0x44/0x80<br /> blk_mq_exit_queue+0x141/0x150<br /> del_gendisk+0x25a/0x2d0<br /> nvme_ns_remove+0xc9/0x170<br /> nvme_remove_namespaces+0xc7/0x100<br /> nvme_remove+0x62/0x150<br /> pci_device_remove+0x23/0x60<br /> device_release_driver_internal+0x159/0x200<br /> unbind_store+0x99/0xa0<br /> kernfs_fop_write_iter+0x112/0x1e0<br /> vfs_write+0x2b1/0x3d0<br /> ksys_write+0x4e/0xb0<br /> do_syscall_64+0x5b/0x160<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> The top stacktrace is showing nvme_timeout() called to handle nvme<br /> command timeout. timeout handler is trying to disable the controller and<br /> as a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not<br /> to call queue callback handlers. The thread is stuck waiting for<br /> set-&gt;tag_list_lock as it tries to walk the queues in set-&gt;tag_list.<br /> <br /> The lock is held by the second thread in the bottom stack which is<br /> waiting for one of queues to be frozen. The queue usage counter will<br /> drop to zero after nvme_timeout() finishes, and this will not happen<br /> because the thread will wait for this mutex forever.<br /> <br /> Given that [un]quiescing queue is an operation that does not need to<br /> sleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking<br /> set-&gt;tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU<br /> safe list operations. Also, delete INIT_LIST_HEAD(&amp;q-&gt;tag_set_list)<br /> in blk_mq_del_queue_tag_set() because we can not re-initialize it while<br /> the list is being traversed under RCU. The deleted queue will not be<br /> added/deleted to/from a tagset and it will be freed in blk_free_queue()<br /> after the end of RCU grace period.