Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vm: move xe_svm_init() earlier<br /> <br /> In xe_vm_close_and_put() we need to be able to call xe_svm_fini(),<br /> however during vm creation we can call this on the error path, before<br /> having actually initialised the svm state, leading to various splats<br /> followed by a fatal NPD.<br /> <br /> (cherry picked from commit 4f296d77cf49fcb5f90b4674123ad7f3a0676165)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> seg6: Fix validation of nexthop addresses<br /> <br /> The kernel currently validates that the length of the provided nexthop<br /> address does not exceed the specified length. This can lead to the<br /> kernel reading uninitialized memory if user space provided a shorter<br /> length than the specified one.<br /> <br /> Fix by validating that the provided length exactly matches the specified<br /> one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix NULL access in assign channel context handler<br /> <br /> Currently, when ath12k_mac_assign_vif_to_vdev() fails, the radio handle<br /> (ar) gets accessed from the link VIF handle (arvif) for debug logging, This<br /> is incorrect. In the fail scenario, radio handle is NULL. Fix the NULL<br /> access, avoid radio handle access by moving to the hardware debug logging<br /> helper function (ath12k_hw_warn).<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1<br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/amlogic: Replace smp_processor_id() with raw_smp_processor_id() in meson_ddr_pmu_create()<br /> <br /> The Amlogic DDR PMU driver meson_ddr_pmu_create() function incorrectly uses<br /> smp_processor_id(), which assumes disabled preemption. This leads to kernel<br /> warnings during module loading because meson_ddr_pmu_create() can be called<br /> in a preemptible context.<br /> <br /> Following kernel warning and stack trace:<br /> [ 31.745138] [ T2289] BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/2289<br /> [ 31.745154] [ T2289] caller is debug_smp_processor_id+0x28/0x38<br /> [ 31.745172] [ T2289] CPU: 4 UID: 0 PID: 2289 Comm: (udev-worker) Tainted: GW 6.14.0-0-MANJARO-ARM #1 59519addcbca6ba8de735e151fd7b9e97aac7ff0<br /> [ 31.745181] [ T2289] Tainted: [W]=WARN<br /> [ 31.745183] [ T2289] Hardware name: Hardkernel ODROID-N2Plus (DT)<br /> [ 31.745188] [ T2289] Call trace:<br /> [ 31.745191] [ T2289] show_stack+0x28/0x40 (C)<br /> [ 31.745199] [ T2289] dump_stack_lvl+0x4c/0x198<br /> [ 31.745205] [ T2289] dump_stack+0x20/0x50<br /> [ 31.745209] [ T2289] check_preemption_disabled+0xec/0xf0<br /> [ 31.745213] [ T2289] debug_smp_processor_id+0x28/0x38<br /> [ 31.745216] [ T2289] meson_ddr_pmu_create+0x200/0x560 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]<br /> [ 31.745237] [ T2289] g12_ddr_pmu_probe+0x20/0x38 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]<br /> [ 31.745246] [ T2289] platform_probe+0x98/0xe0<br /> [ 31.745254] [ T2289] really_probe+0x144/0x3f8<br /> [ 31.745258] [ T2289] __driver_probe_device+0xb8/0x180<br /> [ 31.745261] [ T2289] driver_probe_device+0x54/0x268<br /> [ 31.745264] [ T2289] __driver_attach+0x11c/0x288<br /> [ 31.745267] [ T2289] bus_for_each_dev+0xfc/0x160<br /> [ 31.745274] [ T2289] driver_attach+0x34/0x50<br /> [ 31.745277] [ T2289] bus_add_driver+0x160/0x2b0<br /> [ 31.745281] [ T2289] driver_register+0x78/0x120<br /> [ 31.745285] [ T2289] __platform_driver_register+0x30/0x48<br /> [ 31.745288] [ T2289] init_module+0x30/0xfe0 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]<br /> [ 31.745298] [ T2289] do_one_initcall+0x11c/0x438<br /> [ 31.745303] [ T2289] do_init_module+0x68/0x228<br /> [ 31.745311] [ T2289] load_module+0x118c/0x13a8<br /> [ 31.745315] [ T2289] __arm64_sys_finit_module+0x274/0x390<br /> [ 31.745320] [ T2289] invoke_syscall+0x74/0x108<br /> [ 31.745326] [ T2289] el0_svc_common+0x90/0xf8<br /> [ 31.745330] [ T2289] do_el0_svc+0x2c/0x48<br /> [ 31.745333] [ T2289] el0_svc+0x60/0x150<br /> [ 31.745337] [ T2289] el0t_64_sync_handler+0x80/0x118<br /> [ 31.745341] [ T2289] el0t_64_sync+0x1b8/0x1c0<br /> <br /> Changes replaces smp_processor_id() with raw_smp_processor_id() to<br /> ensure safe CPU ID retrieval in preemptible contexts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: platform_profile: Avoid initializing on non-ACPI platforms<br /> <br /> The platform profile driver is loaded even on platforms that do not have<br /> ACPI enabled. The initialization of the sysfs entries was recently moved<br /> from platform_profile_register() to the module init call, and those<br /> entries need acpi_kobj to be initialized which is not the case when ACPI<br /> is disabled.<br /> <br /> This results in the following warning:<br /> <br /> WARNING: CPU: 5 PID: 1 at fs/sysfs/group.c:131 internal_create_group+0xa22/0xdd8<br /> Modules linked in:<br /> CPU: 5 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.15.0-rc7-dirty #6 PREEMPT<br /> Tainted: [W]=WARN<br /> Hardware name: riscv-virtio,qemu (DT)<br /> epc : internal_create_group+0xa22/0xdd8<br /> ra : internal_create_group+0xa22/0xdd8<br /> <br /> Call Trace:<br /> <br /> internal_create_group+0xa22/0xdd8<br /> sysfs_create_group+0x22/0x2e<br /> platform_profile_init+0x74/0xb2<br /> do_one_initcall+0x198/0xa9e<br /> kernel_init_freeable+0x6d8/0x780<br /> kernel_init+0x28/0x24c<br /> ret_from_fork+0xe/0x18<br /> <br /> Fix this by checking if ACPI is enabled before trying to create sysfs<br /> entries.<br /> <br /> [ rjw: Subject and changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: EM: Fix potential division-by-zero error in em_compute_costs()<br /> <br /> When the device is of a non-CPU type, table[i].performance won&amp;#39;t be<br /> initialized in the previous em_init_performance(), resulting in division<br /> by zero when calculating costs in em_compute_costs().<br /> <br /> Since the &amp;#39;cost&amp;#39; algorithm is only used for EAS energy efficiency<br /> calculations and is currently not utilized by other device drivers, we<br /> should add the _is_cpu_device(dev) check to prevent this division-by-zero<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/skx_common: Fix general protection fault<br /> <br /> After loading i10nm_edac (which automatically loads skx_edac_common), if<br /> unload only i10nm_edac, then reload it and perform error injection testing,<br /> a general protection fault may occur:<br /> <br /> mce: [Hardware Error]: Machine check events logged<br /> Oops: general protection fault ...<br /> ...<br /> Workqueue: events mce_gen_pool_process<br /> RIP: 0010:string+0x53/0xe0<br /> ...<br /> Call Trace:<br /> <br /> ? die_addr+0x37/0x90<br /> ? exc_general_protection+0x1e7/0x3f0<br /> ? asm_exc_general_protection+0x26/0x30<br /> ? string+0x53/0xe0<br /> vsnprintf+0x23e/0x4c0<br /> snprintf+0x4d/0x70<br /> skx_adxl_decode+0x16a/0x330 [skx_edac_common]<br /> skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common]<br /> skx_mce_check_error+0x17/0x20 [skx_edac_common]<br /> ...<br /> <br /> The issue arose was because the variable &amp;#39;adxl_component_count&amp;#39; (inside<br /> skx_edac_common), which counts the ADXL components, was not reset. During<br /> the reloading of i10nm_edac, the count was incremented by the actual number<br /> of ADXL components again, resulting in a count that was double the real<br /> number of ADXL components. This led to an out-of-bounds reference to the<br /> ADXL component array, causing the general protection fault above.<br /> <br /> Fix this issue by resetting the &amp;#39;adxl_component_count&amp;#39; in adxl_put(),<br /> which is called during the unloading of {skx,i10nm}_edac.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY()<br /> <br /> ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(),<br /> in the case the codec dai_name will be null.<br /> <br /> Avoid a crash if the device tree is not assigning a codec<br /> to these links.<br /> <br /> [ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 1.181065] Mem abort info:<br /> [ 1.181420] ESR = 0x0000000096000004<br /> [ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 1.182576] SET = 0, FnV = 0<br /> [ 1.182964] EA = 0, S1PTW = 0<br /> [ 1.183367] FSC = 0x04: level 0 translation fault<br /> [ 1.183983] Data abort info:<br /> [ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 1.186439] [0000000000000000] user address but active_mm is swapper<br /> [ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 1.188029] Modules linked in:<br /> [ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85<br /> [ 1.189515] Hardware name: Radxa NIO 12L (DT)<br /> [ 1.190065] Workqueue: events_unbound deferred_probe_work_func<br /> [ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1.191683] pc : __pi_strcmp+0x24/0x140<br /> [ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0<br /> [ 1.192854] sp : ffff800083473970<br /> [ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002<br /> [ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88<br /> [ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8<br /> [ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff<br /> [ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006<br /> [ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374<br /> [ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018<br /> [ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000<br /> [ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d<br /> [ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000<br /> [ 1.202236] Call trace:<br /> [ 1.202545] __pi_strcmp+0x24/0x140 (P)<br /> [ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8<br /> [ 1.203644] platform_probe+0x70/0xe8<br /> [ 1.204106] really_probe+0xc8/0x3a0<br /> [ 1.204556] __driver_probe_device+0x84/0x160<br /> [ 1.205104] driver_probe_device+0x44/0x130<br /> [ 1.205630] __device_attach_driver+0xc4/0x170<br /> [ 1.206189] bus_for_each_drv+0x8c/0xf8<br /> [ 1.206672] __device_attach+0xa8/0x1c8<br /> [ 1.207155] device_initial_probe+0x1c/0x30<br /> [ 1.207681] bus_probe_device+0xb0/0xc0<br /> [ 1.208165] deferred_probe_work_func+0xa4/0x100<br /> [ 1.208747] process_one_work+0x158/0x3e0<br /> [ 1.209254] worker_thread+0x2c4/0x3e8<br /> [ 1.209727] kthread+0x134/0x1f0<br /> [ 1.210136] ret_from_fork+0x10/0x20<br /> [ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402)<br /> [ 1.211355] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()<br /> <br /> Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():<br /> <br /> 1] If dma_map_sg() fails for areq-&gt;dst, the device driver would try to free<br /> DMA memory it has not allocated in the first place. To fix this, on the<br /> "theend_sgs" error path, call dma unmap only if the corresponding dma<br /> map was successful.<br /> <br /> 2] If the dma_map_single() call for the IV fails, the device driver would<br /> try to free an invalid DMA memory address on the "theend_iv" path:<br /> ------------[ cut here ]------------<br /> DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address<br /> WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90<br /> Modules linked in: skcipher_example(O+)<br /> CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT<br /> Tainted: [O]=OOT_MODULE<br /> Hardware name: OrangePi Zero2 (DT)<br /> pc : check_unmap+0x123c/0x1b90<br /> lr : check_unmap+0x123c/0x1b90<br /> ...<br /> Call trace:<br /> check_unmap+0x123c/0x1b90 (P)<br /> debug_dma_unmap_page+0xac/0xc0<br /> dma_unmap_page_attrs+0x1f4/0x5fc<br /> sun8i_ce_cipher_do_one+0x1bd4/0x1f40<br /> crypto_pump_work+0x334/0x6e0<br /> kthread_worker_fn+0x21c/0x438<br /> kthread+0x374/0x664<br /> ret_from_fork+0x10/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> To fix this, check for !dma_mapping_error() before calling<br /> dma_unmap_single() on the "theend_iv" path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmem: zynqmp_nvmem: unbreak driver after cleanup<br /> <br /> Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup")<br /> changed the driver to expect the device pointer to be passed as the<br /> "context", but in nvmem the context parameter comes from nvmem_config.priv<br /> which is never set - Leading to null pointer exceptions when the device is<br /> accessed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: don&amp;#39;t use submit_bio_noacct_nocheck in blk_zone_wplug_bio_work<br /> <br /> Bios queued up in the zone write plug have already gone through all all<br /> preparation in the submit_bio path, including the freeze protection.<br /> <br /> Submitting them through submit_bio_noacct_nocheck duplicates the work<br /> and can can cause deadlocks when freezing a queue with pending bio<br /> write plugs.<br /> <br /> Go straight to -&gt;submit_bio or blk_mq_submit_bio to bypass the<br /> superfluous extra freeze protection and checks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: at91: Fix possible out-of-boundary access<br /> <br /> at91_gpio_probe() doesn&amp;#39;t check that given OF alias is not available or<br /> something went wrong when trying to get it. This might have consequences<br /> when accessing gpio_chips array with that value as an index. Note, that<br /> BUG() can be compiled out and hence won&amp;#39;t actually perform the required<br /> checks.