summaryrefslogtreecommitdiff
path: root/include/linux/errqueue.h
diff options
context:
space:
mode:
authorDave Jiang <dave.jiang@intel.com>2026-09-04 10:23:35 -0700
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2026-09-04 20:22:06 +0200
commit10338c9085b4939a428a8dc78d2bbf62c161278b (patch)
tree6eea7945f769640a9bad71e6704f5068cbe7998a /include/linux/errqueue.h
parent92480a2b00a15b0add512b6fc474151ec5340a8e (diff)
ACPI: APEI: GHES: Validate memory error section length before payload access
ghes_do_proc() hands the CPER_SEC_PLATFORM_MEM payload to the report chain, arch_apei_report_mem_error() and ghes_handle_memory_failure() without checking gdata->error_data_length. All three read validation_bits and physical_addr, at offsets 0 and 16, so a shorter section reads past the record. Check the length once in ghes_do_proc(), before any consumer runs. Take the 73-byte struct cper_sec_mem_err_old as the floor: older firmware legitimately emits that UEFI 2.1/2.2 layout, and it makes validation_bits safe to read. The fields from "extended" on are absent from that layout, so also require whatever length the validation bits claim. Derive it per field rather than demanding the full 80 bytes: rank needs only 76, and the BANK_GROUP and BANK_ADDRESS bits describe "bank" at offset 38, which every record carries. Testing the whole mask against one size, as cper_print_mem() does, gets it wrong both ways. Reported-by: sashiko-bot@kernel.org Closes: https://sashiko.dev/#/patchset/20260714231835.303081-1-dave.jiang@intel.com?part=7 Fixes: ca104edc1784 ("ACPI, APEI, GHES: Cleanup ghes memory error handling") Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260904172337.1409775-12-dave.jiang@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'include/linux/errqueue.h')
0 files changed, 0 insertions, 0 deletions