Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: qcom: monaco: Reserve full Gunyah metadata region<br /> <br /> We observe spurious "Synchronous External Abort" exceptions<br /> (ESR=0x96000010) and kernel crashes on Monaco-based platforms.<br /> These faults are caused by the kernel inadvertently accessing<br /> hypervisor-owned memory that is not properly marked as reserved.<br /> <br /> &gt;From boot log, The Qualcomm hypervisor reports the memory range<br /> at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned:<br /> qhee_hyp_assign_remove_memory: 0x91a80000/0x80000 -&gt; ret 0<br /> <br /> However, the EFI memory map provided by firmware only reserves the<br /> subrange 0x91a40000–0x91a87fff (288 KiB). The remaining portion<br /> (0x91a88000–0x91afffff) is incorrectly reported as conventional<br /> memory (from efi debug):<br /> efi: 0x000091a40000-0x000091a87fff [Reserved...]<br /> efi: 0x000091a88000-0x0000938fffff [Conventional...]<br /> <br /> As a result, the allocator may hand out PFNs inside the hypervisor<br /> owned region, causing fatal aborts when the kernel accesses those<br /> addresses.<br /> <br /> Add a reserved-memory carveout for the Gunyah hypervisor metadata<br /> at 0x91a80000 (512 KiB) and mark it as no-map so Linux does not<br /> map or allocate from this area.<br /> <br /> For the record:<br /> Hyp version: gunyah-e78adb36e debug (2025-11-17 05:38:05 UTC)<br /> UEFI Ver: 6.0.260122.BOOT.MXF.1.0.c1-00449-KODIAKLA-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mshv_vtl: Fix vmemmap_shift exceeding MAX_FOLIO_ORDER<br /> <br /> When registering VTL0 memory via MSHV_ADD_VTL0_MEMORY, the kernel<br /> computes pgmap-&gt;vmemmap_shift as the number of trailing zeros in the<br /> OR of start_pfn and last_pfn, intending to use the largest compound<br /> page order both endpoints are aligned to.<br /> <br /> However, this value is not clamped to MAX_FOLIO_ORDER, so a<br /> sufficiently aligned range (e.g. physical range<br /> [0x800000000000, 0x800080000000), corresponding to start_pfn=0x800000000<br /> with 35 trailing zeros) can produce a shift larger than what<br /> memremap_pages() accepts, triggering a WARN and returning -EINVAL:<br /> <br /> WARNING: ... memremap_pages+0x512/0x650<br /> requested folio size unsupported<br /> <br /> The MAX_FOLIO_ORDER check was added by<br /> commit 646b67d57589 ("mm/memremap: reject unreasonable folio/compound<br /> page sizes in memremap_pages()").<br /> <br /> Fix this by clamping vmemmap_shift to MAX_FOLIO_ORDER so we always<br /> request the largest order the kernel supports, in those cases, rather<br /> than an out-of-range value.<br /> <br /> Also fix the error path to propagate the actual error code from<br /> devm_memremap_pages() instead of hard-coding -EFAULT, which was<br /> masking the real -EINVAL return.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid uninit-value access in f2fs_sanity_check_node_footer<br /> <br /> syzbot reported a f2fs bug as below:<br /> <br /> BUG: KMSAN: uninit-value in f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520<br /> f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520<br /> f2fs_finish_read_bio+0xe1e/0x1d60 fs/f2fs/data.c:177<br /> f2fs_read_end_io+0x6ab/0x2220 fs/f2fs/data.c:-1<br /> bio_endio+0x1006/0x1160 block/bio.c:1792<br /> submit_bio_noacct+0x533/0x2960 block/blk-core.c:891<br /> submit_bio+0x57a/0x620 block/blk-core.c:926<br /> blk_crypto_submit_bio include/linux/blk-crypto.h:203 [inline]<br /> f2fs_submit_read_bio+0x12c/0x360 fs/f2fs/data.c:557<br /> f2fs_submit_page_bio+0xee2/0x1450 fs/f2fs/data.c:775<br /> read_node_folio+0x384/0x4b0 fs/f2fs/node.c:1481<br /> __get_node_folio+0x5db/0x15d0 fs/f2fs/node.c:1576<br /> f2fs_get_inode_folio+0x40/0x50 fs/f2fs/node.c:1623<br /> do_read_inode fs/f2fs/inode.c:425 [inline]<br /> f2fs_iget+0x1209/0x9380 fs/f2fs/inode.c:596<br /> f2fs_fill_super+0x8f5a/0xb2e0 fs/f2fs/super.c:5184<br /> get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694<br /> get_tree_bdev+0x38/0x50 fs/super.c:1717<br /> f2fs_get_tree+0x35/0x40 fs/f2fs/super.c:5436<br /> vfs_get_tree+0xb3/0x5d0 fs/super.c:1754<br /> fc_mount fs/namespace.c:1193 [inline]<br /> do_new_mount_fc fs/namespace.c:3763 [inline]<br /> do_new_mount+0x885/0x1dd0 fs/namespace.c:3839<br /> path_mount+0x7a2/0x20b0 fs/namespace.c:4159<br /> do_mount fs/namespace.c:4172 [inline]<br /> __do_sys_mount fs/namespace.c:4361 [inline]<br /> __se_sys_mount+0x704/0x7f0 fs/namespace.c:4338<br /> __x64_sys_mount+0xe4/0x150 fs/namespace.c:4338<br /> x64_sys_call+0x39f0/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:166<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x134/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The root cause is: in f2fs_finish_read_bio(), we may access uninit data<br /> in folio if we failed to read the data from device into folio, let&amp;#39;s add<br /> a check condition to avoid such issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: reject direct access to nullable PTR_TO_BUF pointers<br /> <br /> check_mem_access() matches PTR_TO_BUF via base_type() which strips<br /> PTR_MAYBE_NULL, allowing direct dereference without a null check.<br /> <br /> Map iterator ctx-&gt;key and ctx-&gt;value are PTR_TO_BUF | PTR_MAYBE_NULL.<br /> On stop callbacks these are NULL, causing a kernel NULL dereference.<br /> <br /> Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the<br /> existing PTR_TO_BTF_ID pattern.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SMP: force responder MITM requirements before building the pairing response<br /> <br /> smp_cmd_pairing_req() currently builds the pairing response from the<br /> initiator auth_req before enforcing the local BT_SECURITY_HIGH<br /> requirement. If the initiator omits SMP_AUTH_MITM, the response can<br /> also omit it even though the local side still requires MITM.<br /> <br /> tk_request() then sees an auth value without SMP_AUTH_MITM and may<br /> select JUST_CFM, making method selection inconsistent with the pairing<br /> policy the responder already enforces.<br /> <br /> When the local side requires HIGH security, first verify that MITM can<br /> be achieved from the IO capabilities and then force SMP_AUTH_MITM in the<br /> response in both rsp.auth_req and auth. This keeps the responder auth bits<br /> and later method selection aligned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> interconnect: qcom: sm8450: Fix NULL pointer dereference in icc_link_nodes()<br /> <br /> The change to dynamic IDs for SM8450 platform interconnects left two links<br /> unconverted, fix it to avoid the NULL pointer dereference in runtime,<br /> when a pointer to a destination interconnect is not valid:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> <br /> Call trace:<br /> icc_link_nodes+0x3c/0x100 (P)<br /> qcom_icc_rpmh_probe+0x1b4/0x528<br /> platform_probe+0x64/0xc0<br /> really_probe+0xc4/0x2a8<br /> __driver_probe_device+0x80/0x140<br /> driver_probe_device+0x48/0x170<br /> __device_attach_driver+0xc0/0x148<br /> bus_for_each_drv+0x88/0xf0<br /> __device_attach+0xb0/0x1c0<br /> device_initial_probe+0x58/0x68<br /> bus_probe_device+0x40/0xb8<br /> deferred_probe_work_func+0x90/0xd0<br /> process_one_work+0x15c/0x3c0<br /> worker_thread+0x2e8/0x400<br /> kthread+0x150/0x208<br /> ret_from_fork+0x10/0x20<br /> Code: 900310f4 911d6294 91008280 94176078 (f94002a0)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/crypto: chacha: Zeroize permuted_state before it leaves scope<br /> <br /> Since the ChaCha permutation is invertible, the local variable<br /> &amp;#39;permuted_state&amp;#39; is sufficient to compute the original &amp;#39;state&amp;#39;, and thus<br /> the key, even after the permutation has been done.<br /> <br /> While the kernel is quite inconsistent about zeroizing secrets on the<br /> stack (and some prominent userspace crypto libraries don&amp;#39;t bother at all<br /> since it&amp;#39;s not guaranteed to work anyway), the kernel does try to do it<br /> as a best practice, especially in cases involving the RNG.<br /> <br /> Thus, explicitly zeroize &amp;#39;permuted_state&amp;#39; before it goes out of scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix NULL pointer dereference in dcn401_init_hw()<br /> <br /> dcn401_init_hw() assumes that update_bw_bounding_box() is valid when<br /> entering the update path. However, the existing condition:<br /> <br /> ((!fams2_enable &amp;&amp; update_bw_bounding_box) || freq_changed)<br /> <br /> does not guarantee this, as the freq_changed branch can evaluate to true<br /> independently of the callback pointer.<br /> <br /> This can result in calling update_bw_bounding_box() when it is NULL.<br /> <br /> Fix this by separating the update condition from the pointer checks and<br /> ensuring the callback, dc-&gt;clk_mgr, and bw_params are validated before<br /> use.<br /> <br /> Fixes the below:<br /> ../dc/hwss/dcn401/dcn401_hwseq.c:367 dcn401_init_hw() error: we previously assumed &amp;#39;dc-&gt;res_pool-&gt;funcs-&gt;update_bw_bounding_box&amp;#39; could be null (see line 362)<br /> <br /> (cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reserve enough transaction items for qgroup ioctls<br /> <br /> Currently our qgroup ioctls don&amp;#39;t reserve any space, they just do a<br /> transaction join, which does not reserve any space, neither for the quota<br /> tree updates nor for the delayed refs generated when updating the quota<br /> tree. The quota root uses the global block reserve, which is fine most of<br /> the time since we don&amp;#39;t expect a lot of updates to the quota root, or to<br /> be too close to -ENOSPC such that other critical metadata updates need to<br /> resort to the global reserve.<br /> <br /> However this is not optimal, as not reserving proper space may result in a<br /> transaction abort due to not reserving space for delayed refs and then<br /> abusing the use of the global block reserve.<br /> <br /> For example, the following reproducer (which is unlikely to model any<br /> real world use case, but just to illustrate the problem), triggers such a<br /> transaction abort due to -ENOSPC when running delayed refs:<br /> <br /> $ cat test.sh<br /> #!/bin/bash<br /> <br /> DEV=/dev/nullb0<br /> MNT=/mnt/nullb0<br /> <br /> umount $DEV &amp;&gt; /dev/null<br /> # Limit device to 1G so that it&amp;#39;s much faster to reproduce the issue.<br /> mkfs.btrfs -f -b 1G $DEV<br /> mount -o commit=600 $DEV $MNT<br /> <br /> fallocate -l 800M $MNT/filler<br /> btrfs quota enable $MNT<br /> <br /> for ((i = 1; i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: prevent possible UaF in addrconf_permanent_addr()<br /> <br /> The mentioned helper try to warn the user about an exceptional<br /> condition, but the message is delivered too late, accessing the ipv6<br /> after its possible deletion.<br /> <br /> Reorder the statement to avoid the possible UaF; while at it, place the<br /> warning outside the idev-&gt;lock as it needs no protection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Reinit dev-&gt;spinlock between attachments to low-level drivers<br /> <br /> `struct comedi_device` is the main controlling structure for a COMEDI<br /> device created by the COMEDI subsystem. It contains a member `spinlock`<br /> containing a spin-lock that is initialized by the COMEDI subsystem, but<br /> is reserved for use by a low-level driver attached to the COMEDI device<br /> (at least since commit 25436dc9d84f ("Staging: comedi: remove RT<br /> code")).<br /> <br /> Some COMEDI devices (those created on initialization of the COMEDI<br /> subsystem when the "comedi.comedi_num_legacy_minors" parameter is<br /> non-zero) can be attached to different low-level drivers over their<br /> lifetime using the `COMEDI_DEVCONFIG` ioctl command. This can result in<br /> inconsistent lock states being reported when there is a mismatch in the<br /> spin-lock locking levels used by each low-level driver to which the<br /> COMEDI device has been attached. Fix it by reinitializing<br /> `dev-&gt;spinlock` before calling the low-level driver&amp;#39;s `attach` function<br /> pointer if `CONFIG_LOCKDEP` is enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: core: Fix thermal zone device registration error path<br /> <br /> If thermal_zone_device_register_with_trips() fails after registering<br /> a thermal zone device, it needs to wait for the tz-&gt;removal completion<br /> like thermal_zone_device_unregister(), in case user space has managed<br /> to take a reference to the thermal zone device&amp;#39;s kobject, in which case<br /> thermal_release() may not be called by the error path itself and tz may<br /> be freed prematurely.<br /> <br /> Add the missing wait_for_completion() call to the thermal zone device<br /> registration error path.