Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: cs40l50-vibra - fix potential NULL dereference in cs40l50_upload_owt()<br /> <br /> The cs40l50_upload_owt() function allocates memory via kmalloc()<br /> without checking for allocation failure, which could lead to a<br /> NULL pointer dereference.<br /> <br /> Return -ENOMEM in case allocation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: fix data race in show_numa_info()<br /> <br /> The following data-race was found in show_numa_info():<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show<br /> <br /> read to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0:<br /> show_numa_info mm/vmalloc.c:4936 [inline]<br /> vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016<br /> seq_read_iter+0x373/0xb40 fs/seq_file.c:230<br /> proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299<br /> ....<br /> <br /> write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1:<br /> show_numa_info mm/vmalloc.c:4934 [inline]<br /> vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016<br /> seq_read_iter+0x373/0xb40 fs/seq_file.c:230<br /> proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299<br /> ....<br /> <br /> value changed: 0x0000008f -&gt; 0x00000000<br /> ==================================================================<br /> <br /> According to this report,there is a read/write data-race because<br /> m-&gt;private is accessible to multiple CPUs. To fix this, instead of<br /> allocating the heap in proc_vmalloc_init() and passing the heap address to<br /> m-&gt;private, vmalloc_info_show() should allocate the heap.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix iteration of extrefs during log replay<br /> <br /> At __inode_add_ref() when processing extrefs, if we jump into the next<br /> label we have an undefined value of victim_name.len, since we haven&amp;#39;t<br /> initialized it before we did the goto. This results in an invalid memory<br /> access in the next iteration of the loop since victim_name.len was not<br /> initialized to the length of the name of the current extref.<br /> <br /> Fix this by initializing victim_name.len with the current extref&amp;#39;s name<br /> length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: spinand: fix memory leak of ECC engine conf<br /> <br /> Memory allocated for the ECC engine conf is not released during spinand<br /> cleanup. Below kmemleak trace is seen for this memory leak:<br /> <br /> unreferenced object 0xffffff80064f00e0 (size 8):<br /> comm "swapper/0", pid 1, jiffies 4294937458<br /> hex dump (first 8 bytes):<br /> 00 00 00 00 00 00 00 00 ........<br /> backtrace (crc 0):<br /> kmemleak_alloc+0x30/0x40<br /> __kmalloc_cache_noprof+0x208/0x3c0<br /> spinand_ondie_ecc_init_ctx+0x114/0x200<br /> nand_ecc_init_ctx+0x70/0xa8<br /> nanddev_ecc_engine_init+0xec/0x27c<br /> spinand_probe+0xa2c/0x1620<br /> spi_mem_probe+0x130/0x21c<br /> spi_probe+0xf0/0x170<br /> really_probe+0x17c/0x6e8<br /> __driver_probe_device+0x17c/0x21c<br /> driver_probe_device+0x58/0x180<br /> __device_attach_driver+0x15c/0x1f8<br /> bus_for_each_drv+0xec/0x150<br /> __device_attach+0x188/0x24c<br /> device_initial_probe+0x10/0x20<br /> bus_probe_device+0x11c/0x160<br /> <br /> Fix the leak by calling nanddev_ecc_engine_cleanup() inside<br /> spinand_cleanup().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect<br /> <br /> Remove redundant netif_napi_del() call from disconnect path.<br /> <br /> A WARN may be triggered in __netif_napi_del_locked() during USB device<br /> disconnect:<br /> <br /> WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350<br /> <br /> This happens because netif_napi_del() is called in the disconnect path while<br /> NAPI is still enabled. However, it is not necessary to call netif_napi_del()<br /> explicitly, since unregister_netdev() will handle NAPI teardown automatically<br /> and safely. Removing the redundant call avoids triggering the warning.<br /> <br /> Full trace:<br /> lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV<br /> lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV<br /> lan78xx 1-1:1.0 enu1: Link is Down<br /> lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350<br /> Modules linked in: flexcan can_dev fuse<br /> CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT<br /> Hardware name: SKOV IMX8MP CPU revC - bd500 (DT)<br /> Workqueue: usb_hub_wq hub_event<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __netif_napi_del_locked+0x2b4/0x350<br /> lr : __netif_napi_del_locked+0x7c/0x350<br /> sp : ffffffc085b673c0<br /> x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8<br /> x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb<br /> x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000<br /> x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000<br /> x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028<br /> x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8<br /> x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000<br /> x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001<br /> x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000<br /> Call trace:<br /> __netif_napi_del_locked+0x2b4/0x350 (P)<br /> lan78xx_disconnect+0xf4/0x360<br /> usb_unbind_interface+0x158/0x718<br /> device_remove+0x100/0x150<br /> device_release_driver_internal+0x308/0x478<br /> device_release_driver+0x1c/0x30<br /> bus_remove_device+0x1a8/0x368<br /> device_del+0x2e0/0x7b0<br /> usb_disable_device+0x244/0x540<br /> usb_disconnect+0x220/0x758<br /> hub_event+0x105c/0x35e0<br /> process_one_work+0x760/0x17b0<br /> worker_thread+0x768/0xce8<br /> kthread+0x3bc/0x690<br /> ret_from_fork+0x10/0x20<br /> irq event stamp: 211604<br /> hardirqs last enabled at (211603): [] _raw_spin_unlock_irqrestore+0x84/0x98<br /> hardirqs last disabled at (211604): [] el1_dbg+0x24/0x80<br /> softirqs last enabled at (211296): [] handle_softirqs+0x820/0xbc8<br /> softirqs last disabled at (210993): [] __do_softirq+0x18/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Refuse to evaluate a method if arguments are missing<br /> <br /> As reported in [1], a platform firmware update that increased the number<br /> of method parameters and forgot to update a least one of its callers,<br /> caused ACPICA to crash due to use-after-free.<br /> <br /> Since this a result of a clear AML issue that arguably cannot be fixed<br /> up by the interpreter (it cannot produce missing data out of thin air),<br /> address it by making ACPICA refuse to evaluate a method if the caller<br /> attempts to pass fewer arguments than expected to it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/mlx5: Fix potential deadlock in MR deregistration<br /> <br /> The issue arises when kzalloc() is invoked while holding umem_mutex or<br /> any other lock acquired under umem_mutex. This is problematic because<br /> kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke<br /> mmu_notifier_invalidate_range_start(). This function can lead to<br /> mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,<br /> resulting in a deadlock.<br /> <br /> The problematic flow:<br /> CPU0 | CPU1<br /> ---------------------------------------|------------------------------------------------<br /> mlx5_ib_dereg_mr() |<br /> → revoke_mr() |<br /> → mutex_lock(&amp;umem_odp-&gt;umem_mutex) |<br /> | mlx5_mkey_cache_init()<br /> | → mutex_lock(&amp;dev-&gt;cache.rb_lock)<br /> | → mlx5r_cache_create_ent_locked()<br /> | → kzalloc(GFP_KERNEL)<br /> | → fs_reclaim()<br /> | → mmu_notifier_invalidate_range_start()<br /> | → mlx5_ib_invalidate_range()<br /> | → mutex_lock(&amp;umem_odp-&gt;umem_mutex)<br /> → cache_ent_find_and_store() |<br /> → mutex_lock(&amp;dev-&gt;cache.rb_lock) |<br /> <br /> Additionally, when kzalloc() is called from within<br /> cache_ent_find_and_store(), we encounter the same deadlock due to<br /> re-acquisition of umem_mutex.<br /> <br /> Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()<br /> and before acquiring rb_lock. This ensures that we don&amp;#39;t hold<br /> umem_mutex while performing memory allocations that could trigger<br /> the reclaim path.<br /> <br /> This change prevents the deadlock by ensuring proper lock ordering and<br /> avoiding holding locks during memory allocation operations that could<br /> trigger the reclaim path.<br /> <br /> The following lockdep warning demonstrates the deadlock:<br /> <br /> python3/20557 is trying to acquire lock:<br /> ffff888387542128 (&amp;umem_odp-&gt;umem_mutex){+.+.}-{4:4}, at:<br /> mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]<br /> <br /> but task is already holding lock:<br /> ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at:<br /> unmap_vmas+0x7b/0x1a0<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:<br /> fs_reclaim_acquire+0x60/0xd0<br /> mem_cgroup_css_alloc+0x6f/0x9b0<br /> cgroup_init_subsys+0xa4/0x240<br /> cgroup_init+0x1c8/0x510<br /> start_kernel+0x747/0x760<br /> x86_64_start_reservations+0x25/0x30<br /> x86_64_start_kernel+0x73/0x80<br /> common_startup_64+0x129/0x138<br /> <br /> -&gt; #2 (fs_reclaim){+.+.}-{0:0}:<br /> fs_reclaim_acquire+0x91/0xd0<br /> __kmalloc_cache_noprof+0x4d/0x4c0<br /> mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib]<br /> mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib]<br /> mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib]<br /> __mlx5_ib_add+0x4b/0x190 [mlx5_ib]<br /> mlx5r_probe+0xd9/0x320 [mlx5_ib]<br /> auxiliary_bus_probe+0x42/0x70<br /> really_probe+0xdb/0x360<br /> __driver_probe_device+0x8f/0x130<br /> driver_probe_device+0x1f/0xb0<br /> __driver_attach+0xd4/0x1f0<br /> bus_for_each_dev+0x79/0xd0<br /> bus_add_driver+0xf0/0x200<br /> driver_register+0x6e/0xc0<br /> __auxiliary_driver_register+0x6a/0xc0<br /> do_one_initcall+0x5e/0x390<br /> do_init_module+0x88/0x240<br /> init_module_from_file+0x85/0xc0<br /> idempotent_init_module+0x104/0x300<br /> __x64_sys_finit_module+0x68/0xc0<br /> do_syscall_64+0x6d/0x140<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> -&gt; #1 (&amp;dev-&gt;cache.rb_lock){+.+.}-{4:4}:<br /> __mutex_lock+0x98/0xf10<br /> __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib]<br /> mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib]<br /> ib_dereg_mr_user+0x85/0x1f0 [ib_core]<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> optee: ffa: fix sleep in atomic context<br /> <br /> The OP-TEE driver registers the function notif_callback() for FF-A<br /> notifications. However, this function is called in an atomic context<br /> leading to errors like this when processing asynchronous notifications:<br /> <br /> | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258<br /> | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0<br /> | preempt_count: 1, expected: 0<br /> | RCU nest depth: 0, expected: 0<br /> | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0-00019-g657536ebe0aa #13<br /> | Hardware name: linux,dummy-virt (DT)<br /> | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn<br /> | Call trace:<br /> | show_stack+0x18/0x24 (C)<br /> | dump_stack_lvl+0x78/0x90<br /> | dump_stack+0x18/0x24<br /> | __might_resched+0x114/0x170<br /> | __might_sleep+0x48/0x98<br /> | mutex_lock+0x24/0x80<br /> | optee_get_msg_arg+0x7c/0x21c<br /> | simple_call_with_arg+0x50/0xc0<br /> | optee_do_bottom_half+0x14/0x20<br /> | notif_callback+0x3c/0x48<br /> | handle_notif_callbacks+0x9c/0xe0<br /> | notif_get_and_handle+0x40/0x88<br /> | generic_exec_single+0x80/0xc0<br /> | smp_call_function_single+0xfc/0x1a0<br /> | notif_pcpu_irq_work_fn+0x2c/0x38<br /> | process_one_work+0x14c/0x2b4<br /> | worker_thread+0x2e4/0x3e0<br /> | kthread+0x13c/0x210<br /> | ret_from_fork+0x10/0x20<br /> <br /> Fix this by adding work queue to process the notification in a<br /> non-atomic context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume<br /> <br /> Shawn and John reported a hang issue during system suspend as below:<br /> <br /> - USB gadget is enabled as Ethernet<br /> - There is data transfer over USB Ethernet (scp a big file between host<br /> and device)<br /> - Device is going in/out suspend (echo mem &gt; /sys/power/state)<br /> <br /> The root cause is the USB device controller is suspended but the USB bus<br /> is still active which caused the USB host continues to transfer data with<br /> device and the device continues to queue USB requests (in this case, a<br /> delayed TCP ACK packet trigger the issue) after controller is suspended,<br /> however the USB controller clock is already gated off. Then if udc driver<br /> access registers after that point, the system will hang.<br /> <br /> The correct way to avoid such issue is to disconnect device from host when<br /> the USB bus is not at suspend state. Then the host will receive disconnect<br /> event and stop data transfer in time. To continue make USB gadget device<br /> work after system resume, this will reconnect device automatically.<br /> <br /> To make usb wakeup work if USB bus is already at suspend state, this will<br /> keep connection for it only when USB device controller has enabled wakeup<br /> capability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: appletb-kbd: fix slab use-after-free bug in appletb_kbd_probe<br /> <br /> In probe appletb_kbd_probe() a "struct appletb_kbd *kbd" is allocated<br /> via devm_kzalloc() to store touch bar keyboard related data.<br /> Later on if backlight_device_get_by_name() finds a backlight device<br /> with name "appletb_backlight" a timer (kbd-&gt;inactivity_timer) is setup<br /> with appletb_inactivity_timer() and the timer is armed to run after<br /> appletb_tb_dim_timeout (60) seconds.<br /> <br /> A use-after-free is triggered when failure occurs after the timer is<br /> armed. This ultimately means probe failure occurs and as a result the<br /> "struct appletb_kbd *kbd" which is device managed memory is freed.<br /> After 60 seconds the timer will have expired and __run_timers will<br /> attempt to access the timer (kbd-&gt;inactivity_timer) however the kdb<br /> structure has been freed causing a use-after free.<br /> <br /> [ 71.636938] ==================================================================<br /> [ 71.637915] BUG: KASAN: slab-use-after-free in __run_timers+0x7ad/0x890<br /> [ 71.637915] Write of size 8 at addr ffff8881178c5958 by task swapper/1/0<br /> [ 71.637915]<br /> [ 71.637915] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.16.0-rc2-00318-g739a6c93cc75-dirty #12 PREEMPT(voluntary)<br /> [ 71.637915] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> [ 71.637915] Call Trace:<br /> [ 71.637915] <br /> [ 71.637915] dump_stack_lvl+0x53/0x70<br /> [ 71.637915] print_report+0xce/0x670<br /> [ 71.637915] ? __run_timers+0x7ad/0x890<br /> [ 71.637915] kasan_report+0xce/0x100<br /> [ 71.637915] ? __run_timers+0x7ad/0x890<br /> [ 71.637915] __run_timers+0x7ad/0x890<br /> [ 71.637915] ? __pfx___run_timers+0x10/0x10<br /> [ 71.637915] ? update_process_times+0xfc/0x190<br /> [ 71.637915] ? __pfx_update_process_times+0x10/0x10<br /> [ 71.637915] ? _raw_spin_lock_irq+0x80/0xe0<br /> [ 71.637915] ? _raw_spin_lock_irq+0x80/0xe0<br /> [ 71.637915] ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> [ 71.637915] run_timer_softirq+0x141/0x240<br /> [ 71.637915] ? __pfx_run_timer_softirq+0x10/0x10<br /> [ 71.637915] ? __pfx___hrtimer_run_queues+0x10/0x10<br /> [ 71.637915] ? kvm_clock_get_cycles+0x18/0x30<br /> [ 71.637915] ? ktime_get+0x60/0x140<br /> [ 71.637915] handle_softirqs+0x1b8/0x5c0<br /> [ 71.637915] ? __pfx_handle_softirqs+0x10/0x10<br /> [ 71.637915] irq_exit_rcu+0xaf/0xe0<br /> [ 71.637915] sysvec_apic_timer_interrupt+0x6c/0x80<br /> [ 71.637915] <br /> [ 71.637915]<br /> [ 71.637915] Allocated by task 39:<br /> [ 71.637915] kasan_save_stack+0x33/0x60<br /> [ 71.637915] kasan_save_track+0x14/0x30<br /> [ 71.637915] __kasan_kmalloc+0x8f/0xa0<br /> [ 71.637915] __kmalloc_node_track_caller_noprof+0x195/0x420<br /> [ 71.637915] devm_kmalloc+0x74/0x1e0<br /> [ 71.637915] appletb_kbd_probe+0x37/0x3c0<br /> [ 71.637915] hid_device_probe+0x2d1/0x680<br /> [ 71.637915] really_probe+0x1c3/0x690<br /> [ 71.637915] __driver_probe_device+0x247/0x300<br /> [ 71.637915] driver_probe_device+0x49/0x210<br /> [...]<br /> [ 71.637915]<br /> [ 71.637915] Freed by task 39:<br /> [ 71.637915] kasan_save_stack+0x33/0x60<br /> [ 71.637915] kasan_save_track+0x14/0x30<br /> [ 71.637915] kasan_save_free_info+0x3b/0x60<br /> [ 71.637915] __kasan_slab_free+0x37/0x50<br /> [ 71.637915] kfree+0xcf/0x360<br /> [ 71.637915] devres_release_group+0x1f8/0x3c0<br /> [ 71.637915] hid_device_probe+0x315/0x680<br /> [ 71.637915] really_probe+0x1c3/0x690<br /> [ 71.637915] __driver_probe_device+0x247/0x300<br /> [ 71.637915] driver_probe_device+0x49/0x210<br /> [...]<br /> <br /> The root cause of the issue is that the timer is not disarmed<br /> on failure paths leading to it remaining active and accessing<br /> freed memory. To fix this call timer_delete_sync() to deactivate<br /> the timer.<br /> <br /> Another small issue is that timer_delete_sync is called<br /> unconditionally in appletb_kbd_remove(), fix this by checking<br /> for a valid kbd-&gt;backlight_dev before calling timer_delete_sync.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix unsafe xarray access in implicit ODP handling<br /> <br /> __xa_store() and __xa_erase() were used without holding the proper lock,<br /> which led to a lockdep warning due to unsafe RCU usage. This patch<br /> replaces them with xa_store() and xa_erase(), which perform the necessary<br /> locking internally.<br /> <br /> =============================<br /> WARNING: suspicious RCPU usage<br /> 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Not tainted<br /> -----------------------------<br /> ./include/linux/xarray.h:1211 suspicious rcu_dereference_protected() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 3 locks held by kworker/u136:0/219:<br /> at: process_one_work+0xbe4/0x15f0<br /> process_one_work+0x75c/0x15f0<br /> pagefault_mr+0x9a5/0x1390 [mlx5_ib]<br /> <br /> stack backtrace:<br /> CPU: 14 UID: 0 PID: 219 Comm: kworker/u136:0 Not tainted<br /> 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS<br /> rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]<br /> Call Trace:<br /> dump_stack_lvl+0xa8/0xc0<br /> lockdep_rcu_suspicious+0x1e6/0x260<br /> xas_create+0xb8a/0xee0<br /> xas_store+0x73/0x14c0<br /> __xa_store+0x13c/0x220<br /> ? xa_store_range+0x390/0x390<br /> ? spin_bug+0x1d0/0x1d0<br /> pagefault_mr+0xcb5/0x1390 [mlx5_ib]<br /> ? _raw_spin_unlock+0x1f/0x30<br /> mlx5_ib_eqe_pf_action+0x3be/0x2620 [mlx5_ib]<br /> ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> ? mlx5_ib_invalidate_range+0xcb0/0xcb0 [mlx5_ib]<br /> process_one_work+0x7db/0x15f0<br /> ? pwq_dec_nr_in_flight+0xda0/0xda0<br /> ? assign_work+0x168/0x240<br /> worker_thread+0x57d/0xcd0<br /> ? rescuer_thread+0xc40/0xc40<br /> kthread+0x3b3/0x800<br /> ? kthread_is_per_cpu+0xb0/0xb0<br /> ? lock_downgrade+0x680/0x680<br /> ? do_raw_spin_lock+0x12d/0x270<br /> ? spin_bug+0x1d0/0x1d0<br /> ? finish_task_switch.isra.0+0x284/0x9e0<br /> ? lockdep_hardirqs_on_prepare+0x284/0x400<br /> ? kthread_is_per_cpu+0xb0/0xb0<br /> ret_from_fork+0x2d/0x70<br /> ? kthread_is_per_cpu+0xb0/0xb0<br /> ret_from_fork_asm+0x11/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: ensure the received length does not exceed allocated size<br /> <br /> In xdp_linearize_page, when reading the following buffers from the ring,<br /> we forget to check the received length with the true allocate size. This<br /> can lead to an out-of-bound read. This commit adds that missing check.