A SMAP-violating kernel access is not a recoverable condition. Imagine kernel code that, outside of a uaccess region, dereferences a pointer to the user range by accident. If SMAP is on, this will reliably generate as an intentional user access. This makes it easy for bugs to be overlooked if code is inadequately tested both with and without SMAP.
We discovered this because BPF can generate invalid accesses to user memory, but those warnings only got printed if SMAP was off. With this patch, this type of error will be discovered with SMAP on as well. Cc: Yonghong Song <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Daniel Borkmann <[email protected]> Signed-off-by: Andy Lutomirski <[email protected]> --- arch/x86/mm/fault.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 466415bdf58c..eed217d4a877 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1278,9 +1278,12 @@ void do_user_addr_fault(struct pt_regs *regs, */ if (unlikely(cpu_feature_enabled(X86_FEATURE_SMAP) && !(error_code & X86_PF_USER) && - !(regs->flags & X86_EFLAGS_AC))) - { - bad_area_nosemaphore(regs, error_code, address); + !(regs->flags & X86_EFLAGS_AC))) { + /* + * No extable entry here. This was a kernel access to an + * invalid pointer. get_kernel_nofault() will not get here. + */ + page_fault_oops(regs, error_code, address); return; } -- 2.29.2
