Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()<br /> <br /> In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMA<br /> allocations in a loop. When an allocation fails, the previously<br /> successful allocations are not freed on exit.<br /> <br /> Fix that by jumping to err_free_rings label on error, which calls<br /> rtl8180_free_rx_ring() to free the allocations. Remove the free of<br /> rx_ring in rtl8180_init_rx_ring() error path, and set the freed<br /> priv-&gt;rx_buf entry to null, to avoid double free.

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 /> 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 /> 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 /> 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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vgem-fence: Fix potential deadlock on release<br /> <br /> A timer that expires a vgem fence automatically in 10 seconds is now<br /> released with timer_delete_sync() from fence-&gt;ops.release() called on last<br /> dma_fence_put(). In some scenarios, it can run in IRQ context, which is<br /> not safe unless TIMER_IRQSAFE is used. One potentially risky scenario was<br /> demonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, while<br /> working on new IGT subtests syncobj_timeline@stress-* as user space<br /> replacements of some problematic test cases of a dma-fence-chain selftest<br /> [1].<br /> <br /> [117.004338] ================================<br /> [117.004340] WARNING: inconsistent lock state<br /> [117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U<br /> [117.004346] --------------------------------<br /> [117.004347] inconsistent {HARDIRQ-ON-W} -&gt; {IN-HARDIRQ-W} usage.<br /> [117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes:<br /> [117.004352] ffff888138f86aa8 ((&amp;fence-&gt;timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190<br /> [117.004361] {HARDIRQ-ON-W} state was registered at:<br /> [117.004363] lock_acquire+0xc4/0x2e0<br /> [117.004366] call_timer_fn+0x80/0x2a0<br /> [117.004368] __run_timers+0x231/0x310<br /> [117.004370] run_timer_softirq+0x76/0xe0<br /> [117.004372] handle_softirqs+0xd4/0x4d0<br /> [117.004375] __irq_exit_rcu+0x13f/0x160<br /> [117.004377] irq_exit_rcu+0xe/0x20<br /> [117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0<br /> [117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20<br /> [117.004385] cpuidle_enter_state+0x12b/0x8a0<br /> [117.004388] cpuidle_enter+0x2e/0x50<br /> [117.004393] call_cpuidle+0x22/0x60<br /> [117.004395] do_idle+0x1fd/0x260<br /> [117.004398] cpu_startup_entry+0x29/0x30<br /> [117.004401] start_secondary+0x12d/0x160<br /> [117.004404] common_startup_64+0x13e/0x141<br /> [117.004407] irq event stamp: 2282669<br /> [117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80<br /> [117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0<br /> [117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18<br /> [117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160<br /> [117.004426]<br /> other info that might help us debug this:<br /> [117.004429] Possible unsafe locking scenario:<br /> [117.004432] CPU0<br /> [117.004433] ----<br /> [117.004434] lock((&amp;fence-&gt;timer));<br /> [117.004436] <br /> [117.004438] lock((&amp;fence-&gt;timer));<br /> [117.004440]<br /> *** DEADLOCK ***<br /> [117.004443] 1 lock held by swapper/0/0:<br /> [117.004445] #0: ffffc90000003d50 ((&amp;fence-&gt;timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0<br /> [117.004450]<br /> stack backtrace:<br /> [117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary)<br /> [117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER<br /> [117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023<br /> [117.004456] Call Trace:<br /> [117.004456] <br /> [117.004457] dump_stack_lvl+0x91/0xf0<br /> [117.004460] dump_stack+0x10/0x20<br /> [117.004461] print_usage_bug.part.0+0x260/0x360<br /> [117.004463] mark_lock+0x76e/0x9c0<br /> [117.004465] ? register_lock_class+0x48/0x4a0<br /> [117.004467] __lock_acquire+0xbc3/0x2860<br /> [117.004469] lock_acquire+0xc4/0x2e0<br /> [117.004470] ? __timer_delete_sync+0x4b/0x190<br /> [117.004472] ? __timer_delete_sync+0x4b/0x190<br /> [117.004473] __timer_delete_sync+0x68/0x190<br /> [117.004474] ? __timer_delete_sync+0x4b/0x190<br /> [117.004475] timer_delete_sync+0x10/0x20<br /> [117.004476] vgem_fence_release+0x19/0x30 [vgem]<br /> [117.004478] dma_fence_release+0xc1/0x3b0<br /> [117.004480] ? dma_fence_release+0xa1/0x3b0<br /> [117.004481] dma_fence_chain_release+0xe7/0x130<br /> [117.004483] dma_fence_release+0xc1/0x3b0<br /> [117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80<br /> [117.004485] dma_fence_chain_irq_work+0x59/0x80<br /> [117.004487] irq_work_single+0x75/0xa0<br /> [117.004490] irq_work_r<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> backlight: led-bl: Add devlink to supplier LEDs<br /> <br /> LED Backlight is a consumer of one or multiple LED class devices, but<br /> devlink is currently unable to create correct supplier-producer links when<br /> the supplier is a class device. It creates instead a link where the<br /> supplier is the parent of the expected device.<br /> <br /> One consequence is that removal order is not correctly enforced.<br /> <br /> Issues happen for example with the following sections in a device tree<br /> overlay:<br /> <br /> // An LED driver chip<br /> pca9632@62 {<br /> compatible = "nxp,pca9632";<br /> reg = ;<br /> <br /> // ...<br /> <br /> addon_led_pwm: led-pwm@3 {<br /> reg = ;<br /> label = "addon:led:pwm";<br /> };<br /> };<br /> <br /> backlight-addon {<br /> compatible = "led-backlight";<br /> leds = ;<br /> brightness-levels = ;<br /> default-brightness-level = ;<br /> };<br /> <br /> In this example, the devlink should be created between the backlight-addon<br /> (consumer) and the pca9632@62 (supplier). Instead it is created between the<br /> backlight-addon (consumer) and the parent of the pca9632@62, which is<br /> typically the I2C bus adapter.<br /> <br /> On removal of the above overlay, the LED driver can be removed before the<br /> backlight device, resulting in:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> ...<br /> Call trace:<br /> led_put+0xe0/0x140<br /> devm_led_release+0x6c/0x98<br /> <br /> Another way to reproduce the bug without any device tree overlays is<br /> unbinding the LED class device (pca9632@62) before unbinding the consumer<br /> (backlight-addon):<br /> <br /> echo 11-0062 &gt;/sys/bus/i2c/drivers/leds-pca963x/unbind<br /> echo ...backlight-dock &gt;/sys/bus/platform/drivers/led-backlight/unbind<br /> <br /> Fix by adding a devlink between the consuming led-backlight device and the<br /> supplying LED device, as other drivers and subsystems do as well.

In the backup parameters, a user with high privilege is able to concatenate custom instructions to the backup setup. Improper Neutralization of Special Elements used in an OS Command (&amp;#39;OS Command Injection&amp;#39;) vulnerability in Centreon Infra Monitoring (Backup configuration in the administration setup modules) allows OS Command Injection.This issue affects Infra Monitoring: from 25.10.0 before 25.10.2, from 24.10.0 before 24.10.15, from 24.04.0 before 24.04.19.