CVE-2026-46156

What it actually does

This is a Linux kernel availability flaw in the LoongArch-specific Loongson GPU PCI fixup path. During PCI device setup, loongson_gpu_fixup_dma_hang() can derive an invalid device value and fall through switch handling that expects only specific display controller cases. The kernel then performs readl(crtc_reg) against an unintended or random address, triggering an address error exception on LoongArch systems. The practical result is a kernel panic during device enumeration or boot when affected hardware topology is present, especially systems with Loongson GPU components and an inserted discrete GPU. The vulnerability is local and does not provide confidentiality or integrity impact; its primary effect is denial of service through system crash or failure to boot.

Why it matters to the business

Affected LoongArch Linux systems can become unavailable, fail during boot, or crash during PCI hardware discovery, causing service interruption and operational recovery work. The risk is most relevant to organizations running Loongson/LoongArch desktops, appliances, workstations, or servers with affected GPU/PCI configurations. Because exploitation requires local access or control over hardware/device configuration and there is no known public exploit or CISA KEV listing, broad internet-scale risk is low; however, systems using the impacted architecture may experience high operational impact if they cannot boot after hardware changes or kernel deployment.

How an attack unfolds

An attacker or operator with local ability to influence PCI hardware configuration, such as adding or exposing a discrete GPU or otherwise causing the vulnerable Loongson GPU PCI fixup path to process an unexpected device value, triggers PCI enumeration on an affected Linux kernel. During initialization, the kernel calls pci_scan_single_device(), pci_setup_device(), pci_fixup_device(), and then loongson_gpu_fixup_dma_hang(). Because the device value does not match the expected DC2 or DC3 cases, the function may use an invalid CRTC register address. The subsequent readl() dereference causes an LoongArch address error exception, leading to a kernel panic. In practice, this can crash the host or prevent it from completing boot. There is no indication from the provided data that this flaw enables code execution, privilege escalation, data theft, or remote exploitation.

How to fix it

Update the Linux kernel to a vendor-provided version that includes the LoongArch fix adding safe default handling in loongson_gpu_fixup_dma_hang(). Because no exact fixed package versions were provided, use the latest stable kernel or distribution security kernel for affected LoongArch/Loongson systems and confirm the vendor advisory explicitly references this fix or the corresponding upstream commit. Prioritize systems using Loongson GPUs, LoongArch platforms, and PCI/GPU configurations involving discrete GPUs. If an immediate kernel update is not possible, reduce exposure by avoiding unsupported GPU/PCI configurations that trigger the fixup path, do not add or hot-plug affected discrete GPUs, and validate kernel updates on representative LoongArch hardware before production rollout. Where availability is critical, maintain a known-good bootable kernel entry so affected systems can be recovered if a vulnerable kernel panics during boot.

How to confirm the fix worked

Confirm the running kernel has been updated to a build containing the LoongArch loongson_gpu_fixup_dma_hang() correction. Validate with distribution package metadata, kernel changelogs, or source inspection showing a default switch case or equivalent safe handling for unexpected device values in the affected function. On representative LoongArch/Loongson hardware, reboot and verify that PCI enumeration completes successfully with the relevant GPU/PCI configuration present. Review kernel logs after boot for absence of address error exceptions, kernel panic traces, or call traces referencing loongson_gpu_fixup_dma_hang(), pci_fixup_device(), or pci_setup_device(). If kernel live patching is used, verify that the live patch is active and persistent across reboot according to the platform’s patching mechanism.

Typical attack path

1. Obtain local access, administrative influence over hardware configuration, or another way to cause affected PCI devices to be enumerated on a vulnerable LoongArch Linux system.
2. Introduce or expose a PCI/GPU topology that causes the Loongson GPU fixup logic to encounter an unexpected device value, such as a Loongson GPU system with an additional discrete GPU.
3. Trigger PCI enumeration, commonly by booting the system, rescanning PCI devices, or otherwise causing the kernel to initialize the affected device path.
4. The vulnerable kernel enters loongson_gpu_fixup_dma_hang() during PCI fixup processing.
5. The function accesses an invalid register address with readl(), causing a LoongArch address error exception.
6. The kernel panics, causing denial of service, system crash, or boot failure.

How to detect it

To determine whether this issue has already occurred, review kernel logs, persistent journal entries, serial console logs, crash dumps, pstore records, and hardware management logs for LoongArch address error exceptions or kernel panics during PCI or ACPI device enumeration. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd-journald kernel logs, kdump/vmcore data, pstore/ramoops records under /sys/fs/pstore, boot console captures, and crash reporting systems. Focus on crashes during boot, immediately after kernel updates, after inserting or enabling discrete GPUs, or during PCI rescans. Look for call traces containing loongson_gpu_fixup_dma_hang(), pci_fixup_device(), pci_setup_device(), pci_scan_single_device(), pci_scan_slot(), acpi_pci_root_create(), or pci_acpi_scan_root(). Also look for LoongArch exception markers such as "Kernel ade access", "ESTAT", "ADEM", "BADV", and references to Loongson GPU or PCI device enumeration. These artifacts indicate the system likely experienced the denial-of-service condition; they do not, by themselves, prove malicious exploitation because the same crash can be triggered by normal hardware configuration.

• Kernel ade access[#1]
• Kernel ade access
• loongson_gpu_fixup_dma_hang
• loongson_gpu_fixup_dma_hang+0xb4/0x210
• loongson_gpu_fixup_dma_hang+0x40/0x210
• pci_fixup_device
• pci_setup_device
• pci_scan_single_device
• pci_scan_slot
• pci_scan_child_bus_extend
• acpi_pci_root_create
• pci_acpi_scan_root
• acpi_pci_root_add
• ESTAT: 00480000 [ADEM]
• ECode=8 EsubCode=1
• BADV: 7fffffffffffff00
• PRID: 0014d000
• Loongson-64bit, Loongson-3A6000-HV
• Loongson Technology LLC LG100 GPU
• Loongson Technology LLC Device 7a37
• Process swapper/0
• Call Trace:
• Kernel panic

What your security team should do

• Inventory LoongArch/Loongson Linux systems, especially those using Loongson GPUs or discrete GPU configurations.
• Prioritize kernel updates for affected LoongArch systems where availability matters or where hardware changes are frequent.
• Use only vendor-supported kernel packages or stable upstream kernels that include the Loongson GPU fixup correction.
• Before broad rollout, test the patched kernel on representative Loongson hardware with the same PCI/GPU topology used in production.
• Keep a previous known-good boot option available during remediation to recover from boot-time kernel panic scenarios.
• Monitor kernel logs and crash reports for address error exceptions and call traces involving loongson_gpu_fixup_dma_hang().
• Restrict physical and administrative ability to alter PCI/GPU hardware on sensitive LoongArch systems.
• Treat unexpected crashes during PCI enumeration or immediately after GPU hardware changes as potentially related until ruled out.