{ "schema_version": "1.6.1", "id": "RPI-CVE-2023-53331", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2023-53331" ], "published": "2025-09-16T16:13:45Z", "summary": "pstore/ram: Check start of empty przs during init", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npstore/ram: Check start of empty przs during init\n\nAfter commit 30696378f68a (\"pstore/ram: Do not treat empty buffers as\nvalid\"), initialization would assume a prz was valid after seeing that\nthe buffer_size is zero (regardless of the buffer start position). This\nunchecked start value means it could be outside the bounds of the buffer,\nleading to future access panics when written to:\n\n sysdump_panic_event+0x3b4/0x5b8\n atomic_notifier_call_chain+0x54/0x90\n panic+0x1c8/0x42c\n die+0x29c/0x2a8\n die_kernel_fault+0x68/0x78\n __do_kernel_fault+0x1c4/0x1e0\n do_bad_area+0x40/0x100\n do_translation_fault+0x68/0x80\n do_mem_abort+0x68/0xf8\n el1_da+0x1c/0xc0\n __raw_writeb+0x38/0x174\n __memcpy_toio+0x40/0xac\n persistent_ram_update+0x44/0x12c\n persistent_ram_write+0x1a8/0x1b8\n ramoops_pstore_write+0x198/0x1e8\n pstore_console_write+0x94/0xe0\n ...\n\nTo avoid this, also check if the prz start is 0 during the initialization\nphase. If not, the next prz sanity check case will discover it (start >\nsize) and zap the buffer back to a sane state.\n\n[kees: update commit log with backtrace and clarifications]", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.21-1+rpt1", "1:6.1.47-1+rpt2", "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi1-rpi-v6", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v8", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v6", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7l", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v8", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.21-1+rpt1": { "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed", "upstream_version": "6.1.21", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.53" }, "1:6.1.47-1+rpt2": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.53" }, "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.53", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2023-53331" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/89312657337e6e03ad6e9ea1a462bd9c158c85c8" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c807ccdd812d18985860504b503899f3140a9549" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e972231db29b5d1dccc13bf9d5ba55b6979a69ed" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/dc2f60de9a7d3efd982440117dab5579898d808c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/fedecaeef88899d940b69368c996e8b3b0b8650d" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e95d7a8a6edd14f8fab44c777dd7281db91f6ae2" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/f77990358628b01bdc03752126ff5f716ea37615" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/25fb4e3402d46f425ec135ef6f09792a4c1b3003" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/fe8c3623ab06603eb760444a032d426542212021" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:24:39Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The vulnerable path is confined to local pstore/ramoops initialization and subsequent local writes (pstore console, `/dev/pmsg0` via `persistent_ram_write_user`, or other ramoops backends); there is no network or adjacent-radio entry point into `fs/pstore/ram_core.c`.\nAC:L - Once an empty-but-invalid prz header (valid sig, size 0, non-zero start) is present in persistent RAM\u2014observed in the field and retained across soft reboot on common Android/embedded ramoops deployments\u2014the next write deterministically performs an out-of-bounds update with no race or ASLR dependency; scored Low under the uncertainty/highest-severity rule.\nPR:L - In the highest-impact realistic deployment (Android/ChromeOS-style ramoops with pmsg enabled), an unprivileged local actor can trigger the write through `/dev/pmsg0` (kernel default 0220, often further relaxed on Android) or rely on automatic pstore console writes after boot, without needing real init-namespace root.\nUI:N - No victim action is required: after a vulnerable boot accept of the bad empty buffer, the kernel itself writes via the pstore console on printk/panic, or the attacker writes `/dev/pmsg0` directly.\nS:U - The out-of-bounds write corrupts addresses within the kernel\u2019s own ramoops mapping/security domain and does not cross a VM, IOMMU, or other separate authority boundary.\nC:H - This is an out-of-bounds write through `persistent_ram_update`/`_user` into memory past the logical buffer; per kernel scoring guidance such memory corruption is treated as enabling high confidentiality impact (information disclosure primitives), matching CWE-787 assessment of this CVE.\nI:H - The bug issues a attacker-influenced (pmsg) or kernel-sourced (console) out-of-bounds store via `memcpy_toio`/`copy_from_user` at a corrupted start offset, which is integrity-high memory corruption that can overwrite adjacent mapped persistent-RAM contents and is scored as exploitable for control-flow impact under the OOB-write rule.\nA:H - The demonstrated consequence is a kernel translation fault/oops during the out-of-bounds write (see the fix backtrace through `persistent_ram_write` \u2192 `__memcpy_toio`), which is a full availability loss." } } }