Broken RTM_SETLINK message
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) +
> 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