]> git.baikalelectronics.ru Git - kernel.git/commit
packet: tpacket_v3: do not trigger bug() on wrong header status
authorDaniel Borkmann <dborkman@redhat.com>
Fri, 3 May 2013 02:57:00 +0000 (02:57 +0000)
committerDavid S. Miller <davem@davemloft.net>
Fri, 3 May 2013 20:10:33 +0000 (16:10 -0400)
commitb180e14f91c6dd255b9956838de0a205e793bbf0
tree46686ea6065471491e4cc052ab85c8cb29a9d146
parentab7c8a03b16a9b03eb30dedd84112c70cf3c7d44
packet: tpacket_v3: do not trigger bug() on wrong header status

Jakub reported that it is fairly easy to trigger the BUG() macro
from user space with TPACKET_V3's RX_RING by just giving a wrong
header status flag. We already had a similar situation in commit
62f2b544011b7d8 (``af_packet: remove BUG statement in
tpacket_destruct_skb'') where this was the case in the TX_RING
side that could be triggered from user space. So really, don't use
BUG() or BUG_ON() unless there's really no way out, and i.e.
don't use it for consistency checking when there's user space
involved, no excuses, especially not if you're slapping the user
with WARN + dump_stack + BUG all at once. The two functions are
of concern:

  prb_retire_current_block() [when block status != TP_STATUS_KERNEL]
  prb_open_block() [when block_status != TP_STATUS_KERNEL]

Calls to prb_open_block() are guarded by ealier checks if block_status
is really TP_STATUS_KERNEL (racy!), but the first one BUG() is easily
triggable from user space. System behaves still stable after they are
removed. Also remove that yoda condition entirely, since it's already
guarded.

Reported-by: Jakub Zawadzki <darkjames-ws@darkjames.pl>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/packet/af_packet.c