lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAADnVQ+0q3gNWxVFAwAnaXJyn+=47WDrNuw_=ABUERAA1yaJrw@mail.gmail.com> Date: Tue, 22 Jan 2019 23:48:37 -0800 From: Alexei Starovoitov <alexei.starovoitov@...il.com> To: Quentin Monnet <quentin.monnet@...ronome.com> Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Network Development <netdev@...r.kernel.org> Subject: Re: [PATCH bpf-next v5 0/9] tools: bpftool: add probes for system and device On Tue, Jan 22, 2019 at 10:39 PM Alexei Starovoitov <alexei.starovoitov@...il.com> wrote: > > On Thu, Jan 17, 2019 at 7:28 AM Quentin Monnet > <quentin.monnet@...ronome.com> wrote: > > > > > > If the user does not have root privileges (or more precisely, the > > CAP_SYS_ADMIN capability) detection will be erroneous for most > > parameters. Therefore, forbid non-root users to run the command. > > > > v5: > > - Move exported symbols to a new LIBBPF_0.0.2 section in libbpf.map > > (patches 4 to 6). > > - Minor fixes on patches 3 and 4. > > I was about to apply the set, > but while testing on older kernels bpftool crashed the box. > It's a kernel bug, no doubt, but bpftool shouldn't be doing > dangerous operations if it can potentially crash it. > I'm debugging what went wrong. > It crashed after this message: > CONFIG_XFRM is set to y > dmesg was: > [1757577.380114] BUG: unable to handle kernel > [1757577.388476] NULL pointer dereference > [1757577.395957] at (null) > [1757577.402752] IP: (null) > [1757577.421265] Call Trace: > [1757577.421269] ? SyS_bpf+0x18b/0x16b0 > [1757577.421272] ? __audit_syscall_entry+0xb5/0x100 > [1757577.421277] do_syscall_64+0x53/0x150 > Not sure how that was possible. > I'm still debugging. Changed my mind and applied to bpf-next. Turned out that one of the map types was defined in ops, but body was not backported due to large dependencies not suitable for backport. That caused map_create syscall to crash. Will send a separate fix to improve backport resilience.
Powered by blists - more mailing lists