Re: kern/49506: panic in bpf

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

The following reply was made to PR kern/49506; it has been noted by GNATS.

From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
To: Alexander Nasonov <alnsn%yandex.ru@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
	netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/49506: panic in bpf
Date: Mon, 29 Dec 2014 20:07:41 +0900

 On Fri, Dec 26, 2014 at 7:43 PM, Alexander Nasonov <alnsn%yandex.ru@localhost> wrote:
 > n54%gmx.com@localhost wrote:
 >> 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
 >
 > I wonder which filter program triggered it and whether it bypassed a
 > validation step somehow. When bc is NULL, filter programs with COP/COPX
 > shouldn't pass bpf_validate_ext().
 
 Oh, I got it. The variable bc in bpf_deliver confused me.
 I thought it is unexpectedly set to NULL.
 
   ozaki-r