[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 5 Nov 2023 23:43:40 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Hsin-Wei Hung <hsinweih@....edu>, Alexei Starovoitov <ast@...nel.org>
Subject: Linux: BPF: issues with copy_from_user_nofault()
Hi,
Looks like the below wasn't brought to oss-security yet.
As I understand from what was posted to the linux-distros thread, the
issue was being fixed in:
https://lore.kernel.org/bpf/20230118051443.78988-1-alexei.starovoitov@gmail.com/
and actually fixed in:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d319f344561d
and it should have been merged to stable "tomorrow or so" after June 27,
at which point Hsin-Wei Hung was supposed to finally make the
oss-security posting, but apparently that never happened.
Of course, the delay from January 2 to June 28 was way in excess of the
supposed maximum, and it is even more ridiculous we didn't post in here
for even longer.
This is what happens when no one in particular keeps tracking issues
after they fall out of the attention span. This is also why we need to
take care of the distros list statistics task in real time, not only
retroactively like I'm doing for 2023 now.
Alexander
----- Forwarded message from Hsin-Wei Hung <hsinweih@....edu> -----
From: Hsin-Wei Hung <hsinweih@....edu>
To: linux-distros
Subject: [vs-plain] Warning in bpf_probe_read_user
Date: Mon, 2 Jan 2023 11:32:41 -0600
Hi,
We are testing the bpf runtime by running a modified syzkaller on Linux
kernel v5.15 (8993e6067f26 at linux-stable). The fuzzer triggered a warning
in the bpf_probe_read helper. I've attach the BPF PoC and the warning
message.
My understanding is that bpf_probe_read_user() checks user space memory
access by calling access_ok(), which will raise a warning if not being
called in user context. This can happen as the context depends on the hook
and not all of them are in user context. It seems to me that it does not
cause real problems on Linux kernel v5.15 because the use of
current->thread.addr_limit has been removed from access_ok() in v5.9 in
commit 47058bb54b57: (x86: remove address space overrides using set_fs()).
However, I think it might impact the version between v5.5 (since the
introduction of this helper) and v5.9.
BPF PoC:
#include "/usr/local/include/vmlinux.h"
#include "/usr/include/bpf/bpf_helpers.h"
#define SEC(name) \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wignored-attributes\"") \
__attribute__((section(name), used)) \
_Pragma("GCC diagnostic pop")
SEC("perf_event")
int func(struct bpf_perf_event_data *ctx) {
uint64_t v5 = 0;
char v0[56] = {};
uint64_t v6 = bpf_get_current_task();
if (v5 < 56) {
bpf_probe_read_user(v0, v5, v6);
}
return 3748508958;
}
char _license[] SEC("license") = "GPL";
==================================================================
perf event the bpf program attached to:
struct perf_event_attr attr_type_hw = {
.type = PERF_TYPE_HARDWARE,
.config = PERF_COUNT_HW_CPU_CYCLES,
.sample_freq = 50,
.inherit = 1,
.freq = 1,
};
int pfd = perf_event_open(&attr_type_hw, 0, -1, -1, 0);
==================================================================
WARNING: CPU: 3 PID: 14286 at mm/maccess.c:226
copy_from_user_nofault+0x8a/0x1d0
Modules linked in:
CPU: 3 PID: 14286 Comm: syz-executor.7 Not tainted 5.15.26+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:copy_from_user_nofault+0x8a/0x1d0
Code: b6 04 02 84 c0 74 08 3c 03 0f 8e 43 01 00 00 45 8b ad c0 1d 00 00 31
ff 44 89 ee e8 f0 c2 d8 ff 45 85 ed 75 07 e8 16 c7 d8 ff <0f> 0b e8 0f c7
d8 ff 49 89 dd 45 31 f6 48 89 df 4d 01 e5 41 0f 92
RSP: 0018:fffffe00000e6918 EFLAGS: 00010046
RAX: 0000000080110003 RBX: 0000000000000000 RCX: ffffffff9e96457a
RDX: ffff888008e88000 RSI: 0000000000000000 RDI: 0000000000000005
RBP: fffffe00000e6990 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: fffffe00000e6a28
R13: 0000000000000000 R14: 0000000000000000 R15: ffff888008e88000
FS: 00007f3f235c8700(0000) GS:ffff88805b580000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000560e900ad690 CR3: 000000003cfd6006 CR4: 0000000000370ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<NMI>
bpf_probe_read_user+0x25/0x70
bpf_prog_7989dee7b4c4fe7f_func+0x18e/0xf64
bpf_overflow_handler+0x17b/0x460
? perf_output_read+0x12b0/0x12b0
? kvm_sched_clock_read+0x14/0x30
? __perf_event_account_interrupt+0xe9/0x3a0
__perf_event_overflow+0x13f/0x3c0
handle_pmi_common+0x59b/0x980
? intel_pmu_save_and_restart+0x100/0x100
? intel_bts_interrupt+0x10d/0x3d0
intel_pmu_handle_irq+0x28a/0x8b0
perf_event_nmi_handler+0x4d/0x70
nmi_handle+0x147/0x390
default_do_nmi+0x40/0x100
exc_nmi+0x152/0x170
end_repeat_nmi+0x16/0x55
RIP: 0010:vprintk_emit+0x468/0x5e0
Code: 31 f6 48 c7 c7 60 22 14 a2 e8 b4 af fd ff 0f b6 1d 7d b4 96 05 31 ff
89 de e8 74 c7 19 00 5a 84 db 74 1b e8 da cb 19 00 f3 90 <0f> b6 1d 61 b4
96 05 31 ff 89 de e8 58 c7 19 00 84 db 75 e5 e8 bf
RSP: 0018:ffff888017c37b98 EFLAGS: 00000093
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff9e5540b6
RDX: ffff888008e88000 RSI: 0000000000000000 RDI: 0000000000000001
RBP: ffff888017c37be8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000017
R13: ffff888009ce0000 R14: 0000000000000000 R15: 0000000000000200
? vprintk_emit+0x466/0x5e0
? vprintk_emit+0x468/0x5e0
? vprintk_emit+0x468/0x5e0
</NMI>
<TASK>
vprintk+0x85/0xa0
_printk+0xbf/0xf2
? record_print_text.cold+0x16/0x16
? lock_is_held_type+0xe2/0x110
__sys_bpf.cold+0x56/0xbf8
? bpf_link_get_from_fd+0x120/0x120
? new_sync_read+0x6f0/0x6f0
? finish_task_switch.isra.0+0x20b/0x950
? security_file_permission+0xb6/0xe0
? ksys_write+0x1aa/0x260
? lock_is_held_type+0x53/0x110
__x64_sys_bpf+0x7a/0xc0
? syscall_enter_from_user_mode+0x21/0x70
do_syscall_64+0x3b/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f3f244ad12d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f3f235c75e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00007f3f235c76f0 RCX: 00007f3f244ad12d
RDX: 0000000000000048 RSI: 00007f3f235c75f0 RDI: 0000000000000000
RBP: 0000000000000004 R08: 00007f3f235c76f0 R09: 000000040000001d
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000018
R13: 0000000000000000 R14: 000000000000001d R15: 00007f3f1c00cc30
</TASK>
irq event stamp: 18024
hardirqs last enabled at (18023): [<ffffffff9e551264>]
__down_trylock_console_sem+0xd4/0xe0
hardirqs last disabled at (18024): [<ffffffff9e554145>]
vprintk_emit+0x4f5/0x5e0
softirqs last enabled at (18000): [<ffffffff9e3cc4a3>]
__irq_exit_rcu+0x183/0x1e0
softirqs last disabled at (17991): [<ffffffff9e3cc4a3>]
__irq_exit_rcu+0x183/0x1e0
Thanks,
Hsin-Wei
--
Computer Science Department
University of California, Irvine
----- End forwarded message -----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
