]> git.ipfire.org Git - thirdparty/suricata.git/commit
af-packet: fix looping in ring buffer. 64/head
authorEric Leblond <eric@regit.org>
Sat, 8 Sep 2012 09:48:59 +0000 (11:48 +0200)
committerEric Leblond <eric@regit.org>
Sat, 8 Sep 2012 09:50:00 +0000 (11:50 +0200)
commit4a1a008009563f12e995eb1f01dd0bdd4f3c62de
treef8451f0789aa044e682a51ff08bf043eff41da25
parent0d55950840bc3a2f175b151f58b6756e38a8b275
af-packet: fix looping in ring buffer.

A crash can occurs in the following conditions:
 * Suricata running in other mode than "workers"
 * Kernel fill in the ring buffer
Under this conditions, it is possible that the capture thread reads
a packet that has not yet released by one of the treatment threads
because there is no modification done on the ring buffer entry when
a packet is read. Doing, this it access to memory which can be
released to the kernel and modified. This results in a kind of memory
corruption.

This bug has only been seen recently and this has to be linked with the
read speed improvement recently made in AF_PACKET support.

The patch fixes the issue by modifying the tp_status bitmask in the
ring buffer. It sets the TP_STATUS_USER_BUSY flag when it is confirmed
that the packet will be treated. And at the start of the read, it exits
from the reading loop (returning to poll) when it reaches a packet with
the flag set. As tp_status is set to 0 during packet release the flag
is destroyed when releasing the packet.

Regarding concurrency, we've got a sequence of modification. The
capture thread read the packet and set the flag, then it passes the
queue and the packet get processed by other threads. The change on
tp_status are thus made at different time.

Regarding the value of the flag, the patch uses the last bit of
tp_status to avoid be impacting by a change in kernel. I will
propose a patch to have TP_STATUS_USER_BUSY included in kernel
as this is a generic issue for multithreading application using
AF_PACKET mechanism.
src/source-af-packet.c