Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc/tegra: cbb: Fix cross-fabric target timeout lookup<br /> <br /> When a fabric receives an error interrupt, the error may have<br /> occurred on a different fabric. The target timeout lookup was using<br /> the wrong base address (cbb-&gt;regs) with offsets from a different<br /> fabric&amp;#39;s target map, causing a kernel page fault.<br /> <br /> Unable to handle kernel paging request at virtual address ffff80000954cc00<br /> pc : tegra234_cbb_get_tmo_slv+0xc/0x28<br /> Call trace:<br /> tegra234_cbb_get_tmo_slv+0xc/0x28<br /> print_err_notifier+0x6c0/0x7d0<br /> tegra234_cbb_isr+0xe4/0x1b4<br /> <br /> Add tegra234_cbb_get_fabric() to look up the correct fabric device<br /> using fab_id, and use its base address for accessing target timeout<br /> registers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2/dlm: fix off-by-one in dlm_match_regions() region comparison<br /> <br /> The local-vs-remote region comparison loop uses &amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: max77705: Free allocated workqueue and fix removal order<br /> <br /> Use devm interface for allocating workqueue to fix two bugs at the same<br /> time:<br /> <br /> 1. Driver leaks the memory on remove(), because the workqueue is not<br /> destroyed.<br /> <br /> 2. Driver allocates workqueue and then registers interrupt handlers<br /> with devm interface. This means that probe error paths will not use a<br /> reversed order, but first destroy the workqueue and then, via devm<br /> release handlers, free the interrupt.<br /> <br /> The interrupt handler schedules work on this exact workqueue, thus if<br /> interrupt is hit in this short time window - after destroying<br /> workqueue, but before devm() frees the interrupt - the schedulled<br /> work will lead to use of freed memory.<br /> <br /> Change is not equivalent in the workqueue itself: use non-legacy API<br /> which does not set (__WQ_LEGACY | WQ_MEM_RECLAIM). The workqueue is<br /> used to update power supply (power_supply_changed()) status, thus there<br /> is no point to run it for memory reclaim. Note that dev_name() is not<br /> directly used in second argument to prevent possible unlikely parsing<br /> any "%" character in device name as format.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: pinconf-generic: Fully validate &amp;#39;pinmux&amp;#39; property<br /> <br /> The pinconf_generic_parse_dt_pinmux() assumes that the &amp;#39;pinmux&amp;#39; property<br /> is not empty when present. This might be not true. With that, the allocator<br /> will give a special value in return and not NULL which lead to the crash<br /> when trying to access that (invalid) memory. Fix that by fully validating<br /> &amp;#39;pinmux&amp;#39; value, including its length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()<br /> <br /> If queue entry or DMA descriptor list allocation fails in<br /> airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a<br /> NULL pointer dereference running netif_napi_del() for RX queue NAPIs<br /> since netif_napi_add() has never been executed to this particular RX NAPI.<br /> The issue is due to the early ndesc initialization in<br /> airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc<br /> value to check if the queue is properly initialized. Fix the issue moving<br /> ndesc initialization at end of airoha_qdma_init_tx routine.<br /> Move page_pool allocation after descriptor list allocation in order to<br /> avoid memory leaks if desc allocation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()<br /> <br /> If queue entry list allocation fails in airoha_qdma_init_tx_queue routine,<br /> airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference<br /> accessing the queue entry array. The issue is due to the early ndesc<br /> initialization in airoha_qdma_init_tx_queue(). Fix the issue moving ndesc<br /> initialization at end of airoha_qdma_init_tx routine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: enetc: fix NTMP DMA use-after-free issue<br /> <br /> The AI-generated review reported a potential DMA use-after-free issue<br /> [1]. If netc_xmit_ntmp_cmd() times out and returns an error, the pending<br /> command is not explicitly aborted, while ntmp_free_data_mem()<br /> unconditionally frees the DMA buffer. If the buffer has already been<br /> reallocated elsewhere, this may lead to silent memory corruption. Because<br /> the hardware eventually processes the pending command and perform a DMA<br /> write of the response to the physical address of the freed buffer.<br /> <br /> To resolve this issue, this patch does the following modifications:<br /> <br /> 1. Convert cbdr-&gt;ring_lock from a spinlock to a mutex<br /> <br /> The lock was originally a spinlock in case NTMP operations might be<br /> invoked from atomic context. After downstream support for all NTMP<br /> tables, no such usage has materialized. A mutex lock is now required<br /> because the driver now needs to reclaim used BDs and release associated<br /> DMA memory within the lock&amp;#39;s context, while dma_free_coherent() might<br /> sleep.<br /> <br /> 2. Introduce software command BD (struct netc_swcbd)<br /> <br /> The hardware write-back overwrites the addr and len fields of the BD,<br /> so the driver cannot rely on the hardware BD to free the associated DMA<br /> memory. The driver now maintains a software shadow BD storing the DMA<br /> buffer pointer, DMA address, and size. And netc_xmit_ntmp_cmd() only<br /> reclaims older BDs when the number of used BDs reaches<br /> NETC_CBDR_CLEAN_WORK (16). The software BD enables correct DMA memory<br /> release. With this, struct ntmp_dma_buf and ntmp_free_data_mem() are no<br /> longer needed and are removed.<br /> <br /> 3. Require callers to hold ring_lock across netc_xmit_ntmp_cmd()<br /> <br /> netc_xmit_ntmp_cmd() releases the ring_lock before the caller finishes<br /> consuming the response. At this point, if a concurrent thread submits<br /> a new command, it may trigger ntmp_clean_cbdr() and free the DMA buffer<br /> while it is still in use. Move ring_lock ownership to the caller to<br /> ensure the response buffer cannot be reclaimed prematurely. So the<br /> helpers ntmp_select_and_lock_cbdr() and ntmp_unlock_cbdr() are added.<br /> <br /> These changes eliminate the DMA use-after-free condition and ensure safe<br /> and consistent BD reclamation and DMA buffer lifecycle management.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: hvc_iucv: fix off-by-one in number of supported devices<br /> <br /> MAX_HVC_IUCV_LINES == HVC_ALLOC_TTY_ADAPTERS == 8.<br /> This is the number of entries in:<br /> static struct hvc_iucv_private *hvc_iucv_table[MAX_HVC_IUCV_LINES];<br /> <br /> Sometimes hvc_iucv_table[] is limited by:<br /> (a) if (num &gt; hvc_iucv_devices) // for error detection<br /> or<br /> (b) for (i = 0; i MAX_HVC_IUCV_LINES)<br /> <br /> If hvc_iucv_devices == 8, (a) allows the code to access hvc_iucv_table[8].<br /> Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ps883x: Fix Oops at unbind<br /> <br /> When trying to unbind a device in order to bind to it vfio-platform as:<br /> <br /> echo bc0000.geniqup &gt; /sys/bus/platform/devices/bc0000.geniqup/driver/unbind<br /> <br /> I get the following Oops:<br /> <br /> [ 436.478639] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> [ 436.487762] Mem abort info:<br /> [ 436.490716] ESR = 0x0000000096000004<br /> [ 436.494595] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 436.500071] SET = 0, FnV = 0<br /> [ 436.503250] EA = 0, S1PTW = 0<br /> [ 436.506505] FSC = 0x04: level 0 translation fault<br /> [ 436.511533] Data abort info:<br /> [ 436.514558] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 436.520215] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 436.525436] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 436.530918] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008861a9000<br /> [ 436.537554] [0000000000000020] pgd=0000000000000000, p4d=0000000000000000<br /> [ 436.544548] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 436.550374] Modules linked in:<br /> [ 436.553542] CPU: 2 UID: 0 PID: 671 Comm: bash Tainted: G W 7.0.0-rc3-g56fcdd0911a5-dirty #2 PREEMPT<br /> [ 436.564440] Tainted: [W]=WARN<br /> [ 436.567515] Hardware name: LENOVO 91B6CTO1WW/3796, BIOS O6NKT3BA 05/02/2025<br /> [ 436.574675] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> [ 436.581841] pc : ps883x_retimer_remove+0x14/0x94<br /> [ 436.586605] lr : i2c_device_remove+0x28/0x84<br /> [ 436.591017] sp : ffff8000847137c0<br /> <br /> That&amp;#39;s because the ps883x_retimer_remove() retrieves the driver data<br /> from i2c_get_clientdata() which was never set at probe. So, add<br /> i2c_set_clientdata() at the end of the probe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sg: Resolve soft lockup issue when opening /dev/sgX<br /> <br /> The parameter def_reserved_size defines the default buffer size reserved<br /> for each Sg_fd and should be restricted to a range between 0 and 1,048,576<br /> (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the<br /> function sg_proc_write_dressz enforces this limit, it is possible to bypass<br /> it by directly modifying the module parameter as shown below, which then<br /> causes a soft lockup:<br /> <br /> echo -1 &gt; /sys/module/sg/parameters/def_reserved_size<br /> exec 4 /dev/sg0<br /> <br /> watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537]<br /> Modules loaded:<br /> CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134,<br /> PREEMPT disabled<br /> Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version<br /> 1.16.1-2.fc37 dated 04/01/2014<br /> ...<br /> Call Trace:<br /> <br /> sg_build_reserve+0x5c/0xa0<br /> sg_add_sfp+0x168/0x270<br /> sg_open+0x16e/0x340<br /> chrdev_open+0xbe/0x230<br /> do_dentry_open+0x175/0x480<br /> vfs_open+0x34/0xf0<br /> do_open+0x265/0x3d0<br /> path_openat+0x110/0x290<br /> do_filp_open+0xc3/0x170<br /> do_sys_openat2+0x71/0xe0<br /> __x64_sys_openat+0x6d/0xa0<br /> do_syscall_64+0x62/0x310<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The fix is to use module_param_cb to validate and reject invalid values<br /> assigned to def_reserved_size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: protect extension_list reading with sb_lock in f2fs_sbi_show()<br /> <br /> In f2fs_sbi_show(), the extension_list, extension_count and<br /> hot_ext_count are read without holding sbi-&gt;sb_lock. If a concurrent<br /> sysfs store modifies the extension list via f2fs_update_extension_list(),<br /> the show path may read inconsistent count and array contents, potentially<br /> leading to out-of-bounds access or displaying stale data.<br /> <br /> Fix this by holding sb_lock around the entire extension list read<br /> and format operation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: eip93 - fix hmac setkey algo selection<br /> <br /> eip93_hmac_setkey() allocates a temporary ahash transform for<br /> computing HMAC ipad/opad key material. The allocation uses the<br /> driver-specific cra_driver_name (e.g. "sha256-eip93") but passes<br /> CRYPTO_ALG_ASYNC as the mask, which excludes async algorithms.<br /> <br /> Since the EIP93 hash algorithms are the only ones registered<br /> under those driver names and they are inherently async, the<br /> lookup is self-contradictory and always fails with -ENOENT.<br /> <br /> When called from the AEAD setkey path, this failure leaves the<br /> SA record partially initialized with zeroed digest fields. A<br /> subsequent crypto operation then dereferences a NULL pointer in<br /> the request context, resulting in a kernel panic:<br /> <br /> ```<br /> pc : eip93_aead_handle_result+0xc8c/0x1240 [crypto_hw_eip93]<br /> lr : eip93_aead_handle_result+0xbec/0x1240 [crypto_hw_eip93]<br /> sp : ffffffc082feb820<br /> x29: ffffffc082feb820 x28: ffffff8011043980 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffffffc078da0bc8 x24: 0000000091043980<br /> x23: ffffff8004d59e50 x22: ffffff8004d59410 x21: ffffff8004d593c0<br /> x20: ffffff8004d593c0 x19: ffffff8004d4f300 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000007fda7aa498<br /> x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000000 x10: fffffffff8127a80 x9 : 0000000000000000<br /> x8 : ffffff8004d4f380 x7 : 0000000000000000 x6 : 000000000000003f<br /> x5 : 0000000000000040 x4 : 0000000000000008 x3 : 0000000000000009<br /> x2 : 0000000000000008 x1 : 0000000028000003 x0 : ffffff8004d388c0<br /> Code: 910142b6 f94012e0 f9002aa0 f90006d3 (f9400740)<br /> ```<br /> <br /> The reported symbol eip93_aead_handle_result+0xc8c is a<br /> resolution artifact from static functions being merged under<br /> the nearest exported symbol. Decoding the faulting sequence:<br /> <br /> ```<br /> 910142b6 ADD X22, X21, #0x50<br /> f94012e0 LDR X0, [X23, #0x20]<br /> f9002aa0 STR X0, [X21, #0x50]<br /> f90006d3 STR X19, [X22, #0x8]<br /> f9400740 LDR X0, [X26, #0x8]<br /> ```<br /> <br /> The faulting LDR at [X26, #0x8] is loading ctx-&gt;flags<br /> (offset 8 in eip93_hash_ctx), where ctx has been resolved<br /> to NULL from a partially initialized or unreachable<br /> transform context following the failed setkey.<br /> <br /> Fix this by dropping the CRYPTO_ALG_ASYNC mask from the<br /> crypto_alloc_ahash() call. The code already handles async<br /> completion correctly via crypto_wait_req(), so there is no<br /> requirement to restrict the lookup to synchronous algorithms.<br /> <br /> Note that hashing a single 64-byte block through the hardware<br /> is likely slower than doing it in software due to the DMA<br /> round-trip overhead, but offloading it may still spare CPU<br /> cycles on the slower embedded cores where this IP is found.<br /> <br /> [Detailed investigation report of this bug]