Broken RTM_SETLINK message

Jouni Malinen j
Sun Oct 12 09:14:28 PDT 2014


On Mon, Aug 11, 2014 at 10:08:25PM -0700, Marcel Holtmann wrote:
> so I have been looking at netlink traces a bit and it seems that wpa_supplicant is sending a badly formatted RTM_SETLINK message.
> 
>     2d 00 00 00 13 00 01 00 01 00 00 00 00 00 00 00  -...............
>     00 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00  ................
>     05 00 11 00 01 00 00 00 05 00 10 00 05           .............   
> 
> The problem is that it does not pad the message and this causes problems when parsing it. It does seem that the kernel accepts it, but I still think this not a valid message.

Agreed. This is quite odd design and well, it has been there since
beginning when it was added eight years ago.. I don't write that part,
so I'm not completely sure where this came from, but I guess it could
have been based on some other example code from 2006.. :) Anyway, we
might as well fix this finally.

> 		req.hdr.nlmsg_len = NLMSG_ALIGN(req.hdr.nlmsg_len) +
> 			RTA_LENGTH(sizeof(char));

> The problem seems to be that req.hdr.nlmsg_len calculation is done using RTA_LENGTH. That one however only aligns struct rtattr. It does not align the payload. While this is correct for the rta->rta_len assignment, it think it is wrong for req.hdr.nlmsg_len. That should use RTA_SPACE instead.
> 
> 		req.hdr.nlmsg_len += RTA_SPACE(sizeof(char));

Yes, that makes sense.

> The NLMSG_ALIGN(req.hdr.nlmsg_len) looks like double alignment to me and should not be needed since RTA_SPACE will actually take care of it. I think it is just there because of the wrongly used RTA_LENGTH.

Agreed. This seems to "fix" the case of two attributes being included.

> Any thoughts on this?

I'll commit a fix to use += RTA_SPACE.

-- 
Jouni Malinen                                            PGP id EFC895FA



More information about the Hostap mailing list