Eric Lee / smarc-fsl-linux-kernel

14 Oct, 2010

1 commit

  • 10d8dad84   wext: fix alignment problem in serializing 'struct iw_point' ... Browse Code »

    wext: fix alignment problem in serializing 'struct iw_point'

    This fixes a typo in the definition of the serialized length of struct iw_point:
    a) wireless.h is exported to userspace, the typo causes IW_EV_POINT_PK_LEN
    to be 12 on 64-bit, and 8 on 32-bit systems (causing misalignment);
    b) in compat-64 mode iwe_stream_add_point() memcpys overlap (see below).

    The second case in in compat-64 mode looks like (variable names are as in
    include/net/iw_handler.h:iwe_stream_add_point()):

    point_len = IW_EV_COMPAT_POINT_LEN = 8
    lcp_len = IW_EV_COMPAT_LCP_LEN = 4
    2nd memcpy: IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN = 12 - 4 = 8

    IW_EV_LCP_PK_LEN
    *---> 'extra' data area
    +-------+-------+-------+-------+---------------+------- ...-+
    | len | cmd |length | flags | (empty) -> extra ... |
    +-------+-------+-------+-------+---------------+------- ...-+
    2 2 2 2 4

    lcp_len



    This case could cause overrun whenever iw_point.length < 4.
    The other two cases are -
    * 32-bit systems: IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN = 8 - 4 = 4,
    the second memcpy copies exactly the 4 required bytes;
    * 64-bit systems: IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN = 12 - 4 = 8,
    the second memcpy copies a superfluous (but non overlapping) 4 bytes.

    The patch changes IW_EV_POINT_PK_LEN to be 8, so that in all 3 cases always only
    the requested iw_point.{length,flags} (both __u16) are copied, avoiding overrrun
    (compat-64) and superfluous copy (64-bit). In addition, the userspace header is
    sanitized (in agreement with version 30 of the wireless tools).

    Many thanks to Johannes Berg for help and review with this patch.

    Signed-off-by: Gerrit Renker
    Signed-off-by: John W. Linville

    Gerrit Renker
     

24 Mar, 2010

2 commits

15 Jul, 2009

1 commit

  • 1dacc76d0   net/compat/wext: send different messages to compat tasks ... Browse Code »

    Wireless extensions have the unfortunate problem that events
    are multicast netlink messages, and are not independent of
    pointer size. Thus, currently 32-bit tasks on 64-bit platforms
    cannot properly receive events and fail with all kinds of
    strange problems, for instance wpa_supplicant never notices
    disassociations, due to the way the 64-bit event looks (to a
    32-bit process), the fact that the address is all zeroes is
    lost, it thinks instead it is 00:00:00:00:01:00.

    The same problem existed with the ioctls, until David Miller
    fixed those some time ago in an heroic effort.

    A different problem caused by this is that we cannot send the
    ASSOCREQIE/ASSOCRESPIE events because sending them causes a
    32-bit wpa_supplicant on a 64-bit system to overwrite its
    internal information, which is worse than it not getting the
    information at all -- so we currently resort to sending a
    custom string event that it then parses. This, however, has a
    severe size limitation we are frequently hitting with modern
    access points; this limitation would can be lifted after this
    patch by sending the correct binary, not custom, event.

    A similar problem apparently happens for some other netlink
    users on x86_64 with 32-bit tasks due to the alignment for
    64-bit quantities.

    In order to fix these problems, I have implemented a way to
    send compat messages to tasks. When sending an event, we send
    the non-compat event data together with a compat event data in
    skb_shinfo(main_skb)->frag_list. Then, when the event is read
    from the socket, the netlink code makes sure to pass out only
    the skb that is compatible with the task. This approach was
    suggested by David Miller, my original approach required
    always sending two skbs but that had various small problems.

    To determine whether compat is needed or not, I have used the
    MSG_CMSG_COMPAT flag, and adjusted the call path for recv and
    recvfrom to include it, even if those calls do not have a cmsg
    parameter.

    I have not solved one small part of the problem, and I don't
    think it is necessary to: if a 32-bit application uses read()
    rather than any form of recvmsg() it will still get the wrong
    (64-bit) event. However, neither do applications actually do
    this, nor would it be a regression.

    Signed-off-by: Johannes Berg
    Signed-off-by: David S. Miller

    Johannes Berg
     

30 Jan, 2009

3 commits

17 Jun, 2008

2 commits

  • ccc580571   wext: Emit event stream entries correctly when compat. ... Browse Code »

    Three major portions to this change:

    1) Add IW_EV_COMPAT_LCP_LEN, IW_EV_COMPAT_POINT_OFF,
    and IW_EV_COMPAT_POINT_LEN helper defines.

    2) Delete iw_stream_check_add_*(), they are unused.

    3) Add iw_request_info argument to iwe_stream_add_*(), and use it to
    size the event and pointer lengths correctly depending upon whether
    IW_REQUEST_FLAG_COMPAT is set or not.

    4) The mechanical transformations to the drivers and wireless stack
    bits to get the iw_request_info passed down into the routines
    modified in #3. Also, explicit references to IW_EV_LCP_LEN are
    replaced with iwe_stream_lcp_len(info).

    With a lot of help and bug fixes from Masakazu Mokuno.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • 87de87d5e   wext: Dispatch and handle compat ioctls entirely in net/wireless/wext.c ... Browse Code »

    Next we can kill the hacks in fs/compat_ioctl.c and also
    dispatch compat ioctls down into the driver and 80211 protocol
    helper layers in order to handle iw_point objects embedded in
    stream replies which need to be translated.

    Signed-off-by: David S. Miller

    David S. Miller
     

04 Jun, 2008

1 commit

02 May, 2008

1 commit

07 Mar, 2008

1 commit

03 Feb, 2008

1 commit

29 Jan, 2008

1 commit

  • 374fdfbc6   introduce WEXT scan capabilities ... Browse Code »

    Introduce scan capabilities to WEXT so that userspace can do intelligent
    things with scan behavior such as handling hidden SSIDs more gracefully.
    If the driver reports a specific scan capability, the driver must
    respect the options specified in the iw_scan_req structure when handling
    the SIOCSIWSCAN call, unless it's mode or state does not allow it to do
    so, in which case it must return an error.

    This version switches to Dave Kilroy's suggestion of claiming unused
    padding space for the scan_capa field.

    Signed-off-by: Dan Williams
    Signed-off-by: John W. Linville
    Signed-off-by: David S. Miller

    Dan Williams
     

28 Apr, 2007

1 commit

  • 85d32e7b0   [PATCH] Update my email address from jkmaline@cc.hut.fi to j@w1.fi ... Browse Code »

    After 13 years of use, it looks like my email address is finally going
    to disappear. While this is likely to drop the amount of incoming spam
    greatly ;-), it may also affect more appropriate messages, so let's
    update my email address in various places. In addition, Host AP mailing
    list is subscribers-only and linux-wireless can also be used for
    discussing issues related to this driver which is now shown in
    MAINTAINERS.

    Signed-off-by: Jouni Malinen
    Signed-off-by: John W. Linville

    Jouni Malinen
     

28 Mar, 2007

1 commit

15 Feb, 2007

1 commit

02 Dec, 2006

1 commit

26 Sep, 2006

1 commit

  • baef18651   [PATCH] WE-21 support (core API) ... Browse Code »

    This is version 21 of the Wireless Extensions. Changelog :
    o finishes migrating the ESSID API (remove the +1)
    o netdev->get_wireless_stats is no more
    o long/short retry

    This is a redacted version of a patch originally submitted by Jean
    Tourrilhes. I removed most of the additions, in order to minimize
    future support requirements for nl80211 (or other WE successor).

    CC: Jean Tourrilhes
    Signed-off-by: John W. Linville

    John W. Linville
     

23 Mar, 2006

1 commit

  • 711e2c33a   [PATCH] WE-20 for kernel 2.6.16 ... Browse Code »

    This is version 20 of the Wireless Extensions. This is the
    completion of the RtNetlink work I started early 2004, it enables the
    full Wireless Extension API over RtNetlink.

    Few comments on the patch :
    o totally driver transparent, no change in drivers needed.
    o iwevent were already RtNetlink based since they were created
    (around 2.5.7). This adds all the regular SET and GET requests over
    RtNetlink, using the exact same mechanism and data format as iwevents.
    o This is a Kconfig option, as currently most people have no
    need for it. Surprisingly, patch is actually small and well
    encapsulated.
    o Tested on SMP, attention as been paid to make it 64 bits clean.
    o Code do probably too many checks and could be further
    optimised, but better safe than sorry.
    o RtNetlink based version of the Wireless Tools available on
    my web page for people inclined to try out this stuff.

    I would also like to thank Alexey Kuznetsov for his helpful
    suggestions to make this patch better.

    Signed-off-by: Jean Tourrilhes
    Signed-off-by: John W. Linville

    Jean Tourrilhes
     

07 Sep, 2005

2 commits

  • bbeec90b9   [wireless] build fixes after merging WE-19 Browse Code »
    Jeff Garzik
     
  • 6582c164f   [PATCH] WE-19 for kernel 2.6.13 ... Browse Code »

    Hi Jeff,

    This is version 19 of the Wireless Extensions. It was supposed
    to be the fallback of the WPA API changes, but people seem quite happy
    about it (especially Jouni), so the patch is rather small.
    The patch has been fully tested with 2.6.13 and various
    wireless drivers, and is in its final version. Would you mind pushing
    that into Linus's kernel so that the driver and the apps can take
    advantage ot it ?

    It includes :
    o iwstat improvement (explicit dBm). This is the result of
    long discussions with Dan Williams, the authors of
    NetworkManager. Thanks to him for all the fruitful feedback.
    o remove pointer from event stream. I was not totally sure if
    this pointer was 32-64 bits clean, so I'd rather remove it and be at
    peace with it.
    o remove linux header from wireless.h. This has long been
    requested by people writting user space apps, now it's done, and it
    was not even painful.
    o final deprecation of spy_offset. You did not like it, it's
    now gone for good.
    o Start deprecating dev->get_wireless_stats -> debloat netdev
    o Add "check" version of event macros for ieee802.11
    stack. Jiri Benc doesn't like the current macros, we aim to please ;-)
    All those changes, except the last one, have been bit-roting on
    my web pages for a while...

    Patches for most kernel drivers will follow. Patches for the
    Orinoco and the HostAP drivers have been sent to their respective
    maintainers.

    Have fun...

    Jean
    Signed-off-by: Jeff Garzik

    Jean Tourrilhes
     

13 May, 2005

1 commit

  • fff9cfd99   [PATCH] Wireless Extensions 18 (aka WPA) ... Browse Code »

    This is version 18 of the Wireless Extensions. The main change
    is that it adds all the necessary APIs for WPA and WPA2 support. This
    work was entirely done by Jouni Malinen, so let's thank him for both
    his hard work and deep expertise on the subject ;-)
    This APIs obviously doesn't do much by itself and works in
    concert with driver support (Jouni already sent you the HostAP
    changes) and userspace (Jouni is updating wpa_supplicant). This is
    also orthogonal with the ongoing work on in-kernel IEEE support (but
    potentially useful).
    The patch is attached, tested with 2.6.11. Normally, I would
    ask you to push that directly in the kernel (99% of the patch has been
    on my web page for ages and it does not affect non-WPA stuff), but
    Jouni convinced me that it should bake a few weeks in wireless-2.6
    first, so that other driver maintainers can get up to speed with it.

    Signed-off-by: Jeff Garzik

     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds