Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Disable interrupts before resetting the GPU<br /> <br /> Currently, an interrupt can be triggered during a GPU reset, which can<br /> lead to GPU hangs and NULL pointer dereference in an interrupt context<br /> as shown in the following trace:<br /> <br /> [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0<br /> [ 314.043822] Mem abort info:<br /> [ 314.046606] ESR = 0x0000000096000005<br /> [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 314.055651] SET = 0, FnV = 0<br /> [ 314.058695] EA = 0, S1PTW = 0<br /> [ 314.061826] FSC = 0x05: level 1 translation fault<br /> [ 314.066694] Data abort info:<br /> [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000<br /> [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight<br /> [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1<br /> [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)<br /> [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d]<br /> [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d]<br /> [ 314.160198] sp : ffffffc080003ea0<br /> [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000<br /> [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0<br /> [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000<br /> [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000<br /> [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000<br /> [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001<br /> [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874<br /> [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180<br /> [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb<br /> [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 314.234807] Call trace:<br /> [ 314.237243] v3d_irq+0xec/0x2e0 [v3d]<br /> [ 314.240906] __handle_irq_event_percpu+0x58/0x218<br /> [ 314.245609] handle_irq_event+0x54/0xb8<br /> [ 314.249439] handle_fasteoi_irq+0xac/0x240<br /> [ 314.253527] handle_irq_desc+0x48/0x68<br /> [ 314.257269] generic_handle_domain_irq+0x24/0x38<br /> [ 314.261879] gic_handle_irq+0x48/0xd8<br /> [ 314.265533] call_on_irq_stack+0x24/0x58<br /> [ 314.269448] do_interrupt_handler+0x88/0x98<br /> [ 314.273624] el1_interrupt+0x34/0x68<br /> [ 314.277193] el1h_64_irq_handler+0x18/0x28<br /> [ 314.281281] el1h_64_irq+0x64/0x68<br /> [ 314.284673] default_idle_call+0x3c/0x168<br /> [ 314.288675] do_idle+0x1fc/0x230<br /> [ 314.291895] cpu_startup_entry+0x3c/0x50<br /> [ 314.295810] rest_init+0xe4/0xf0<br /> [ 314.299030] start_kernel+0x5e8/0x790<br /> [ 314.302684] __primary_switched+0x80/0x90<br /> [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017)<br /> [ 314.312775] ---[ end trace 0000000000000000 ]---<br /> [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt<br /> [ 314.324249] SMP: stopping secondary CPUs<br /> [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000<br /> [ 314.334076] PHYS_OFFSET: 0x0<br /> [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b<br /> [ 314.342337] Memory Limit: none<br /> [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---<br /> <br /> Before resetting the G<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rose: fix dangling neighbour pointers in rose_rt_device_down()<br /> <br /> There are two bugs in rose_rt_device_down() that can cause<br /> use-after-free:<br /> <br /> 1. The loop bound `t-&gt;count` is modified within the loop, which can<br /> cause the loop to terminate early and miss some entries.<br /> <br /> 2. When removing an entry from the neighbour array, the subsequent entries<br /> are moved up to fill the gap, but the loop index `i` is still<br /> incremented, causing the next entry to be skipped.<br /> <br /> For example, if a node has three neighbours (A, A, B) with count=3 and A<br /> is being removed, the second A is not checked.<br /> <br /> i=0: (A, A, B) -&gt; (A, B) with count=2<br /> ^ checked<br /> i=1: (A, B) -&gt; (A, B) with count=2<br /> ^ checked (B, not A!)<br /> i=2: (doesn&amp;#39;t occur because i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Check validity of "num_cpu" from user space<br /> <br /> The maximum supported cpu number is EIOINTC_ROUTE_MAX_VCPUS about<br /> irqchip EIOINTC, here add validation about cpu number to avoid array<br /> pointer overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Avoid overflow with array index<br /> <br /> The variable index is modified and reused as array index when modify<br /> register EIOINTC_ENABLE. There will be array index overflow problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe()<br /> <br /> The returned value, pfsm-&gt;miscdev.name, from devm_kasprintf()<br /> could be NULL.<br /> A pointer check is added to prevent potential NULL pointer dereference.<br /> This is similar to the fix in commit 3027e7b15b02<br /> ("ice: Fix some null pointer dereference issues in ice_ptp.c").<br /> <br /> This issue is found by our static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix failure to rebuild free space tree using multiple transactions<br /> <br /> If we are rebuilding a free space tree, while modifying the free space<br /> tree we may need to allocate a new metadata block group.<br /> If we end up using multiple transactions for the rebuild, when we call<br /> btrfs_end_transaction() we enter btrfs_create_pending_block_groups()<br /> which calls add_block_group_free_space() to add items to the free space<br /> tree for the block group.<br /> <br /> Then later during the free space tree rebuild, at<br /> btrfs_rebuild_free_space_tree(), we may find such new block groups<br /> and call populate_free_space_tree() for them, which fails with -EEXIST<br /> because there are already items in the free space tree. Then we abort the<br /> transaction with -EEXIST at btrfs_rebuild_free_space_tree().<br /> Notice that we say "may find" the new block groups because a new block<br /> group may be inserted in the block groups rbtree, which is being iterated<br /> by the rebuild process, before or after the current node where the rebuild<br /> process is currently at.<br /> <br /> Syzbot recently reported such case which produces a trace like the<br /> following:<br /> <br /> ------------[ cut here ]------------<br /> BTRFS: Transaction aborted (error -17)<br /> WARNING: CPU: 1 PID: 7626 at fs/btrfs/free-space-tree.c:1341 btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 7626 Comm: syz.2.25 Not tainted 6.15.0-rc7-syzkaller-00085-gd7fa1af5b33e-dirty #0 PREEMPT<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341<br /> lr : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341<br /> sp : ffff80009c4f7740<br /> x29: ffff80009c4f77b0 x28: ffff0000d4c3f400 x27: 0000000000000000<br /> x26: dfff800000000000 x25: ffff70001389eee8 x24: 0000000000000003<br /> x23: 1fffe000182b6e7b x22: 0000000000000000 x21: ffff0000c15b73d8<br /> x20: 00000000ffffffef x19: ffff0000c15b7378 x18: 1fffe0003386f276<br /> x17: ffff80008f31e000 x16: ffff80008adbe98c x15: 0000000000000001<br /> x14: 1fffe0001b281550 x13: 0000000000000000 x12: 0000000000000000<br /> x11: ffff60001b281551 x10: 0000000000000003 x9 : 1c8922000a902c00<br /> x8 : 1c8922000a902c00 x7 : ffff800080485878 x6 : 0000000000000000<br /> x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff80008047843c<br /> x2 : 0000000000000001 x1 : ffff80008b3ebc40 x0 : 0000000000000001<br /> Call trace:<br /> btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 (P)<br /> btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074<br /> btrfs_remount_rw fs/btrfs/super.c:1319 [inline]<br /> btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543<br /> reconfigure_super+0x1d4/0x6f0 fs/super.c:1083<br /> do_remount fs/namespace.c:3365 [inline]<br /> path_mount+0xb34/0xde0 fs/namespace.c:4200<br /> do_mount fs/namespace.c:4221 [inline]<br /> __do_sys_mount fs/namespace.c:4432 [inline]<br /> __se_sys_mount fs/namespace.c:4409 [inline]<br /> __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767<br /> el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600<br /> irq event stamp: 330<br /> hardirqs last enabled at (329): [] raw_spin_rq_unlock_irq kernel/sched/sched.h:1525 [inline]<br /> hardirqs last enabled at (329): [] finish_lock_switch+0xb0/0x1c0 kernel/sched/core.c:5130<br /> hardirqs last disabled at (330): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:511<br /> softirqs last enabled at (10): [] local_bh_enable+0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using<br /> <br /> Running IDXD workloads in a container with the /dev directory mounted can<br /> trigger a call trace or even a kernel panic when the parent process of the<br /> container is terminated.<br /> <br /> This issue occurs because, under certain configurations, Docker does not<br /> properly propagate the mount replica back to the original mount point.<br /> <br /> In this case, when the user driver detaches, the WQ is destroyed but it<br /> still calls destroy_workqueue() attempting to completes all pending work.<br /> It&amp;#39;s necessary to check wq-&gt;wq and skip the drain if it no longer exists.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix a race between renames and directory logging<br /> <br /> We have a race between a rename and directory inode logging that if it<br /> happens and we crash/power fail before the rename completes, the next time<br /> the filesystem is mounted, the log replay code will end up deleting the<br /> file that was being renamed.<br /> <br /> This is best explained following a step by step analysis of an interleaving<br /> of steps that lead into this situation.<br /> <br /> Consider the initial conditions:<br /> <br /> 1) We are at transaction N;<br /> <br /> 2) We have directories A and B created in a past transaction (