Re: kern/49506: panic in bpf

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

Hi,

I think the below patch fixes the problem, but I cannot reproduce
the panic and confirm the patch is correct. Kamil, do you have
time to test it? or someone else?

Thanks,
  ozaki-r

diff --git a/sys/net/bpf.c b/sys/net/bpf.c
index f66e783..e4d4164 100644
--- a/sys/net/bpf.c
+++ b/sys/net/bpf.c
@@ -1388,7 +1388,7 @@ static inline void
 bpf_deliver(struct bpf_if *bp, void *(*cpfn)(void *, const void *, size_t),
     void *pkt, u_int pktlen, u_int buflen, const bool rcv)
 {
-       const bpf_ctx_t *bc = NULL;
+       const bpf_ctx_t *bc = bpf_default_ctx();
        uint32_t mem[BPF_MEMWORDS];
        bpf_args_t args = {
                .pkt = (const uint8_t *)pkt,

On Fri, Dec 26, 2014 at 1:35 PM,  <n54%gmx.com@localhost> wrote:
>>Number:         49506
>>Category:       kern
>>Synopsis:       panic in bpf
>>Confidential:   no
>>Severity:       critical
>>Priority:       high
>>Responsible:    kern-bug-people
>>State:          open
>>Class:          sw-bug
>>Submitter-Id:   net
>>Arrival-Date:   Fri Dec 26 04:35:00 +0000 2014
>>Originator:     Kamil Rytarowski
>>Release:        NetBSD-current
>>Organization:
>>Environment:
> NetBSD 6.99.47 (NO_DRM) #1: Sat Sep  6 00:20:24 CEST 2014
>         root@compaq:/usr/src/sys/arch/amd64/compile/NO_DRM
>>Description:
> I was able to trigger NULL pointer dereference (when I used a different network setup few months ago).
>
> I planned to debug it myself, but I had no time until now, as other things were more annoying so I give the bug report for free to a willing developer.
>
> DMESG
>
> axe0: link state UP (was UNKNOWN)
> uvm_fault(0xfffffe80bda53460, 0x0, 2) -> e
> fatal page fault in supervisor mode
> trap type 6 code 2 rip ffffffff80292fe7 cs 8 rflags 10246 cr2 0 ilevel 6 rsp fffffe800766fae0
> curlwp 0xfffffe8006f51120 pid 125.1 lowest kstack 0xfffffe800766c2c0
> panic: trap
> cpu0: Begin traceback...
> vpanic() at netbsd:vpanic+0x203
> vpanic() at netbsd:vpanic
> trap() at netbsd:trap+0x296
> --- trap (number 6) ---
> bpf_filter_ext() at netbsd:bpf_filter_ext+0x532
> bpf_deliver() at netbsd:bpf_deliver+0xef
> _bpf_mtap() at netbsd:_bpf_mtap+0xc5
> bpf_mtap() at ffffffff804c26b9
> axe_start() at netbsd:axe_start+0x1b4
> ifq_enqueue() at netbsd:ifq_enqueue+0x19b
> ether_output() at netbsd:ether_output+0xa06
> bpf_write() at netbsd:bpf_write+0x1c3
> dofilewrite() at netbsd:dofilewrite+0xa7
> sys_write() at netbsd:sys_write+0x88
> sy_call() at netbsd:sy_call+0x40
> sy_invoke() at netbsd:sy_invoke+0xba
> syscall() at netbsd:syscall+0xf5
> --- syscall (number 4) ---
> 7f7ff5a3be8a:
> cpu0: End traceback...
>
> dumping to dev 0,1 (offset=8, size=784207):
>
>
> The culprit reason for panic was passing NULL pointer as a parameter to this function.
>
> If I remember correctly it was "bc" and it was triggered in one of the following cases:
> case BPF_MISC|BPF_COP:
> #ifdef _KERNEL
> if (pc->k < bc->nfuncs) {
> const bpf_copfunc_t fn = bc->copfuncs[pc->k];
> A = fn(bc, args, A);
> continue;
> }
> #endif
> return 0;
> case BPF_MISC|BPF_COPX:
> #ifdef _KERNEL
> if (X < bc->nfuncs) {
> const bpf_copfunc_t fn = bc->copfuncs[X];
> A = fn(bc, args, A);
> continue;
> }
> #endif
>>How-To-Repeat:
> NIC: axe0
>
> preinstalled software: net/nmap
>
> JUST after (re)boot:
> # ifconfig axe0 192.168.1.1
> # nmap 192.168.1.0/24
>
> see crash, always reproducible
>>Fix:
> N/A
>