CVE-2022-50849: 
Linux Kernel vulnerability analysis and mitigation

CVE-2022-50849 is a Linux kernel vulnerability in the pstore subsystem's RAM backend that can cause a kernel oops (panic) when reading /proc/kcore on affected devices. The flaw affects Linux kernel versions using pstore with the RAM (ramoops) backend, and was publicly disclosed on December 30, 2025. It carries a CVSS v3.1 base score of 7.0 (High), requiring local access with low privileges and high attack complexity (Red Hat Advisory, Red Hat Bugzilla).

The root cause is an improper memory mapping in the pstore RAM backend (CWE-119/memory safety). During early boot, memblock reserves pages for the ramoops memory region, and pstore's RAM backend remaps these pages via vmap() with specific memory type flags (writeback or non-cached). When read_kcore() iterates over the vmalloc region and encounters the ramoops virtual address, it calls vmalloc_to_page() to retrieve the underlying page struct, then passes it to kmap_atomic(). The kmap_atomic() function incorrectly assumes the lowmem page is directly accessible via __va(), but since the lowmem mapping was never established for these reserved pages, a level-2 translation fault occurs, triggering a kernel oops. The fix involves passing the VM_IOREMAP flag to vmap(), which causes vread() to exclude the ramoops region from kcore operations entirely (Red Hat Bugzilla).

Successful exploitation causes a kernel oops (system crash), resulting in a denial of service on affected systems. The crash is triggered by a simple read of /proc/kcore, which any low-privileged local user can perform. While the primary impact is availability (system crash), the corrupted memory access patterns observed in the kernel panic trace may also present secondary risks of information disclosure from kernel memory (Red Hat Advisory, Red Hat Bugzilla).

1. Identify a vulnerable system: Confirm the target Linux system uses pstore with the RAM (ramoops) backend, which is common on embedded or Chromebook-style devices (e.g., Google Lazor).
2. Obtain local access: Authenticate to the system with any low-privileged user account.
3. Trigger the kernel oops: Execute the command cat /proc/kcore > /dev/null from the local shell. This causes read_kcore() to iterate over the vmalloc region, encounter the ramoops virtual address, and attempt to access reserved lowmem pages via kmap_atomic(), triggering a level-2 translation fault and kernel panic (Red Hat Bugzilla).

• Logs: Kernel logs (dmesg or /var/log/kern.log) showing Internal error: Oops: 96000006 with a call trace including __memcpy, vread, and read_kcore; messages referencing Unable to handle kernel paging request at virtual address in the ramoops address range.
• Process: Processes such as cat, perf, or other tools reading /proc/kcore immediately prior to a system crash or reboot.
• System: Unexpected system reboots or kernel panics on devices using pstore with RAM backend, particularly following access to /proc/kcore (Red Hat Bugzilla).

Apply the upstream Linux kernel patch that passes the VM_IOREMAP flag to vmap() in the pstore RAM backend; multiple stable kernel commits address this issue (e.g., commits 2f82381d, 4d3126f2, 6d946021, 69dbff7d in the stable kernel tree). As a temporary workaround, restrict read access to /proc/kcore using file permissions (e.g., chmod 400 /proc/kcore or via kernel hardening settings) to prevent low-privileged users from triggering the fault. Systems using pstore with non-RAM backends are not affected and do not require remediation (Red Hat Bugzilla, Red Hat Advisory).