Threat Intelligence Database

In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Detach sync cmd buffer on interrupted wait mwifiex synchronous commands keep the caller-provided data buffer in cmd_node->data_buf. Several callers pass stack-allocated objects there. If wait_event_interruptible_timeout() is interrupted, the caller can return and release that stack object while the firmware command is still the current command. A late firmware response then reaches the normal response handler, which can copy data through cmd_node->data_buf into the stale stack address. This fixes a stack corruption observed during repeated association and disassociation cycles. The panic trace showed the command wait being interrupted immediately before a bad pointer dereference: cmd_wait_q terminated: -512 Unable to handle kernel paging request at virtual address 002c583837384662 Kernel panic - not syncing: stack-protector: Kernel stack is corrupted ... Tainted: [M]=MACHINE_CHECK The fault address decodes as little-endian ASCII: 0x002c583837384662 -> "bF878X,\0" which is a fragment of the VERSION_EXT firmware string exposed as debugfs "verext": w8997o-V4, RF878X, FP92, 16.92.21.p153.7 The same runs also showed corrupted control data containing: 0x2400372e333531 -> "153.7\0$" which is the tail of the same VERSION_EXT string. This points at a late VERSION_EXT response writing through a stale stack-backed data_buf after the interrupted wait returned. After cancelling pending commands on an interrupted or timed-out wait, detach the caller-owned data buffer from the still-current command. This preserves the existing command cancellation behaviour while preventing a late response from writing through a pointer whose lifetime ended with the waiting caller. Tested on an i.MX8MP board using an 88W8997.

In the Linux kernel, the following vulnerability has been resolved: net: enetc: fix potential divide-by-zero when num_vsi is zero For i.MX94 series, all the standalone ENETCs do not support SR-IOV, so pf->caps.num_vsi is zero. This leads to a divide-by-zero in enetc4_default_rings_allocation() when distributing rings among PF and VFs. Division by zero is undefined behavior in C. On ARM64, the UDIV/SDIV instructions silently return zero rather than raising an exception, so the issue does not cause a visible crash. However, relying on this behavior is incorrect and poses a cross-platform compatibility risk. Add an explicit check for num_vsi == 0 and return early after the PF's rings have been configured.

Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - Foo-over-UDP (FOU); - ARM64 architecture; - x86 architecture; - Block layer subsystem; - Drivers core; - Null block device driver; - Bluetooth drivers; - Counter interface drivers; - DMA engine subsystem; - DPLL subsystem; - GPIO subsystem; - GPU drivers; - I2C subsystem; - IIO ADC drivers; - IIO subsystem; - InfiniBand drivers; - On-Chip Interconnect management framework; - IOMMU subsystem; - IRQ chip drivers; - Modular ISDN driver; - LED subsystem; - Multiple devices driver; - Media drivers; - UACCE accelerator framework; - MMC subsystem; - Ethernet bonding driver; - Network drivers; - Mellanox network drivers; - Texas Instruments network drivers; - NVME drivers; - Device tree and open firmware driver; - PHY drivers; - x86 platform drivers; - i.MX PM domains; - SCSI subsystem; - SLIMbus drivers; - SPI subsystem; - TTY drivers; - USB Host Controller drivers; - W1 Dallas's 1-wire bus driver; - Xen hypervisor drivers; - BTRFS file system; - EFI Variable file system; - File systems infrastructure; - Ext4 file system; - FUSE (File system in Userspace); - Network file systems library; - Network file system (NFS) client; - Network file system (NFS) server daemon; - SMB network file system; - Memory Management; - Memory management; - Scheduler infrastructure; - Tracing infrastructure; - IPv4 networking; - Netfilter; - NFC subsystem; - Network traffic control; - TCP network protocol; - io_uring subsystem; - Perf events; - Locking primitives; - Hibernation control; - Timer subsystem; - BPF subsystem; - Floating proportions library; - Bluetooth subsystem; - CAN network layer; - Ceph Core library; - Networking core; - IPv6 networking; - L2TP protocol; - MAC80211 subsystem; - Multipath TCP; - NET/ROM layer; - RxRPC session sockets; - SCTP protocol; - SMC sockets; - VMware vSockets driver; - Wireless networking; - ALSA AC97 driver; - Creative Sound Blaster X-Fi driver; - Texas InstrumentS Audio (ASoC/HDA) drivers; - USB sound devices; (CVE-2025-71158, CVE-2025-71160, CVE-2025-71161, CVE-2025-71162, CVE-2025-71163, CVE-2025-71180, CVE-2025-71182, CVE-2025-71183, CVE-2025-71184, CVE-2025-71185, CVE-2025-71186, CVE-2025-71187, CVE-2025-71188, CVE-2025-71189, CVE-2025-71190, CVE-2025-71191, CVE-2025-71192, CVE-2025-71193, CVE-2025-71194, CVE-2025-71195, CVE-2025-71196, CVE-2025-71197, CVE-2025-71198, CVE-2025-71199, CVE-2025-71200, CVE-2025-71201, CVE-2026-22976, CVE-2026-22977, CVE-2026-22978, CVE-2026-22979, CVE-2026-22980, CVE-2026-22981, CVE-2026-22982, CVE-2026-22985, CVE-2026-22986, CVE-2026-22987, CVE-2026-22989, CVE-2026-22990, CVE-2026-22991, CVE-2026-22992, CVE-2026-22993, CVE-2026-22994, CVE-2026-22996, CVE-2026-22997, CVE-2026-22998, CVE-2026-22999, CVE-2026-23000, CVE-2026-23001, CVE-2026-23002, CVE-2026-23003, CVE-2026-23004, CVE-2026-23005, CVE-2026-23006, CVE-2026-23007, CVE-2026-23008, CVE-2026-23009, CVE-2026-23010, CVE-2026-23011, CVE-2026-23012, CVE-2026-23013, CVE-2026-23014, CVE-2026-23015, CVE-2026-23017, CVE-2026-23018, CVE-2026-23019, CVE-2026-23020, CVE-2026-23021, CVE-2026-23022, CVE-2026-23023, CVE-2026-23024, CVE-2026-23025, CVE-2026-23026, CVE-2026-23030, CVE-2026-23031, CVE-2026-23032, CVE-2026-23033, CVE-2026-23034, CVE-2026-23035, CVE-2026-23036, CVE-2026-23037, CVE-2026-23038, CVE-2026-23042, CVE-2026-23044, CVE-2026-23045, CVE-2026-23046, CVE-2026-23047, CVE-2026-23049, CVE-2026-23050, CVE-2026-23051, CVE-2026-23052, CVE-2026-23053, CVE-2026-23054, CVE-2026-23055, CVE-2026-23056, CVE-2026-23057, CVE-2026-23058, CVE-2026-23059, CVE-2026-23061, CVE-2026-23062, CVE-2026-23063, CVE-2026-23064, CVE-2026-23065, CVE-2026-23066, CVE-2026-23067, CVE-2026-23068, CVE-2026-23069, CVE-2026-23070, CVE-2026-23071, CVE-2026-23072, CVE-2026-23073, CVE-2026-23075, CVE-2026-23076, CVE-2026-23077, CVE-2026-23078, CVE-2026-23079, CVE-2026-23080, CVE-2026-23081, CVE-2026-23083, CVE-2026-23084, CVE-2026-23085, CVE-2026-23086, CVE-2026-23087, CVE-2026-23088, CVE-2026-23089, CVE-2026-23090, CVE-2026-23092, CVE-2026-23093, CVE-2026-23094, CVE-2026-23095, CVE-2026-23096, CVE-2026-23097, CVE-2026-23098, CVE-2026-23099, CVE-2026-23100, CVE-2026-23101, CVE-2026-23102, CVE-2026-23103, CVE-2026-23104, CVE-2026-23105, CVE-2026-23106, CVE-2026-23107, CVE-2026-23108, CVE-2026-23109, CVE-2026-23110, CVE-2026-23113, CVE-2026-23114, CVE-2026-23115, CVE-2026-23116, CVE-2026-23118, CVE-2026-23119, CVE-2026-23120, CVE-2026-23121, CVE-2026-23122, CVE-2026-23123, CVE-2026-23124, CVE-2026-23125, CVE-2026-23126, CVE-2026-23128, CVE-2026-23129, CVE-2026-23130, CVE-2026-23131, CVE-2026-23133, CVE-2026-23135, CVE-2026-23136, CVE-2026-23137, CVE-2026-23138, CVE-2026-23139, CVE-2026-23140, CVE-

In the Linux kernel, the following vulnerability has been resolved: i2c: imx: mark I2C adapter when hardware is powered down On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers. During system suspend/resume, there exists a time window between: - suspend_noirq and the system entering suspend - the system starting to resume and resume_noirq In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored. If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang. Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available.

In the Linux kernel, the following vulnerability has been resolved: spi: imx: reconfigure for PIO when DMA cannot be started When spi_imx_can_dma() selects DMA, the ECSPI is configured for DMA: spi_imx_setupxfer() sets CTRL.SMC and clears dynamic_burst, and spi_imx_dma_transfer() programs the dynamic-burst BURST_LENGTH and the SDMA watermarks. If the DMA descriptor cannot be prepared (dmaengine_prep_slave_single() returns NULL), the transfer is failed with SPI_TRANS_FAIL_NO_START and falls back to PIO. The dynamic-burst DMA path uses its own bounce buffers instead of the SPI core's mapping, so xfer->{tx,rx}_sg_mapped are not set and the core's DMA->PIO retry is skipped; the driver falls back to PIO internally. But none of the DMA-mode configuration is undone, so the PIO transfer runs with CTRL.SMC set, the wrong burst length and dynamic_burst cleared, and the transferred data is corrupted. This is easily hit on i.MX8MP boards that describe ECSPI DMA in the device tree but run SDMA on ROM firmware (no external sdma-imx7d.bin): every ECSPI DMA prepare fails. An Infineon SLB9670 TPM on ECSPI1 then returns shifted TPM2_GetCapability data, is flagged "field failure mode", /dev/tpmrm0 is never created. Set controller->fallback before re-running spi_imx_setupxfer() so the ECSPI is reconfigured exactly like a normal PIO transfer. With controller->fallback set, spi_imx_setupxfer() sees spi_imx_can_dma() return false, so it clears spi_imx->usedma and reprograms the controller (clears CTRL.SMC, restores dynamic_burst and the PIO burst length). No explicit spi_imx->usedma = false is needed: setupxfer() already updates it from the can_dma() result.

In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx: Fix i.MX8MP VC8000E power up sequence Per errata[1]: ERR050531: VPU_NOC power down handshake may hang during VC8000E/VPUMIX power up/down cycling. Description: VC8000E reset de-assertion edge and AXI clock may have a timing issue. Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is de-asserted by HW) Add a bool variable is_errata_err050531 in 'struct imx8m_blk_ctrl_domain_data' to represent whether the workaround is needed. If is_errata_err050531 is true, first clear the clk before powering up gpc, then enable the clk after powering up gpc. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MP_1P33A

In the Linux kernel, the following vulnerability has been resolved: i2c: imx-lpi2c: mark I2C adapter when hardware is powered down On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers. During system suspend/resume, there exists a time window between: - suspend_noirq and the system entering suspend - the system starting to resume and resume_noirq In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored. If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang. Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available.

It was discovered that some AMD processors did not properly clear data in the floating point divider unit during speculative execution. A local attacker could use this to expose sensitive information. (CVE-2025-54505) It was discovered that some AMD Zen 2 processors did not properly isolate shared resources in the operation cache. A local attacker could possibly use this issue to corrupt instructions executed at a higher privilege level, resulting in privilege escalation. (CVE-2025-54518) It was discovered that some AMD Zen 5 processors supporting RDSEED instruction did not properly handle entropy, potentially resulting in the consumption of insufficiently random values. A local attacker could possibly use this issue to influence the values returned by the RDSEED instruction causing loss of confidentiality and integrity. (CVE-2025-62626) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - MIPS architecture; - PowerPC architecture; - RISC-V architecture; - S390 architecture; - x86 architecture; - Block layer subsystem; - Cryptographic API; - Compute Acceleration Framework; - ACPI drivers; - Serial ATA and Parallel ATA drivers; - ATM drivers; - Drivers core; - Power management core; - DRBD Distributed Replicated Block Device drivers; - Rados block device (RBD) driver; - RNBD block device driver; - Ublk userspace block driver; - Compressed RAM block device driver; - Bluetooth drivers; - Bus devices; - Character device driver; - TPM device driver; - Clock framework and drivers; - Clocksource drivers; - Data acquisition framework and drivers; - Counter interface drivers; - CPU frequency scaling framework; - CPU idle management framework; - Hardware crypto device drivers; - CXL (Compute Express Link) drivers; - DMA engine subsystem; - EDAC drivers; - EFI core; - GPIO subsystem; - GPU drivers; - Greybus drivers; - HID subsystem; - Hardware monitoring drivers; - I2C subsystem; - IIO subsystem; - IIO ADC drivers; - InfiniBand drivers; - Input Device (Miscellaneous) drivers; - IOMMU subsystem; - IRQ chip drivers; - LED subsystem; - Mailbox framework; - Multiple devices driver; - Media drivers; - MediaTek SMI driver; - NVIDIA Tegra memory controller driver; - Multifunction device drivers; - Broadcom VK accelerator driver; - Fastrpc Driver; - IBM Advanced System Management driver; - MMC subsystem; - MOST (Media Oriented Systems Transport) drivers; - MTD block device drivers; - Network drivers; - Ethernet bonding driver; - Mellanox network drivers; - Microsoft Azure Network Adapter (MANA) driver; - STMicroelectronics network drivers; - Ethernet team driver; - MediaTek network drivers; - Near Field Communication (NFC) drivers; - NTB driver; - NVDIMM (Non-Volatile Memory Device) drivers; - NVME drivers; - Device tree and open firmware driver; - PCI subsystem; - Performance monitor drivers; - Pin controllers subsystem; - x86 platform drivers; - Broadcom BCM2835 power domain driver; - Generic PM domains; - i.MX PM domains; - Power supply drivers; - RapidIO drivers; - RAS (Reliability, Availability, Serviceability) subsystem; - Remote Processor subsystem; - RPMSG subsystem; - S/390 drivers; - SCSI subsystem; - SLIMbus drivers; - Freescale SoC drivers; - MediaTek SoC drivers; - Microchip PolarFire SoC system controller driver; - Texas Instruments SoC drivers; - SPI subsystem; - Greybus lights staging drivers; - Media staging drivers; - Realtek RTL8723BS SDIO drivers; - SM750 framebuffer staging driver; - TCM subsystem; - Thermal drivers; - TTY drivers; - UFS subsystem; - Cadence USB3 driver; - ChipIdea USB driver; - USB Device Class drivers; - ULPI bus; - USB core drivers; - DesignWare USB2 driver; - DesignWare USB3 driver; - USB Gadget drivers; - USB Host Controller drivers; - Mustek MDC800 USB digital camera driver; - USB YUREX driver; - Renesas USBHS Controller drivers; - USB Type-C Connector System Software Interface driver; - USB over IP driver; - vDPA drivers; - VFIO drivers; - Virtio Host (VHOST) subsystem; - Framebuffer layer; - TSM TDX Guest driver; - Xen hypervisor drivers; - File systems infrastructure; - BTRFS file system; - Ceph distributed file system; - EROFS file system; - Ext4 file system; - F2FS file system; - FAT file system; - FUSE (File system in Userspace); - GFS2 file system; - HFS+ file system; - Journaling layer for block devices (JBD2); - JFS file system; - Network file systems library; - Network file system (NFS) server daemon; - NILFS2 file system; - File system notification infrastructure; - NTFS3 file system; - OCFS2 file system; - Proc file system; - Pstore file system;

The Autel Maxi Charger Single firmware up to version 1.03.51 allows unrestricted access to the NXP i.MX6 recovery mode via exposed hardware recovery pins. This vulnerability enables an attacker with physical access to boot attacker-controlled code in memory, potentially modifying or extracting firmware and sensitive data. The issue is classified with a high severity score of 6.8 CVSS v3.1. No patch or remediation information is currently available.

Autel Maxi Charger Single firmware up to version 1.03.51 allows unrestricted physical access to the NXP i.MX6 recovery mode via exposed hardware recovery pins. This vulnerability enables an attacker with physical access to boot attacker-controlled code, potentially modifying or extracting firmware and sensitive data. The vulnerability is classified under CWE-1191 and CWE-1244 and has a high severity score of 8.6. No patch or official remediation has been confirmed as of the publication date.