25 May, 2009

1 commit


23 May, 2009

1 commit

  • The requirement for wireless stats to be atomic is now mostly
    artificial since we hold the rtnl _and_ the dev_base_lock for
    iterating the device list. Doing that is not required, just the
    rtnl is sufficient (and the rtnl is required for other reasons
    outlined in commit "wext: fix get_wireless_stats locking").

    This will fix http://bugzilla.kernel.org/show_bug.cgi?id=13344
    and make things easier for drivers.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

21 May, 2009

1 commit

  • Another design flaw in wireless extensions (is anybody
    surprised?) in the way it handles the iw_encode_ext
    structure: The structure is part of the 'extra' memory
    but contains the key length explicitly, instead of it
    just being the length of the extra buffer - size of
    the struct and using the explicit key length only for
    the get operation (which only writes it).

    Therefore, we have this layout:

    extra: +-------------------------+
    | struct iw_encode_ext { |
    | ... |
    | u16 key_len; |
    | u8 key[0]; |
    | }; |
    +-------------------------+
    | key material |
    +-------------------------+

    Now, all drivers I checked use ext->key_len without
    checking that both key_len and the struct fit into the
    extra buffer that has been copied from userspace. This
    leads to a buffer overrun while reading that buffer,
    depending on the driver it may be possible to specify
    arbitrary key_len or it may need to be a proper length
    for the key algorithm specified.

    Thankfully, this is only exploitable by root, but root
    can actually cause a segfault or use kernel memory as
    a key (which you can even get back with siocgiwencode
    or siocgiwencodeext from the key buffer).

    Fix this by verifying that key_len fits into the buffer
    along with struct iw_encode_ext.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

14 May, 2009

1 commit

  • Even though they are true, they cause sparse to complain
    because it doesn't see the __acquires(dev_base_lock) on
    dev_seq_start() because it is only added to the function
    in net/core/dev.c, not the header file. To keep track of
    the nesting correctly we should probably annotate those
    functions publically, but for now let's just remove the
    annotation I added to wext.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

12 May, 2009

1 commit

  • Currently, get_wireless_stats is racy by _design_. This is
    because it returns a buffer, which needs to be statically
    allocated since it cannot be freed if it was allocated
    dynamically. Also, SIOCGIWSTATS and /proc/net/wireless use
    no common lock, and /proc/net/wireless accesses are not
    synchronised against each other. This is a design flaw in
    get_wireless_stats since the beginning.

    This patch fixes it by wrapping /proc/net/wireless accesses
    with the RTNL so they are protected against each other and
    SIOCGIWSTATS. The more correct method of fixing this would
    be to pass in the buffer instead of returning it and have
    the caller take care of synchronisation of the buffer, but
    even then most drivers probably assume that their callback
    is protected by the RTNL like all other wext callbacks.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

07 Jan, 2009

1 commit


07 Dec, 2008

1 commit


13 Aug, 2008

1 commit


20 Jul, 2008

1 commit


17 Jun, 2008

10 commits


26 Mar, 2008

1 commit


29 Jan, 2008

3 commits


20 Nov, 2007

1 commit

  • On 64-bit systems sizeof(struct ifreq) is 8 bytes larger than
    sizeof(struct iwreq).

    For GET calls, the wireless extension code copies back into userspace
    using sizeof(struct ifreq) but userspace and elsewhere only allocates
    a "struct iwreq". Thus, this copy writes past the end of the iwreq
    object and corrupts whatever sits after it in memory.

    Fix the copy_to_user() length.

    This particularly hurts the compat case because the wireless compat
    code uses compat_alloc_userspace() and right after this allocated
    buffer is the current bottom of the user stack, and that's what gets
    overwritten by the copy_to_user() call.

    Signed-off-by: David S. Miller

    David S. Miller
     

11 Oct, 2007

4 commits

  • The problem: proc_net files remember which network namespace the are
    against but do not remember hold a reference count (as that would pin
    the network namespace). So we currently have a small window where
    the reference count on a network namespace may be incremented when opening
    a /proc file when it has already gone to zero.

    To fix this introduce maybe_get_net and get_proc_net.

    maybe_get_net increments the network namespace reference count only if it is
    greater then zero, ensuring we don't increment a reference count after it
    has gone to zero.

    get_proc_net handles all of the magic to go from a proc inode to the network
    namespace instance and call maybe_get_net on it.

    PROC_NET the old accessor is removed so that we don't get confused and use
    the wrong helper function.

    Then I fix up the callers to use get_proc_net and handle the case case
    where get_proc_net returns NULL. In that case I return -ENXIO because
    effectively the network namespace has already gone away so the files
    we are trying to access don't exist anymore.

    Signed-off-by: Eric W. Biederman
    Acked-by: Paul E. McKenney
    Signed-off-by: David S. Miller

    Eric W. Biederman
     
  • This patch makes most of the generic device layer network
    namespace safe. This patch makes dev_base_head a
    network namespace variable, and then it picks up
    a few associated variables. The functions:
    dev_getbyhwaddr
    dev_getfirsthwbytype
    dev_get_by_flags
    dev_get_by_name
    __dev_get_by_name
    dev_get_by_index
    __dev_get_by_index
    dev_ioctl
    dev_ethtool
    dev_load
    wireless_process_ioctl

    were modified to take a network namespace argument, and
    deal with it.

    vlan_ioctl_set and brioctl_set were modified so their
    hooks will receive a network namespace argument.

    So basically anthing in the core of the network stack that was
    affected to by the change of dev_base was modified to handle
    multiple network namespaces. The rest of the network stack was
    simply modified to explicitly use &init_net the initial network
    namespace. This can be fixed when those components of the network
    stack are modified to handle multiple network namespaces.

    For now the ifindex generator is left global.

    Fundametally ifindex numbers are per namespace, or else
    we will have corner case problems with migration when
    we get that far.

    At the same time there are assumptions in the network stack
    that the ifindex of a network device won't change. Making
    the ifindex number global seems a good compromise until
    the network stack can cope with ifindex changes when
    you change namespaces, and the like.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: David S. Miller

    Eric W. Biederman
     
  • This patch makes /proc/net per network namespace. It modifies the global
    variables proc_net and proc_net_stat to be per network namespace.
    The proc_net file helpers are modified to take a network namespace argument,
    and all of their callers are fixed to pass &init_net for that argument.
    This ensures that all of the /proc/net files are only visible and
    usable in the initial network namespace until the code behind them
    has been updated to be handle multiple network namespaces.

    Making /proc/net per namespace is necessary as at least some files
    in /proc/net depend upon the set of network devices which is per
    network namespace, and even more files in /proc/net have contents
    that are relevant to a single network namespace.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: David S. Miller

    Eric W. Biederman
     
  • Makes use of the type safe netlink interface and adds a warning
    if the message is too big for NLMSG_DEFAULT_SIZE to help debug.

    Signed-off-by: Thomas Graf
    Signed-off-by: John W. Linville

    Thomas Graf
     

27 Apr, 2007

8 commits