[freebsd-current]Who should reset M_PKTHDR flag in m_buf when IP packets are fragmented. m_unshare panic throw when IPSec is enabled
Andrey V. Elsukov
bu7cher at yandex.ru
Wed Dec 27 21:05:24 UTC 2017
On 27.12.2017 23:09, Navdeep Parhar wrote:
>> It is not clear to me why it helps. The panic happens on outbound path,
>> where mbuf should be allocated by network stack and should be writeable.
>> ip_reass() usually used on inbound path. I think the patch just hides
>> the problem in another place.
>> Do you mean that cxgbe can produce !WRITEABLE mbuf for received packet
>> and then pass it to the network stack?
>
> Yes, cxgbe does that. But I think the real bug here is in ip_reass
> because it doesn't properly get rid of the pkthdr of the fragments while
> creating the reassembled datagram. cxgbe happens to trip on this easily
> because it often creates !WRITEABLE mbufs.
From the quick look, I don't see the code in netipsec and in crypto,
that does check mbuf is WRITEABLE. It is expected that in most cases for
received mbuf the data will be decrypted and copied back into the given
buffer. Can this lead to memory corruption?
> This should fix it:
> https://people.freebsd.org/~np/ip_reass_demotehdr.diff
>
> It will also fix leaks in configurations where mbuf tags are in use by
> default (for example with MAC), ip_reass is involved during rx, and the
> mbuf chain never gets m_demote'd elsewhere (meaning ip_reass should have
> freed the tags itself).
I think such chain with several mbufs with M_PKTHDR flag is created with
m_cat() due to !WRITEABLE mbufs. And when mbuf chain will be freed, the
tags chain will be also destroyed by mbuf zone destructor.
If you think it solves the problem, the IPv6 fragment reassembly
probably needs the same code. But I think that M_WRITEABLE flag is not
properly handled is the problem too.
--
WBR, Andrey V. Elsukov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20171227/e8aad333/attachment.sig>
More information about the freebsd-net
mailing list