29 Nov, 2007

13 commits

  • SCTP-AUTH requires selection of CRYPTO, HMAC and SHA1 since
    SHA1 is a MUST requirement for AUTH. We also support SHA256,
    but that's optional, so fix the code to treat it as such.

    Signed-off-by: Vlad Yasevich

    Vlad Yasevich
     
  • In the case where no autheticated chunks were specified, we were still
    trying to verify that a given chunk needs authentication and doing so
    incorrectly. Add a check for parameter length to make sure we don't
    try to use an empty auth_chunks parameter to verify against.

    Signed-off-by: Vlad Yasevich

    Vlad Yasevich
     
  • Supported extensions parameter was not coded right and ended up
    over-writing memory or causing skb overflows. First, remove
    the FWD_TSN support from as it shouldn't be there and also fix
    the paramter encoding.

    Signed-off-by: Vlad Yasevich

    Vlad Yasevich
     
  • There was a typo that cleared the HMACS parameters when no
    authenticated chunks were specified. We whould be clearing
    the chunks pointer instead of the hmacs.

    Signed-off-by: Vlad Yasevich

    Vlad Yasevich
     
  • Our treatment of Heartbeats is special in that the inital HB chunk
    counts against the error count for the association, where as for
    other chunks, only retransmissions or timeouts count against us.
    As a result, we had an off-by-1 situation with a number of
    Heartbeats we could send.

    Signed-off-by: Vlad Yasevich

    Vlad Yasevich
     
  • Lachlan Andrew observed that my TCP-Illinois implementation uses the
    beta value incorrectly:
    The parameter beta in the paper specifies the amount to decrease
    *by*: that is, on loss,
    W
    Signed-off-by: Herbert Xu

    Stephen Hemminger
     
  • Andrew Morton reported that __xfrm_lookup generates this warning:

    net/xfrm/xfrm_policy.c: In function '__xfrm_lookup':
    net/xfrm/xfrm_policy.c:1449: warning: 'dst' may be used uninitialized in this function

    This is because if policy->action is of an unexpected value then dst will
    not be initialised. Of course, in practice this should never happen since
    the input layer xfrm_user/af_key will filter out all illegal values. But
    the compiler doesn't know that of course.

    So this patch fixes this by taking the conservative approach and treat all
    unknown actions the same as a blocking action.

    Thanks to Andrew for finding this and providing an initial fix.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • The following race is possible when one cpu unregisters the handler
    while other one is trying to receive a message and call this one:

    CPU1: CPU2:
    inet_diag_rcv() inet_diag_unregister()
    mutex_lock(&inet_diag_mutex);
    netlink_rcv_skb(skb, &inet_diag_rcv_msg);
    if (inet_diag_table[nlh->nlmsg_type] ==
    NULL) /* false handler is still registered */
    ...
    netlink_dump_start(idiagnl, skb, nlh,
    inet_diag_dump, NULL);
    cb = kzalloc(sizeof(*cb), GFP_KERNEL);
    /* sleep here freeing memory
    * or preempt
    * or sleep later on nlk->cb_mutex
    */
    spin_lock(&inet_diag_register_lock);
    inet_diag_table[type] = NULL;
    ... spin_unlock(&inet_diag_register_lock);
    synchronize_rcu();
    /* CPU1 is sleeping - RCU quiescent
    * state is passed
    */
    return;
    /* inet_diag_dump is finally called: */
    inet_diag_dump()
    handler = inet_diag_table[cb->nlh->nlmsg_type];
    BUG_ON(handler == NULL);
    /* OOPS! While we slept the unregister has set
    * handler to NULL :(
    */

    Grep showed, that the register/unregister functions are called
    from init/fini module callbacks for tcp_/dccp_diag, so it's OK
    to use the inet_diag_mutex to synchronize manipulations with the
    inet_diag_table and the access to it.

    Besides, as Herbert pointed out, asynchronous dumps should hold
    this mutex as well, and thus, we provide the mutex as cb_mutex one.

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: Herbert Xu

    Pavel Emelyanov
     
  • This hook is protected with the RCU, so simple

    if (br_should_route_hook)
    br_should_route_hook(...)

    is not enough on some architectures.

    Use the rcu_dereference/rcu_assign_pointer in this case.

    Fixed Stephen's comment concerning using the typeof().

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: Herbert Xu

    Pavel Emelyanov
     
  • In case the br_netfilter_init() (or any subsequent call)
    fails, the br_fdb_fini() must be called to free the allocated
    in br_fdb_init() br_fdb_cache kmem cache.

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: Herbert Xu

    Pavel Emelyanov
     
  • I am not absolutely sure whether this actually is a bug (as in: I've got
    no clue what the standards say or what other implementations do), but at
    least I was pretty surprised when I noticed that a recv() on a
    non-blocking unix domain socket of type SOCK_SEQPACKET (which is connection
    oriented, after all) where the remote end has closed the connection
    returned -1 (EAGAIN) rather than 0 to indicate end of file.

    This is a test case:

    | #include
    | #include
    | #include
    | #include
    | #include
    | #include
    | #include
    |
    | int main(){
    | int sock;
    | struct sockaddr_un addr;
    | char buf[4096];
    | int pfds[2];
    |
    | pipe(pfds);
    | sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
    | addr.sun_family=AF_UNIX;
    | strcpy(addr.sun_path,"/tmp/foobar_testsock");
    | bind(sock,(struct sockaddr *)&addr,sizeof(addr));
    | listen(sock,1);
    | if(fork()){
    | close(sock);
    | sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
    | connect(sock,(struct sockaddr *)&addr,sizeof(addr));
    | fcntl(sock,F_SETFL,fcntl(sock,F_GETFL)|O_NONBLOCK);
    | close(pfds[1]);
    | read(pfds[0],buf,sizeof(buf));
    | recv(sock,buf,sizeof(buf),0); //
    Signed-off-by: Herbert Xu

    Florian Zumbiehl
     
  • Fix misbehavior of vlan_dev_hard_start_xmit() for recursive encapsulations.

    Signed-off-by: Joonwoo Park
    Signed-off-by: Herbert Xu

    Joonwoo Park
     
  • sungem's gem_reset_task() will unconditionally try to disable NAPI even
    when it's called while the interface is not operating and hence the NAPI
    struct isn't enabled. Make napi_disable() depend on gp->running.

    Also removes a superfluous test of gp->running in the same function.

    Signed-off-by: Johannes Berg
    Signed-off-by: Herbert Xu

    Johannes Berg
     

27 Nov, 2007

2 commits

  • The xfrm_timer calls __xfrm_state_delete, which drops the final reference
    manually without triggering destruction of the state. Change it to use
    xfrm_state_put to add the state to the gc list when we're dropping the
    last reference. The timer function may still continue to use the state
    safely since the final destruction does a del_timer_sync().

    Signed-off-by: Patrick McHardy
    Signed-off-by: Herbert Xu

    Patrick McHardy
     
  • if you are lucky (unlucky?) enough to have shared interrupts, the
    interrupt handler can be called before the tasklet and lock are ready
    for use.

    Signed-off-by: chas williams
    Signed-off-by: Herbert Xu

    chas williams
     

26 Nov, 2007

4 commits

  • The #ifdef's in arp_process() were not only a mess, they were also wrong
    in the CONFIG_NET_ETHERNET=n and (CONFIG_NETDEV_1000=y or
    CONFIG_NETDEV_10000=y) cases.

    Since they are not required this patch removes them.

    Also removed are some #ifdef's around #include's that caused compile
    errors after this change.

    Signed-off-by: Adrian Bunk
    Signed-off-by: Herbert Xu

    Adrian Bunk
     
  • The skb_morph function only freed the data part of the dst skb, but leaked
    the auxiliary data such as the netfilter fields. This patch fixes this by
    moving the relevant parts from __kfree_skb to skb_release_all and calling
    it in skb_morph.

    It also makes kfree_skbmem static since it's no longer called anywhere else
    and it now no longer does skb_release_data.

    Thanks to Yasuyuki KOZAKAI for finding this problem and posting a patch for
    it.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • The inet_ehash_locks_alloc() looks like this:

    #ifdef CONFIG_NUMA
    if (size > PAGE_SIZE)
    x = vmalloc(...);
    else
    #endif
    x = kmalloc(...);

    Unlike it, the inet_ehash_locks_alloc() looks like this:

    #ifdef CONFIG_NUMA
    if (size > PAGE_SIZE)
    vfree(x);
    else
    #else
    kfree(x);
    #endif

    The error is obvious - if the NUMA is on and the size
    is less than the PAGE_SIZE we leak the pointer (kfree is
    inside the #else branch).

    Compiler doesn't warn us because after the kfree(x) there's
    a "x = NULL" assignment, so here's another (minor?) bug: we
    don't set x to NULL under certain circumstances.

    Boring explanation, I know... Patch explains it better.

    Signed-off-by: Pavel Emelyanov
    Signed-off-by: Herbert Xu

    Pavel Emelyanov
     
  • The change 050f009e16f908932070313c1745d09dc69fd62b

    [IPSEC]: Lock state when copying non-atomic fields to user-space

    caused a regression.

    Ingo Molnar reports that it causes a potential dead-lock found by the
    lock validator as it tries to take x->lock within xfrm_state_lock while
    numerous other sites take the locks in opposite order.

    For 2.6.24, the best fix is to simply remove the added locks as that puts
    us back in the same state as we've been in for years. For later kernels
    a proper fix would be to reverse the locking order for every xfrm state
    user such that if x->lock is taken together with xfrm_state_lock then
    it is to be taken within it.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

23 Nov, 2007

2 commits

  • The original code has striking complexity to perform a query
    which can be reduced to a very simple compare.

    FIN seqno may be included to write_seq but it should not make
    any significant difference here compared to skb->len which was
    used previously. One won't end up there with SYN still queued.

    Use of write_seq check guarantees that there's a valid skb in
    send_head so I removed the extra check.

    Signed-off-by: Ilpo Järvinen
    Acked-by: John Heffner
    Signed-off-by: Herbert Xu

    Ilpo Järvinen
     
  • It seems that the checked range for receiver window check should
    begin from the first rather than from the last skb that is going
    to be included to the probe. And that can be achieved without
    reference to skbs at all, snd_nxt and write_seq provides the
    correct seqno already. Plus, it SHOULD account packets that are
    necessary to trigger fast retransmit [RFC4821].

    Location of snd_wnd < probe_size/size_needed check is bogus
    because it will cause the other if() match as well (due to
    snd_nxt >= snd_una invariant).

    Removed dead obvious comment.

    Signed-off-by: Ilpo Järvinen
    Signed-off-by: Herbert Xu

    Ilpo Järvinen
     

22 Nov, 2007

5 commits


21 Nov, 2007

11 commits


20 Nov, 2007

3 commits

  • When connection tracking entry (nf_conn) is about to copy itself it can
    have some of its extension users (like nat) as being already freed and
    thus not required to be copied.

    Actually looking at this function I suspect it was copied from
    nf_nat_setup_info() and thus bug was introduced.

    Report and testing from David .

    [ Patrick McHardy states:

    I now understand whats happening:

    - new connection is allocated without helper
    - connection is REDIRECTed to localhost
    - nf_nat_setup_info adds NAT extension, but doesn't initialize it yet
    - nf_conntrack_alter_reply performs a helper lookup based on the
    new tuple, finds the SIP helper and allocates a helper extension,
    causing reallocation because of too little space
    - nf_nat_move_storage is called with the uninitialized nat extension

    So your fix is entirely correct, thanks a lot :) ]

    Signed-off-by: Evgeniy Polyakov
    Acked-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Evgeniy Polyakov
     
  • 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
     
  • Signed-off-by: Joe Perches
    Signed-off-by: David S. Miller

    Joe Perches