diff options
| author | Xie Yuanbin <xieyuanbin1@huawei.com> | 2026-07-28 03:16:42 +0100 |
|---|---|---|
| committer | Russell King <rmk+kernel@armlinux.org.uk> | 2026-08-05 16:15:51 +0100 |
| commit | 1039bffd6ae9c75b42b7d148d6c1106134107b66 (patch) | |
| tree | e8ee4ac80f87e2ad1b6b0c877eccbb62b0915c02 /Documentation/ABI/testing/sysfs-mce | |
| download | linux-stable-1039bffd6ae9c75b42b7d148d6c1106134107b66.tar.gz linux-stable-1039bffd6ae9c75b42b7d148d6c1106134107b66.zip | |
ARM: 9485/1: mm: acquire mmap write lock around show_pte() for user faultsgrafted
When CONFIG_DEBUG_USER=y, and cmdline "user_debug=31" is set,
a user fault may trigger show_pte() without any lock.
If another thread in the same process concurrently calls munmap(),
the page table pages may be freed while show_pte() is still traversing
them, causing a use-after-free in show_pte().
If CONFIG_ARM_LPAE=y, this may cause a kernel panic if the pages table
of PMD are freed when show_pte() is running.
Acquire mmap_write_lock() around show_pte() for user faults to fix the
contention.
For user faults, additionally restrict that show_pte() is called only
when the addr is a user-space address (addr < TASK_SIZE). This is because
the lock of tsk->mm only protects the virtual memory of user address space,
furthermore, dumping the page tables of a kernel-space address for user
faults is unnecessary and may have security implications.
Keep everything unchanged for kernel faults, because the kernel is
already in the "oops" state, acquiring a lock may risk a deadlock.
Co-developed-by: Qi Xi <xiqi2@huawei.com>
Fixes: 6d021b724481 ("ARM: dump pgd, pmd and pte states on unhandled data abort faults")
Link: https://lore.kernel.org/20260716014022.2823-1-xieyuanbin1@huawei.com
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Qi Xi <xiqi2@huawei.com>
Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Diffstat (limited to 'Documentation/ABI/testing/sysfs-mce')
| -rw-r--r-- | Documentation/ABI/testing/sysfs-mce | 97 |
1 files changed, 97 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/sysfs-mce b/Documentation/ABI/testing/sysfs-mce new file mode 100644 index 000000000..83172f50e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-mce @@ -0,0 +1,97 @@ +What: /sys/devices/system/machinecheck/machinecheckX/ +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + (X = CPU number) + + Machine checks report internal hardware error conditions + detected by the CPU. Uncorrected errors typically cause a + machine check (often with panic), corrected ones cause a + machine check log entry. + + For more details about the x86 machine check architecture + see the Intel and AMD architecture manuals from their + developer websites. + + For more details about the architecture + see http://one.firstfloor.org/~andi/mce.pdf + + Each CPU has its own directory. + +What: /sys/devices/system/machinecheck/machinecheckX/bank<Y> +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + (Y bank number) + + 64bit Hex bitmask enabling/disabling specific subevents for + bank Y. + + When a bit in the bitmask is zero then the respective + subevent will not be reported. + + By default all events are enabled. + + Note that BIOS maintain another mask to disable specific events + per bank. This is not visible here + +What: /sys/devices/system/machinecheck/machinecheckX/check_interval +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + The entries appear for each CPU, but they are truly shared + between all CPUs. + + How often to poll for corrected machine check errors, in + seconds (Note output is hexadecimal). Default 5 minutes. + When the poller finds MCEs it triggers an exponential speedup + (poll more often) on the polling interval. When the poller + stops finding MCEs, it triggers an exponential backoff + (poll less often) on the polling interval. The check_interval + variable is both the initial and maximum polling interval. + 0 means no polling for corrected machine check errors + (but some corrected errors might be still reported + in other ways) + +What: /sys/devices/system/machinecheck/machinecheckX/trigger +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + The entries appear for each CPU, but they are truly shared + between all CPUs. + + Program to run when a machine check event is detected. + This is an alternative to running mcelog regularly from cron + and allows to detect events faster. + +What: /sys/devices/system/machinecheck/machinecheckX/monarch_timeout +Contact: Andi Kleen <ak@linux.intel.com> +Date: Feb, 2007 +Description: + How long to wait for the other CPUs to machine check too on a + exception. 0 to disable waiting for other CPUs. + + Unit: us + +What: /sys/devices/system/machinecheck/machinecheckX/ignore_ce +Contact: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> +Date: Jun 2009 +Description: + Disables polling and CMCI for corrected errors. + All corrected events are not cleared and kept in bank MSRs. + +What: /sys/devices/system/machinecheck/machinecheckX/dont_log_ce +Contact: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> +Date: Jun 2009 +Description: + Disables logging for corrected errors. + All reported corrected errors will be cleared silently. + + This option will be useful if you never care about corrected + errors. + +What: /sys/devices/system/machinecheck/machinecheckX/cmci_disabled +Contact: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> +Date: Jun 2009 +Description: + Disables the CMCI feature. |
