Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: arm-ni: Fix missing platform_set_drvdata()<br /> <br /> Add missing platform_set_drvdata in arm_ni_probe(), otherwise<br /> calling platform_get_drvdata() in remove returns NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table<br /> <br /> The function atomctrl_initialize_mc_reg_table() and<br /> atomctrl_initialize_mc_reg_table_v2_2() does not check the return<br /> value of smu_atom_get_data_table(). If smu_atom_get_data_table()<br /> fails to retrieve vram_info, it returns NULL which is later<br /> dereferenced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: eir: Fix possible crashes on eir_create_adv_data<br /> <br /> eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER<br /> without checking if that would fit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix NULL pointer deference on eir_get_service_data<br /> <br /> The len parameter is considered optional so it can be NULL so it cannot<br /> be used for skipping to next entry of EIR_SERVICE_DATA.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: remove ptp-&gt;n_vclocks check logic in ptp_vclock_in_use()<br /> <br /> There is no disagreement that we should check both ptp-&gt;is_virtual_clock<br /> and ptp-&gt;n_vclocks to check if the ptp virtual clock is in use.<br /> <br /> However, when we acquire ptp-&gt;n_vclocks_mux to read ptp-&gt;n_vclocks in<br /> ptp_vclock_in_use(), we observe a recursive lock in the call trace<br /> starting from n_vclocks_store().<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.15.0-rc6 #1 Not tainted<br /> --------------------------------------------<br /> syz.0.1540/13807 is trying to acquire lock:<br /> ffff888035a24868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]<br /> ffff888035a24868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415<br /> <br /> but task is already holding lock:<br /> ffff888030704868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;ptp-&gt;n_vclocks_mux);<br /> lock(&amp;ptp-&gt;n_vclocks_mux);<br /> <br /> *** DEADLOCK ***<br /> ....<br /> ============================================<br /> <br /> The best way to solve this is to remove the logic that checks<br /> ptp-&gt;n_vclocks in ptp_vclock_in_use().<br /> <br /> The reason why this is appropriate is that any path that uses<br /> ptp-&gt;n_vclocks must unconditionally check if ptp-&gt;n_vclocks is greater<br /> than 0 before unregistering vclocks, and all functions are already<br /> written this way. And in the function that uses ptp-&gt;n_vclocks, we<br /> already get ptp-&gt;n_vclocks_mux before unregistering vclocks.<br /> <br /> Therefore, we need to remove the redundant check for ptp-&gt;n_vclocks in<br /> ptp_vclock_in_use() to prevent recursive locking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/fhandle.c: fix a race in call of has_locked_children()<br /> <br /> may_decode_fh() is calling has_locked_children() while holding no locks.<br /> That&amp;#39;s an oopsable race...<br /> <br /> The rest of the callers are safe since they are holding namespace_sem and<br /> are guaranteed a positive refcount on the mount in question.<br /> <br /> Rename the current has_locked_children() to __has_locked_children(), make<br /> it static and switch the fs/namespace.c users to it.<br /> <br /> Make has_locked_children() a wrapper for __has_locked_children(), calling<br /> the latter under read_seqlock_excl(&amp;mount_lock).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: avs: Verify content returned by parse_int_array()<br /> <br /> The first element of the returned array stores its length. If it is 0,<br /> any manipulation beyond the element at index 0 ends with null-ptr-deref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: avs: Fix possible null-ptr-deref when initing hw<br /> <br /> Search result of avs_dai_find_path_template() shall be verified before<br /> being used. As &amp;#39;template&amp;#39; is already known when<br /> avs_hw_constraints_init() is fired, drop the search entirely.

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.