On Wed, Jan 12, 2022 at 10:50:50AM +0100, Christian Ehrhardt wrote:
| So here is what happens:
| - The iwx(4) (and the iwm(4) driver for that matter) receive multiple
| IP packets in an aggregated WLAN packet. All of these packets
| live in the same mbuf cluster.
| - The iwx(4) driver uses m_copym to de-aggregates the packets.
| As a result we get multiple mbufs (mbuf chains) that all reference
| different parts of the same cluster. This should be ok but
| renders the cluster memory read-only (M_READONLY() retruns true).
| - Then some code in the stack appends to one of these mbuf chains.
| The most likely candidate is re-assembly of fragmented IP packets.
| This results in an mbuf chain with two mbufs:
| + The first mbuf contains the data in the read-only mbuf cluster.
| + The second mbuf can be anything but assuming IP re-assembly it is
| probably another mbuf that references a read-only mbuf cluster.
| It is even possible that the second mbuf in fact points to
| the same cluster.
| - This mbuf chain reaches wg_input in wg(4) because it contains
| a wireguard encrypted packet.
| - As wireguard decryption can only deal with buffers but not with
| mbufs, wg_input does this:
| m = m_pullup(m, m->m_pkthdr.len)
| - Unfortunately, m_pullup does not respect the read-only
| property of an mbuf cluster and blindly copies the entire packet
| into the read-only cluster.
| - This overwrites packet data of other packets that reside in the
| same cluster.
| - Most of the time this corruption will simply result in a dropped
| packet and an increased error counter.
| - The panic only happens if the corruption is detected
| during re-ordering: When the packet is saved for reordering
| iwx(4) checks that the packet is a QOS packet. Later when the
| packet is released from the reorder buffer we assume that the
| packet still is a QOS packet and the ieee80211 code panics if
| this is not the case.
|
| IMHO the fix should be in m_pullup, a suggested patch is below.
| Paul already tested an ealier version of this and it seems to fix
| the problem.
This latest version also seems to be stable.
Thanks again, Christian, for all your work on this issue!
Cheers,
Paul
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
