14 Apr, 2007

5 commits

  • * master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
    [SPARC64]: Fix inline directive in pci_iommu.c
    [SPARC64]: Fix arg passing to compat_sys_ipc().
    [SPARC]: Fix section mismatch warnings in pci.c and pcic.c
    [SUNRPC]: Make sure on-stack cmsg buffer is properly aligned.
    [SPARC]: avoid CHILD_MAX and OPEN_MAX constants
    [SPARC64]: Fix SBUS IOMMU allocation code.

    Linus Torvalds
     
  • There are two device string comparison loops in arp_packet_match().
    The first one goes byte-by-byte but the second one tries to be
    clever and cast the string to a long and compare by longs.

    The device name strings in the arp table entries are not guarenteed
    to be aligned enough to make this value, so just use byte-by-byte
    for both cases.

    Based upon a report by .

    Signed-off-by: David S. Miller

    David S. Miller
     
  • A packet which is being discarded because of no routes in the
    forwarding path should not be counted as OutNoRoutes but as
    InNoRoutes.
    Additionally, on this occasion, a packet whose destinaion is
    not valid should be counted as InAddrErrors separately.

    Based on patch from Mitsuru Chinen .

    Signed-off-by: YOSHIFUJI Hideaki
    Signed-off-by: David S. Miller

    YOSHIFUJI Hideaki
     
  • When sending a security context of 50+ characters in an ACQUIRE
    message, following kernel panic occurred.

    kernel BUG in xfrm_send_acquire at net/xfrm/xfrm_user.c:1781!
    cpu 0x3: Vector: 700 (Program Check) at [c0000000421bb2e0]
    pc: c00000000033b074: .xfrm_send_acquire+0x240/0x2c8
    lr: c00000000033b014: .xfrm_send_acquire+0x1e0/0x2c8
    sp: c0000000421bb560
    msr: 8000000000029032
    current = 0xc00000000fce8f00
    paca = 0xc000000000464b00
    pid = 2303, comm = ping
    kernel BUG in xfrm_send_acquire at net/xfrm/xfrm_user.c:1781!
    enter ? for help
    3:mon> t
    [c0000000421bb650] c00000000033538c .km_query+0x6c/0xec
    [c0000000421bb6f0] c000000000337374 .xfrm_state_find+0x7f4/0xb88
    [c0000000421bb7f0] c000000000332350 .xfrm_tmpl_resolve+0xc4/0x21c
    [c0000000421bb8d0] c0000000003326e8 .xfrm_lookup+0x1a0/0x5b0
    [c0000000421bba00] c0000000002e6ea0 .ip_route_output_flow+0x88/0xb4
    [c0000000421bbaa0] c0000000003106d8 .ip4_datagram_connect+0x218/0x374
    [c0000000421bbbd0] c00000000031bc00 .inet_dgram_connect+0xac/0xd4
    [c0000000421bbc60] c0000000002b11ac .sys_connect+0xd8/0x120
    [c0000000421bbd90] c0000000002d38d0 .compat_sys_socketcall+0xdc/0x214
    [c0000000421bbe30] c00000000000869c syscall_exit+0x0/0x40
    --- Exception: c00 (System Call) at 0000000007f0ca9c
    SP (fc0ef8f0) is in userspace

    We are using size of security context from xfrm_policy to determine
    how much space to alloc skb and then putting security context from
    xfrm_state into skb. Should have been using size of security context
    from xfrm_state to alloc skb. Following fix does that

    Signed-off-by: Joy Latten
    Acked-by: James Morris
    Signed-off-by: David S. Miller

    Joy Latten
     
  • When a VLAN interface is created on top of a bridge interface and
    netfilter is enabled to see the bridged packets, the packets can be
    corrupted when passing through the netfilter code. This is caused by the
    VLAN driver not setting the 'protocol' and 'nh' members of the sk_buff
    structure. In general, this is no problem as the VLAN interface is mostly
    connected to a physical ethernet interface which does not use the
    'protocol' and 'nh' members. For a bridge interface, however, these
    members do matter.

    Signed-off-by: Jerome Borsboom
    Signed-off-by: David S. Miller

    Jerome Borsboom
     

13 Apr, 2007

3 commits


11 Apr, 2007

1 commit

  • The clusterip_config_find_get() already increases entries reference
    counter, so there is no reason to do it twice in checkentry() callback.

    This causes the config to be freed before it is removed from the list,
    resulting in a crash when adding the next rule.

    Signed-off-by: Jaroslav Kysela
    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Jaroslav Kysela
     

10 Apr, 2007

2 commits

  • For the cases that slow_start_after_idle are meant to deal
    with, it is almost a certainty that the congestion window
    tests will think the connection is application limited and
    we'll thus decrease the cwnd there too. This defeats the
    whole point of setting slow_start_after_idle to zero.

    So test it there too.

    We do not cancel out the entire tcp_cwnd_validate() function
    so that if the sysctl is changed we still have the validation
    state maintained.

    Signed-off-by: David S. Miller

    David S. Miller
     
  • Userspace uses an integer for TCA_TCINDEX_SHIFT, the kernel was changed
    to expect and use a u16 value in 2.6.11, which broke compatibility on
    big endian machines. Change back to use int.

    Reported by Ole Reinartz

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     

07 Apr, 2007

1 commit


06 Apr, 2007

4 commits

  • Beet mode looks for the beet pseudo header after the outer IP header,
    which is wrong since that is followed by the ESP header. Additionally
    it needs to adjust the packet length after removing the pseudo header
    and point the data pointer to the real data location.

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     
  • Beet mode decapsulation fails to properly set up the skb pointers, which
    only works by accident in combination with CONFIG_NETFILTER, since in that
    case the skb is fixed up in xfrm4_input before passing it to the netfilter
    hooks.

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     
  • draft-nikander-esp-beet-mode-07.txt states "The padding MUST be filled
    with NOP options as defined in Internet Protocol [1] section 3.1
    Internet header format.", so do that.

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     
  • Beet mode calculates an incorrect value for the transport header location
    when IP options are present, resulting in encapsulation errors.

    The correct location is 4 or 8 bytes before the end of the original IP
    header, depending on whether the pseudo header is padded.

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     

05 Apr, 2007

4 commits

  • Up until this point we've accepted replay window settings greater than
    32 but our bit mask can only accomodate 32 packets. Thus any packet
    with a sequence number within the window but outside the bit mask would
    be accepted.

    This patch causes those packets to be rejected instead.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     
  • Incoming trancated packets are counted as not only InTruncatedPkts but
    also InHdrErrors. They should be counted as InTruncatedPkts only.

    Signed-off-by: Mitsuru Chinen
    Acked-by: YOSHIFUJI Hideaki
    Signed-off-by: David S. Miller

    Mitsuru Chinen
     
  • When we receive an AppleTalk frame shorter than what its header says,
    we still attempt to verify its checksum, and trip on the BUG_ON() at
    the end of function atalk_sum_skb() because of the length mismatch.

    This has security implications because this can be triggered by simply
    sending a specially crafted ethernet frame to a target victim,
    effectively crashing that host. Thus this qualifies, I think, as a
    remote DoS. Here is the frame I used to trigger the crash, in npg
    format:

    {
    # Ethernet header -----

    XX XX XX XX XX XX # Destination MAC
    00 00 00 00 00 00 # Source MAC
    00 1D # Length

    # LLC header -----

    AA AA 03
    08 00 07 80 9B # Appletalk

    # Appletalk header -----

    00 1B # Packet length (invalid)
    00 01 # Fake checksum
    00 00 00 00 # Destination and source networks
    00 00 00 00 # Destination and source nodes and ports

    # Payload -----

    0C 0D 0E 0F 10 11 12 13
    14
    }

    The destination MAC address must be set to those of the victim.

    The severity is mitigated by two requirements:
    * The target host must have the appletalk kernel module loaded. I
    suspect this isn't so frequent.
    * AppleTalk frames are non-IP, thus I guess they can only travel on
    local networks. I am no network expert though, maybe it is possible
    to somehow encapsulate AppleTalk packets over IP.

    The bug has been reported back in June 2004:
    http://bugzilla.kernel.org/show_bug.cgi?id=2979
    But it wasn't investigated, and was closed in July 2006 as both
    reporters had vanished meanwhile.

    This code was new in kernel 2.6.0-test5:
    http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=7ab442d7e0a76402c12553ee256f756097cae2d2
    And not modified since then, so we can assume that vanilla kernels
    2.6.0-test5 and later, and distribution kernels based thereon, are
    affected.

    Note that I still do not know for sure what triggered the bug in the
    real-world cases. The frame could have been corrupted by the kernel if
    we have a bug hiding somewhere. But more likely, we are receiving the
    faulty frame from the network.

    Signed-off-by: Jean Delvare
    Signed-off-by: David S. Miller

    Jean Delvare
     
  • The return value of kernel_recvmsg() should be assigned to "err", not
    compared with the random value of a never initialized "err" (and the "< 0"
    check wrongly always returned false since == comparisons never have a
    result < 0).

    Spotted by the Coverity checker.

    Signed-off-by: Adrian Bunk
    Acked-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk
     

04 Apr, 2007

1 commit

  • The generic networking code ensures that no two networking devices
    have the same name, so there is no time except when sysfs has
    implementation bugs that device_rename when called from
    dev_change_name will fail.

    The current error handling for errors from device_rename in
    dev_change_name is wrong and results in an unusable and unrecoverable
    network device if device_rename is happens to return an error.

    This patch removes the buggy error handling. Which confines the mess
    when device_rename hits a problem to sysfs, instead of propagating it
    the rest of the network stack. Making linux a little more robust.

    Without this patch you can observe what happens when sysfs has a bug
    when CONFIG_SYSFS_DEPRECATED is not set and you attempt to rename
    a real network device to a name like (broken_parity_status, device,
    modalias, power, resource2, subsystem_vendor, class, driver, irq,
    msi_bus, resource, subsystem, uevent, config, enable, local_cpus,
    numa_node, resource0, subsystem_device, vendor)

    Greg has a patch that fixes the sysfs bugs but he doesn't trust it
    for a 2.6.21 timeframe. This patch which just ignores errors should
    be safe and it keeps the system from going completely wacky.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

03 Apr, 2007

4 commits

  • Signed-off-by: John Heffner
    Signed-off-by: David S. Miller

    John Heffner
     
  • In article (at Thu, 29 Mar 2007 14:26:44 -0700 (PDT)), David Miller says:

    > From: Sridhar Samudrala
    > Date: Thu, 29 Mar 2007 14:17:28 -0700
    >
    > > The check for length in rawv6_sendmsg() is incorrect.
    > > As len is an unsigned int, (len < 0) will never be TRUE.
    > > I think checking for IPV6_MAXPLEN(65535) is better.
    > >
    > > Is it possible to send ipv6 jumbo packets using raw
    > > sockets? If so, we can remove this check.
    >
    > I don't see why such a limitation against jumbo would exist,
    > does anyone else?
    >
    > Thanks for catching this Sridhar. A good compiler should simply
    > fail to compile "if (x < 0)" when 'x' is an unsigned type, don't
    > you think :-)

    Dave, we use "int" for returning value,
    so we should fix this anyway, IMHO;
    we should not allow len > INT_MAX.

    Signed-off-by: YOSHIFUJI Hideaki
    Acked-by: Sridhar Samudrala
    Signed-off-by: David S. Miller

    YOSHIFUJI Hideaki
     
  • tp->root is not freed on destruction.

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     
  • This changes the "not found" error return for the lookup
    function to -ESRCH so that it can be distinguished from
    the case where a rule or route resulting in -ENETUNREACH
    has been found during the search.

    It fixes a bug where if DECnet was compiled with routing
    support, but no routes were added to the routing table,
    it was failing to fall back to endnode routing.

    Signed-off-by: Steven Whitehouse
    Signed-off-by: Patrick Caulfield
    Signed-off-by: David S. Miller

    Steven Whitehouse
     

30 Mar, 2007

2 commits


29 Mar, 2007

4 commits

  • I have a bugreport that scrollwheel of bluetooth version of apple
    mightymouse doesn't work. The USB version of mightymouse works, as there
    is a quirk for handling scrollwheel in hid/usbhid for it.

    Now that bluetooth git tree is hooked to generic hid layer, it could easily
    use the quirks which are already present in generic hid parser, hid-input,
    etc.

    Below is a simple patch against bluetooth git tree, which adds quirk
    handling to current bluetooth hidp code, and sets quirk flags for device
    0x05ac/0x030c, which is the bluetooth version of the apple mightymouse.

    Signed-off-by: Jiri Kosina
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jiri Kosina
     
  • * master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
    [DCCP] getsockopt: Fix DCCP_SOCKOPT_[SEND,RECV]_CSCOV

    Linus Torvalds
     
  • * 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6:
    SUN3/3X Lance trivial fix improved
    mv643xx_eth: Fix use of uninitialized port_num field
    forcedeth: fix tx timeout
    forcedeth: fix nic poll
    qla3xxx: bugfix: Jumbo frame handling.
    qla3xxx: bugfix: Dropping interrupt under heavy network load.
    qla3xxx: bugfix: Multi segment sends were getting whacked.
    qla3xxx: bugfix: Add tx control block memset.
    atl1: remove unnecessary crc inversion
    myri10ge: correctly detect when TSO should be used
    [PATCH] WE-22 : prevent information leak on 64 bit
    [PATCH] wext: Add missing ioctls to 6432 conversion
    [PATCH] bcm43xx: Fix machine check on PPC for version 1 PHY
    [PATCH] bcm43xx: fix radio_set_tx_iq
    [PATCH] bcm43xx: Fix code for confusion between PHY revision and PHY version

    Linus Torvalds
     
  • We were only checking if there was enough space to put the int, but
    left len as specified by the (malicious) user, sigh, fix it by setting
    len to sizeof(val) and transfering just one int worth of data, the one
    asked for.

    Also check for negative len values.

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     

28 Mar, 2007

4 commits


27 Mar, 2007

3 commits


26 Mar, 2007

2 commits

  • Ingress queueing uses a seperate lock for serializing enqueue operations,
    but fails to properly protect itself against concurrent changes to the
    qdisc tree. Use queue_lock for now since the real fix it quite intrusive.

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     
  • cls_basic doesn't allocate tp->root before it is linked into the
    active classifier list, resulting in a NULL pointer dereference
    when packets hit the classifier before its ->change function is
    called.

    Reported by Chris Madden

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy