From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Thu, 25 Jan 2007 16:22:20 +0300
> Actually, it can. Return value was used only as sign of error,
> so that the mistake was to return original unsigned result casted to int.
>
> Alternative fix is enclosed. To be honest, it is not better than
> your
Hello!
> So this whole idea to make run_filter() return signed integers
> and fail on negative is entirely flawed, it simply cannot work
> and retain the expected semantics which have been there forever.
Actually, it can. Return value was used only as sign of error,
so that the mistake was to ret
From: Raivis Bucis <[EMAIL PROTECTED]>
Date: Thu, 4 Jan 2007 17:47:46 +0200
> I believe I have found a bug in PF_PACKET socket filtering
> (introduced in linux-2.6.19). If BPF returns values larger than
> 0x8000u, run_filter in af_packet.c considers that as error
> instead of simply accepting
Hello,
I believe I have found a bug in PF_PACKET socket filtering (introduced in
linux-2.6.19). If BPF returns values larger than 0x8000u, run_filter in
af_packet.c considers that as error instead of simply accepting packet in its
full length. sk_filter does not have this problem.
Raivis B
