From: Hou Tao <houtao1@huawei.com>
When trying to use copy_from_kernel_nofault() to read vsyscall page
through a bpf program, the following oops was reported:
BUG: unable to handle page fault for address: ffffffffff600000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
RIP: 0010:copy_from_kernel_nofault+0x6f/0x110
......
Call Trace:
<TASK>
? copy_from_kernel_nofault+0x6f/0x110
bpf_probe_read_kernel+0x1d/0x50
bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d
trace_call_bpf+0xc5/0x1c0
perf_call_bpf_enter.isra.0+0x69/0xb0
perf_syscall_enter+0x13e/0x200
syscall_trace_enter+0x188/0x1c0
do_syscall_64+0xb5/0xe0
entry_SYSCALL_64_after_hwframe+0x6e/0x76
</TASK>
......
---[ end trace 0000000000000000 ]---
The oops is triggered when:
1) A bpf program uses bpf_probe_read_kernel() to read from the vsyscall
page and invokes copy_from_kernel_nofault() which in turn calls
__get_user_asm().
2) Because the vsyscall page address is not readable from kernel space,
a page fault exception is triggered accordingly.
3) handle_page_fault() considers the vsyscall page address as a user
space address instead of a kernel space address. This results in the
fix-up setup by bpf not being applied and a page_fault_oops() is invoked
due to SMAP.
Considering handle_page_fault() has already considered the vsyscall page
address as a userspace address, fix the problem by disallowing vsyscall
page read for copy_from_kernel_nofault().
Originally-by: Thomas Gleixner <tglx@linutronix.de>
Reported-by: syzbot+72aa0161922eba61b50e@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/bpf/CAG48ez06TZft=ATH1qh2c5mpS5BT8UakwNkzi6nvK5_djC-4Nw@mail.gmail.com
Reported-by: xingwei lee <xrivendell7@gmail.com>
Closes: https://lore.kernel.org/bpf/CABOYnLynjBoFZOf3Z4BhaZkc5hx_kHfsjiW+UWLoB=w33LvScw@mail.gmail.com
Signed-off-by: Hou Tao <houtao1@huawei.com>
---
arch/x86/mm/maccess.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/mm/maccess.c b/arch/x86/mm/maccess.c
index 6993f026adec9..42115ac079cfe 100644
--- a/arch/x86/mm/maccess.c
+++ b/arch/x86/mm/maccess.c
@@ -3,6 +3,8 @@
#include <linux/uaccess.h>
#include <linux/kernel.h>
+#include <asm/vsyscall.h>
+
#ifdef CONFIG_X86_64
bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
{
@@ -15,6 +17,14 @@ bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
if (vaddr < TASK_SIZE_MAX + PAGE_SIZE)
return false;
+ /*
+ * Reading from the vsyscall page may cause an unhandled fault in
+ * certain cases. Though it is at an address above TASK_SIZE_MAX, it is
+ * usually considered as a user space address.
+ */
+ if (is_vsyscall_vaddr(vaddr))
+ return false;
+
/*
* Allow everything during early boot before 'x86_virt_bits'
* is initialized. Needed for instruction decoding in early
--
2.29.2
On Fri, Feb 02 2024 at 18:39, Hou Tao wrote: > > Originally-by: Thomas Gleixner <tglx@linutronix.de> > Reported-by: syzbot+72aa0161922eba61b50e@syzkaller.appspotmail.com > Closes: https://lore.kernel.org/bpf/CAG48ez06TZft=ATH1qh2c5mpS5BT8UakwNkzi6nvK5_djC-4Nw@mail.gmail.com > Reported-by: xingwei lee <xrivendell7@gmail.com> > Closes: https://lore.kernel.org/bpf/CABOYnLynjBoFZOf3Z4BhaZkc5hx_kHfsjiW+UWLoB=w33LvScw@mail.gmail.com > Signed-off-by: Hou Tao <houtao1@huawei.com> Acked-by: Thomas Gleixner <tglx@linutronix.de>
On 2/2/2024 2:39 AM, Hou Tao wrote: > From: Hou Tao <houtao1@huawei.com> > > When trying to use copy_from_kernel_nofault() to read vsyscall page > through a bpf program, the following oops was reported: > > BUG: unable to handle page fault for address: ffffffffff600000 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0 > Oops: 0000 [#1] PREEMPT SMP PTI > CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... > RIP: 0010:copy_from_kernel_nofault+0x6f/0x110 > ...... > Call Trace: > <TASK> > ? copy_from_kernel_nofault+0x6f/0x110 > bpf_probe_read_kernel+0x1d/0x50 > bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d > trace_call_bpf+0xc5/0x1c0 > perf_call_bpf_enter.isra.0+0x69/0xb0 > perf_syscall_enter+0x13e/0x200 > syscall_trace_enter+0x188/0x1c0 > do_syscall_64+0xb5/0xe0 > entry_SYSCALL_64_after_hwframe+0x6e/0x76 > </TASK> > ...... > ---[ end trace 0000000000000000 ]--- > > The oops is triggered when: > > 1) A bpf program uses bpf_probe_read_kernel() to read from the vsyscall > page and invokes copy_from_kernel_nofault() which in turn calls > __get_user_asm(). > > 2) Because the vsyscall page address is not readable from kernel space, > a page fault exception is triggered accordingly. > > 3) handle_page_fault() considers the vsyscall page address as a user > space address instead of a kernel space address. This results in the > fix-up setup by bpf not being applied and a page_fault_oops() is invoked > due to SMAP. > > Considering handle_page_fault() has already considered the vsyscall page > address as a userspace address, fix the problem by disallowing vsyscall > page read for copy_from_kernel_nofault(). > > Originally-by: Thomas Gleixner <tglx@linutronix.de> > Reported-by: syzbot+72aa0161922eba61b50e@syzkaller.appspotmail.com > Closes: https://lore.kernel.org/bpf/CAG48ez06TZft=ATH1qh2c5mpS5BT8UakwNkzi6nvK5_djC-4Nw@mail.gmail.com > Reported-by: xingwei lee <xrivendell7@gmail.com> > Closes: https://lore.kernel.org/bpf/CABOYnLynjBoFZOf3Z4BhaZkc5hx_kHfsjiW+UWLoB=w33LvScw@mail.gmail.com > Signed-off-by: Hou Tao <houtao1@huawei.com> > --- > arch/x86/mm/maccess.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > Reviewed-by: Sohil Mehta <sohil.mehta@intel.com>
On Fri, Feb 2, 2024 at 11:03 AM Sohil Mehta <sohil.mehta@intel.com> wrote: > > On 2/2/2024 2:39 AM, Hou Tao wrote: > > From: Hou Tao <houtao1@huawei.com> > > > > When trying to use copy_from_kernel_nofault() to read vsyscall page > > through a bpf program, the following oops was reported: > > > > BUG: unable to handle page fault for address: ffffffffff600000 > > #PF: supervisor read access in kernel mode > > #PF: error_code(0x0000) - not-present page > > PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0 > > Oops: 0000 [#1] PREEMPT SMP PTI > > CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58 > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... > > RIP: 0010:copy_from_kernel_nofault+0x6f/0x110 > > ...... > > Call Trace: > > <TASK> > > ? copy_from_kernel_nofault+0x6f/0x110 > > bpf_probe_read_kernel+0x1d/0x50 > > bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d > > trace_call_bpf+0xc5/0x1c0 > > perf_call_bpf_enter.isra.0+0x69/0xb0 > > perf_syscall_enter+0x13e/0x200 > > syscall_trace_enter+0x188/0x1c0 > > do_syscall_64+0xb5/0xe0 > > entry_SYSCALL_64_after_hwframe+0x6e/0x76 > > </TASK> > > ...... > > ---[ end trace 0000000000000000 ]--- > > > > The oops is triggered when: > > > > 1) A bpf program uses bpf_probe_read_kernel() to read from the vsyscall > > page and invokes copy_from_kernel_nofault() which in turn calls > > __get_user_asm(). > > > > 2) Because the vsyscall page address is not readable from kernel space, > > a page fault exception is triggered accordingly. > > > > 3) handle_page_fault() considers the vsyscall page address as a user > > space address instead of a kernel space address. This results in the > > fix-up setup by bpf not being applied and a page_fault_oops() is invoked > > due to SMAP. > > > > Considering handle_page_fault() has already considered the vsyscall page > > address as a userspace address, fix the problem by disallowing vsyscall > > page read for copy_from_kernel_nofault(). > > > > Originally-by: Thomas Gleixner <tglx@linutronix.de> Thomas, could you please Ack the patch if you're still ok with it, so we can take through the bpf tree to Linus soon ? Not only syzbot, but real users are hitting this bug. Thanks! > > Reported-by: syzbot+72aa0161922eba61b50e@syzkaller.appspotmail.com > > Closes: https://lore.kernel.org/bpf/CAG48ez06TZft=ATH1qh2c5mpS5BT8UakwNkzi6nvK5_djC-4Nw@mail.gmail.com > > Reported-by: xingwei lee <xrivendell7@gmail.com> > > Closes: https://lore.kernel.org/bpf/CABOYnLynjBoFZOf3Z4BhaZkc5hx_kHfsjiW+UWLoB=w33LvScw@mail.gmail.com > > Signed-off-by: Hou Tao <houtao1@huawei.com> > > --- > > arch/x86/mm/maccess.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> >
© 2016 - 2025 Red Hat, Inc.