Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: let net.core.dev_weight always be non-zero<br /> <br /> The following problem was encountered during stability test:<br /> <br /> (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \<br /> returned 1, exceeding its budget of 0.<br /> ------------[ cut here ]------------<br /> list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \<br /> next=ffff88905f746e40.<br /> WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \<br /> __list_add_valid_or_report+0xf3/0x130<br /> CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+<br /> RIP: 0010:__list_add_valid_or_report+0xf3/0x130<br /> Call Trace:<br /> ? __warn+0xcd/0x250<br /> ? __list_add_valid_or_report+0xf3/0x130<br /> enqueue_to_backlog+0x923/0x1070<br /> netif_rx_internal+0x92/0x2b0<br /> __netif_rx+0x15/0x170<br /> loopback_xmit+0x2ef/0x450<br /> dev_hard_start_xmit+0x103/0x490<br /> __dev_queue_xmit+0xeac/0x1950<br /> ip_finish_output2+0x6cc/0x1620<br /> ip_output+0x161/0x270<br /> ip_push_pending_frames+0x155/0x1a0<br /> raw_sendmsg+0xe13/0x1550<br /> __sys_sendto+0x3bf/0x4e0<br /> __x64_sys_sendto+0xdc/0x1b0<br /> do_syscall_64+0x5b/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The reproduction command is as follows:<br /> sysctl -w net.core.dev_weight=0<br /> ping 127.0.0.1<br /> <br /> This is because when the napi&amp;#39;s weight is set to 0, process_backlog() may<br /> return 0 and clear the NAPI_STATE_SCHED bit of napi-&gt;state, causing this<br /> napi to be re-polled in net_rx_action() until __do_softirq() times out.<br /> Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can<br /> be retriggered in enqueue_to_backlog(), causing this issue.<br /> <br /> Making the napi&amp;#39;s weight always non-zero solves this problem.<br /> <br /> Triggering this issue requires system-wide admin (setting is<br /> not namespaced).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: protect access to buffers with no active references<br /> <br /> nilfs_lookup_dirty_data_buffers(), which iterates through the buffers<br /> attached to dirty data folios/pages, accesses the attached buffers without<br /> locking the folios/pages.<br /> <br /> For data cache, nilfs_clear_folio_dirty() may be called asynchronously<br /> when the file system degenerates to read only, so<br /> nilfs_lookup_dirty_data_buffers() still has the potential to cause use<br /> after free issues when buffers lose the protection of their dirty state<br /> midway due to this asynchronous clearing and are unintentionally freed by<br /> try_to_free_buffers().<br /> <br /> Eliminate this race issue by adjusting the lock section in this function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ax25: rcu protect dev-&gt;ax25_ptr<br /> <br /> syzbot found a lockdep issue [1].<br /> <br /> We should remove ax25 RTNL dependency in ax25_setsockopt()<br /> <br /> This should also fix a variety of possible UAF in ax25.<br /> <br /> [1]<br /> <br /> WARNING: possible circular locking dependency detected<br /> 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted<br /> ------------------------------------------------------<br /> syz.5.1818/12806 is trying to acquire lock:<br /> ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680<br /> <br /> but task is already holding lock:<br /> ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]<br /> ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (sk_lock-AF_AX25){+.+.}-{0:0}:<br /> lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849<br /> lock_sock_nested+0x48/0x100 net/core/sock.c:3642<br /> lock_sock include/net/sock.h:1618 [inline]<br /> ax25_kill_by_device net/ax25/af_ax25.c:101 [inline]<br /> ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146<br /> notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85<br /> __dev_notify_flags+0x207/0x400<br /> dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026<br /> dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563<br /> dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820<br /> sock_do_ioctl+0x240/0x460 net/socket.c:1234<br /> sock_ioctl+0x626/0x8e0 net/socket.c:1339<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:906 [inline]<br /> __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> -&gt; #0 (rtnl_mutex){+.+.}-{4:4}:<br /> check_prev_add kernel/locking/lockdep.c:3161 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3280 [inline]<br /> validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904<br /> __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226<br /> lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849<br /> __mutex_lock_common kernel/locking/mutex.c:585 [inline]<br /> __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735<br /> ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680<br /> do_sock_setsockopt+0x3af/0x720 net/socket.c:2324<br /> __sys_setsockopt net/socket.c:2349 [inline]<br /> __do_sys_setsockopt net/socket.c:2355 [inline]<br /> __se_sys_setsockopt net/socket.c:2352 [inline]<br /> __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> other info that might help us debug this:<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(sk_lock-AF_AX25);<br /> lock(rtnl_mutex);<br /> lock(sk_lock-AF_AX25);<br /> lock(rtnl_mutex);<br /> <br /> *** DEADLOCK ***<br /> <br /> 1 lock held by syz.5.1818/12806:<br /> #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]<br /> #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574<br /> <br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074<br /> check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206<br /> check_prev_add kernel/locking/lockdep.c:3161 [inline]<br /> check_prevs_add kernel/lockin<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: Ensure info-&gt;enable callback is always set<br /> <br /> The ioctl and sysfs handlers unconditionally call the -&gt;enable callback.<br /> Not all drivers implement that callback, leading to NULL dereferences.<br /> Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.<br /> <br /> Instead use a dummy callback if no better was specified by the driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: HWS, fix definer&amp;#39;s HWS_SET32 macro for negative offset<br /> <br /> When bit offset for HWS_SET32 macro is negative,<br /> UBSAN complains about the shift-out-of-bounds:<br /> <br /> UBSAN: shift-out-of-bounds in<br /> drivers/net/ethernet/mellanox/mlx5/core/steering/hws/definer.c:177:2<br /> shift exponent -8 is negative

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Fix warnings during S3 suspend<br /> <br /> The enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(),<br /> and the later one may call the preempt_schedule_common() function,<br /> resulting in a thread switch and causing the CPU to be in an interrupt<br /> enabled state after the enable_gpe_wakeup() function returns, leading<br /> to the warnings as follow.<br /> <br /> [ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8<br /> [ C0] ...<br /> [ C0] Call Trace:<br /> [ C0] [] show_stack+0x64/0x188<br /> [ C0] [] dump_stack_lvl+0x60/0x88<br /> [ C0] [] __warn+0x8c/0x148<br /> [ C0] [] report_bug+0x1c0/0x2b0<br /> [ C0] [] do_bp+0x204/0x3b8<br /> [ C0] [] exception_handlers+0x1924/0x10000<br /> [ C0] [] ktime_get+0xbc/0xc8<br /> [ C0] [] tick_sched_timer+0x30/0xb0<br /> [ C0] [] __hrtimer_run_queues+0x160/0x378<br /> [ C0] [] hrtimer_interrupt+0x144/0x388<br /> [ C0] [] constant_timer_interrupt+0x38/0x48<br /> [ C0] [] __handle_irq_event_percpu+0x64/0x1e8<br /> [ C0] [] handle_irq_event_percpu+0x20/0x80<br /> [ C0] [] handle_percpu_irq+0x5c/0x98<br /> [ C0] [] generic_handle_domain_irq+0x30/0x48<br /> [ C0] [] handle_cpu_irq+0x70/0xa8<br /> [ C0] [] handle_loongarch_irq+0x30/0x48<br /> [ C0] [] do_vint+0x80/0xe0<br /> [ C0] [] finish_task_switch.isra.0+0x8c/0x2a8<br /> [ C0] [] __schedule+0x314/0xa48<br /> [ C0] [] schedule+0x58/0xf0<br /> [ C0] [] worker_thread+0x224/0x498<br /> [ C0] [] kthread+0xf8/0x108<br /> [ C0] [] ret_from_kernel_thread+0xc/0xa4<br /> [ C0]<br /> [ C0] ---[ end trace 0000000000000000 ]---<br /> <br /> The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect<br /> acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause<br /> a thread switch. Since there is no longer concurrent execution during<br /> loongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes()<br /> directly in enable_gpe_wakeup().<br /> <br /> The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid<br /> breaking S3 wakeup due to might_sleep()").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ravb: Fix missing rtnl lock in suspend/resume path<br /> <br /> Fix the suspend/resume path by ensuring the rtnl lock is held where<br /> required. Calls to ravb_open, ravb_close and wol operations must be<br /> performed under the rtnl lock to prevent conflicts with ongoing ndo<br /> operations.<br /> <br /> Without this fix, the following warning is triggered:<br /> [ 39.032969] =============================<br /> [ 39.032983] WARNING: suspicious RCU usage<br /> [ 39.033019] -----------------------------<br /> [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious<br /> rcu_dereference_protected() usage!<br /> ...<br /> [ 39.033597] stack backtrace:<br /> [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted<br /> 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7<br /> [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on<br /> r9a08g045s33 (DT)<br /> [ 39.033628] Call trace:<br /> [ 39.033633] show_stack+0x14/0x1c (C)<br /> [ 39.033652] dump_stack_lvl+0xb4/0xc4<br /> [ 39.033664] dump_stack+0x14/0x1c<br /> [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c<br /> [ 39.033682] phy_detach+0x160/0x190<br /> [ 39.033694] phy_disconnect+0x40/0x54<br /> [ 39.033703] ravb_close+0x6c/0x1cc<br /> [ 39.033714] ravb_suspend+0x48/0x120<br /> [ 39.033721] dpm_run_callback+0x4c/0x14c<br /> [ 39.033731] device_suspend+0x11c/0x4dc<br /> [ 39.033740] dpm_suspend+0xdc/0x214<br /> [ 39.033748] dpm_suspend_start+0x48/0x60<br /> [ 39.033758] suspend_devices_and_enter+0x124/0x574<br /> [ 39.033769] pm_suspend+0x1ac/0x274<br /> [ 39.033778] state_store+0x88/0x124<br /> [ 39.033788] kobj_attr_store+0x14/0x24<br /> [ 39.033798] sysfs_kf_write+0x48/0x6c<br /> [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8<br /> [ 39.033817] vfs_write+0x27c/0x378<br /> [ 39.033825] ksys_write+0x64/0xf4<br /> [ 39.033833] __arm64_sys_write+0x18/0x20<br /> [ 39.033841] invoke_syscall+0x44/0x104<br /> [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4<br /> [ 39.033862] do_el0_svc+0x18/0x20<br /> [ 39.033870] el0_svc+0x3c/0xf0<br /> [ 39.033880] el0t_64_sync_handler+0xc0/0xc4<br /> [ 39.033888] el0t_64_sync+0x154/0x158<br /> [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: th1520: Fix a NULL vs IS_ERR() bug<br /> <br /> The devm_ioremap() function doesn&amp;#39;t return error pointers, it returns<br /> NULL. Update the error checking to match.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rhashtable: Fix potential deadlock by moving schedule_work outside lock<br /> <br /> Move the hash table growth check and work scheduling outside the<br /> rht lock to prevent a possible circular locking dependency.<br /> <br /> The original implementation could trigger a lockdep warning due to<br /> a potential deadlock scenario involving nested locks between<br /> rhashtable bucket, rq lock, and dsq lock. By relocating the<br /> growth check and work scheduling after releasing the rth lock, we break<br /> this potential deadlock chain.<br /> <br /> This change expands the flexibility of rhashtable by removing<br /> restrictive locking that previously limited its use in scheduler<br /> and workqueue contexts.<br /> <br /> Import to say that this calls rht_grow_above_75(), which reads from<br /> struct rhashtable without holding the lock, if this is a problem, we can<br /> move the check to the lock, and schedule the workqueue after the lock.<br /> <br /> <br /> Modified so that atomic_inc is also moved outside of the bucket<br /> lock along with the growth above 75% check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: test: Fix potential null dereference in firewire kunit test<br /> <br /> kunit_kzalloc() may return a NULL pointer, dereferencing it without<br /> NULL check may lead to NULL dereference.<br /> Add a NULL check for test_state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()<br /> <br /> When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns<br /> negative error value on error. So not NULL check is not sufficient<br /> to deteremine if IRQ is valid. Check that IRQ is greater then zero<br /> to ensure it is valid.<br /> <br /> There is no issue at probe time but at runtime user can invoke<br /> .set_channels which results in the following call chain.<br /> am65_cpsw_set_channels()<br /> am65_cpsw_nuss_update_tx_rx_chns()<br /> am65_cpsw_nuss_remove_tx_chns()<br /> am65_cpsw_nuss_init_tx_chns()<br /> <br /> At this point if am65_cpsw_nuss_init_tx_chns() fails due to<br /> k3_udma_glue_tx_get_irq() then tx_chn-&gt;irq will be set to a<br /> negative value.<br /> <br /> Then, at subsequent .set_channels with higher channel count we<br /> will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()<br /> leading to a kernel warning.<br /> <br /> The issue is present in the original commit that introduced this driver,<br /> although there, am65_cpsw_nuss_update_tx_rx_chns() existed as<br /> am65_cpsw_nuss_update_tx_chns().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix oops when unload drivers paralleling<br /> <br /> When unload hclge driver, it tries to disable sriov first for each<br /> ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at<br /> the time, because it removes all the ae_dev nodes, and it may cause<br /> oops.<br /> <br /> But we can&amp;#39;t simply use hnae3_common_lock for this. Because in the<br /> process flow of pci_disable_sriov(), it will trigger the remove flow<br /> of VF, which will also take hnae3_common_lock.<br /> <br /> To fixes it, introduce a new mutex to protect the unload process.