Vulnerabilities

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 (

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()<br /> <br /> Temporarily clear the preallocation flag when explicitly requesting<br /> allocations. Pre-existing allocations are already counted against the<br /> request through mas_node_count_gfp(), but the allocations will not happen<br /> if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid<br /> re-allocating in bulk allocation mode, and to detect issues with<br /> preallocation calculations.<br /> <br /> The MA_STATE_PREALLOC flag should also always be set on zero allocations<br /> so that detection of underflow allocations will print a WARN_ON() during<br /> consumption.<br /> <br /> User visible effect of this flaw is a WARN_ON() followed by a null pointer<br /> dereference when subsequent requests for larger number of nodes is<br /> ignored, such as the vma merge retry in mmap_region() caused by drivers<br /> altering the vma flags (which happens in v6.6, at least)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/tegra: Fix a possible null pointer dereference<br /> <br /> In tegra_crtc_reset(), new memory is allocated with kzalloc(), but<br /> no check is performed. Before calling __drm_atomic_helper_crtc_reset,<br /> state should be checked to prevent possible null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null pointer check for get_first_active_display()<br /> <br /> The function mod_hdcp_hdcp1_enable_encryption() calls the function<br /> get_first_active_display(), but does not check its return value.<br /> The return value is a null pointer if the display list is empty.<br /> This will lead to a null pointer dereference in<br /> mod_hdcp_hdcp2_enable_encryption().<br /> <br /> Add a null pointer check for get_first_active_display() and return<br /> MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc: Explicitly exit CT safe mode on unwind<br /> <br /> During driver probe we might be briefly using CT safe mode, which<br /> is based on a delayed work, but usually we are able to stop this<br /> once we have IRQ fully operational. However, if we abort the probe<br /> quite early then during unwind we might try to destroy the workqueue<br /> while there is still a pending delayed work that attempts to restart<br /> itself which triggers a WARN.<br /> <br /> This was recently observed during unsuccessful VF initialization:<br /> <br /> [ ] xe 0000:00:02.1: probe with driver xe failed with error -62<br /> [ ] ------------[ cut here ]------------<br /> [ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq<br /> [ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710<br /> [ ] RIP: 0010:__queue_work+0x287/0x710<br /> [ ] Call Trace:<br /> [ ] delayed_work_timer_fn+0x19/0x30<br /> [ ] call_timer_fn+0xa1/0x2a0<br /> <br /> Exit the CT safe mode on unwind to avoid that warning.<br /> <br /> (cherry picked from commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)