possible bug in in_l2tp_match

[Maxime Villard]

I don't think in_l2tp_match() is really correct [1]. Here the mbuf given
as argument is pulled up, but the new pointer is not passed back (detected
as memory leak by Mootja). And it doesn't look like this kind of functions
is supposed to free the mbuf on error either. Same in in6_l2tp_match().

Please enlighten the code with a comment or two if I'm mistaken.

Maxime

[1] https://nxr.netbsd.org/xref/src/sys/netinet/in_l2tp.c?r=1.4#363

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Kengo NAKAHARA]

Hi,

Post by Maxime Villard
I don't think in_l2tp_match() is really correct [1]. Here the mbuf given
as argument is pulled up, but the new pointer is not passed back (detected
as memory leak by Mootja). And it doesn't look like this kind of functions
is supposed to free the mbuf on error either. Same in in6_l2tp_match().
Please enlighten the code with a comment or two if I'm mistaken.
Maxime
[1] https://nxr.netbsd.org/xref/src/sys/netinet/in_l2tp.c?r=1.4#363

You are right. The in{,6}_l2tp_match() should not call m_pullup() as
the match functions just check the packet. In contrast, in{,6}_l2tp_input()
which are the receive packet processing path must call m_pullup().
I fixed them in in_l2tp.c:r1.5 and in6_l2tp.c:r1.8.

Thank you for your pointing out.


Thanks,
--
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
IoT Platform Development Department,
Network Division,
Technology Unit

Kengo NAKAHARA <k-***@iij.ad.jp>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de