lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 8 Sep 2008 21:05:25 -0700
From:	Jouni Malinen <j@...fi>
To:	David Miller <davem@...emloft.net>
Cc:	j@...fi, jouni.malinen@...eros.com, alex.williamson@...com,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT]: Networking

On Mon, Sep 08, 2008 at 08:43:23PM -0700, David Miller wrote:

> If we're talking about the netlink emission of WEXT blobs, then such
> bits cannot be fixed unfortunately, because via netlink we don't know
> in the message generating context what kind of process will receive
> the message.

OK. Interesting point here is that the old code was using IWEVCUSTOM
which is defined as having header_type IW_HEADER_TYPE_POINT and so are
the new IWEVASSOCREQIE and IWEVASSOCRESPIE. The only difference is in
max_tokens specifying different maximum length for the data. Maybe the
old code was also broken, but wpa_supplicant handled the bogus data
without causing problems (text parsing failing instead of some
parameters being set based on bogus binary data).

> In fact, when broadcasting a netlink message, applications of different
> dispositions can want to receive the message.
> 
> So in essence netlink cases cannot be fixed for COMPAT handling,
> rather, netlink protocols must be designed to be COMPAT agnostic from
> the beginning, and use fixed sized types only.  WEXT was not.

I haven't looked how IW_HEADER_TYPE_POINT headers get encoded with
wireless_send_event(), but it sounds likely something there gets
different field size. It sounds like there is not really a good
solution for this with the current iw event types and should we want to
get the original issue fixed, something new would need to be
specified.. Would people be fine with extending wireless_send_event()
with new event types that use fixed sized fields or is someone going to
be interesting in providing a better replacement for this functionality?

-- 
Jouni Malinen                                            PGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists