Commits on Feb 20, 2013
  1. Linux 3.2.39

    bwhacks committed Feb 20, 2013
  2. x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS.

    commit 13d2b4d upstream.
    This fixes CVE-2013-0228 / XSA-42
    Drew Jones while working on CVE-2013-0190 found that that unprivileged guest user
    in 32bit PV guest can use to crash the > guest with the panic like this:
    general protection fault: 0000 [#1] SMP
    last sysfs file: /sys/devices/vbd-51712/block/xvda/dev
    Modules linked in: sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
    iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
    xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_netfront ext4
    mbcache jbd2 xen_blkfront dm_mirror dm_region_hash dm_log dm_mod [last
    unloaded: scsi_wait_scan]
    Pid: 1250, comm: r Not tainted 2.6.32-356.el6.i686 #1
    EIP: 0061:[<c0407462>] EFLAGS: 00010086 CPU: 0
    EIP is at xen_iret+0x12/0x2b
    EAX: eb8d0000 EBX: 00000001 ECX: 08049860 EDX: 00000010
    ESI: 00000000 EDI: 003d0f00 EBP: b77f8388 ESP: eb8d1fe0
     DS: 0000 ES: 007b FS: 0000 GS: 00e0 SS: 0069
    Process r (pid: 1250, ti=eb8d0000 task=c2953550 task.ti=eb8d0000)
     00000000 0027f416 00000073 00000206 b77f8364 0000007b 00000000 00000000
    Call Trace:
    Code: c3 8b 44 24 18 81 4c 24 38 00 02 00 00 8d 64 24 30 e9 03 00 00 00
    8d 76 00 f7 44 24 08 00 00 02 80 75 33 50 b8 00 e0 ff ff 21 e0 <8b> 40
    10 8b 04 85 a0 f6 ab c0 8b 80 0c b0 b3 c0 f6 44 24 0d 02
    EIP: [<c0407462>] xen_iret+0x12/0x2b SS:ESP 0069:eb8d1fe0
    general protection fault: 0000 [#2]
    ---[ end trace ab0d29a492dcd330 ]---
    Kernel panic - not syncing: Fatal exception
    Pid: 1250, comm: r Tainted: G      D    ---------------
    2.6.32-356.el6.i686 #1
    Call Trace:
     [<c08476df>] ? panic+0x6e/0x122
     [<c084b63c>] ? oops_end+0xbc/0xd0
     [<c084b260>] ? do_general_protection+0x0/0x210
     [<c084a9b7>] ? error_code+0x73/
    Petr says: "
     I've analysed the bug and I think that xen_iret() cannot cope with
     mangled DS, in this case zeroed out (null selector/descriptor) by either
     xen_failsafe_callback() or RESTORE_REGS because the corresponding LDT
     entry was invalidated by the reproducer. "
    Jan took a look at the preliminary patch and came up a fix that solves
    this problem:
    "This code gets called after all registers other than those handled by
    IRET got already restored, hence a null selector in %ds or a non-null
    one that got loaded from a code or read-only data descriptor would
    cause a kernel mode fault (with the potential of crashing the kernel
    as a whole, if panic_on_oops is set)."
    The way to fix this is to realize that the we can only relay on the
    registers that IRET restores. The two that are guaranteed are the
    %cs and %ss as they are always fixed GDT selectors. Also they are
    inaccessible from user mode - so they cannot be altered. This is
    the approach taken in this patch.
    Another alternative option suggested by Jan would be to relay on
    the subtle realization that using the %ebp or %esp relative references uses
    the %ss segment.  In which case we could switch from using %eax to %ebp and
    would not need the %ss over-rides. That would also require one extra
    instruction to compensate for the one place where the register is used
    as scaled index. However Andrew pointed out that is too subtle and if
    further work was to be done in this code-path it could escape folks attention
    and lead to accidents.
    Reviewed-by: Petr Matousek <>
    Reported-by: Petr Matousek <>
    Reviewed-by: Andrew Cooper <>
    Signed-off-by: Jan Beulich <>
    Signed-off-by: Konrad Rzeszutek Wilk <>
    Signed-off-by: Ben Hutchings <>
    jbeulich committed with bwhacks Jan 24, 2013
  3. tg3: Fix crc errors on jumbo frame receive

    [ Upstream commit daf3ec6 ]
    TG3_PHY_AUXCTL_SMDSP_ENABLE/DISABLE macros do a blind write to the phy
    auxiliary control register and overwrite the EXT_PKT_LEN (bit 14) resulting
    in intermittent crc errors on jumbo frames with some link partners. Change
    the code to do a read/modify/write.
    Signed-off-by: Nithin Nayak Sujir <>
    Signed-off-by: Michael Chan <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Nithin Nayak Sujir committed with bwhacks Jan 14, 2013
  4. tg3: Avoid null pointer dereference in tg3_interrupt in netconsole mode

    [ Upstream commit 9c13cb8 ]
    When netconsole is enabled, logging messages generated during tg3_open
    can result in a null pointer dereference for the uninitialized tg3
    status block. Use the irq_sync flag to disable polling in the early
    stages. irq_sync is cleared when the driver is enabling interrupts after
    all initialization is completed.
    Signed-off-by: Nithin Nayak Sujir <>
    Signed-off-by: Michael Chan <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Nithin Nayak Sujir committed with bwhacks Jan 14, 2013
  5. bridge: Pull ip header into skb->data before looking into ip header.

    [ Upstream commit 6caab7b ]
    If lower layer driver leaves the ip header in the skb fragment, it needs to
    be first pulled into skb->data before inspecting ip header length or ip version
    Signed-off-by: Sarveshwar Bandi <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Sarveshwar Bandi committed with bwhacks Oct 10, 2012
  6. tcp: fix MSG_SENDPAGE_NOTLAST logic

    [ Upstream commit ae62ca7 ]
    commit 35f9c09 (tcp: tcp_sendpages() should call tcp_push() once)
    added an internal flag : MSG_SENDPAGE_NOTLAST meant to be set on all
    frags but the last one for a splice() call.
    The condition used to set the flag in pipe_to_sendpage() relied on
    splice() user passing the exact number of bytes present in the pipe,
    or a smaller one.
    But some programs pass an arbitrary high value, and the test fails.
    The effect of this bug is a lack of tcp_push() at the end of a
    splice(pipe -> socket) call, and possibly very slow or erratic TCP
    We should both test sd->total_len and fact that another fragment
    is in the pipe (pipe->nrbufs > 1)
    Many thanks to Willy for providing very clear bug report, bisection
    and test programs.
    Reported-by: Willy Tarreau <>
    Bisected-by: Willy Tarreau <>
    Tested-by: Willy Tarreau <>
    Signed-off-by: Eric Dumazet <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Eric Dumazet committed with bwhacks Jan 6, 2013
  7. tcp: fix for zero packets_in_flight was too broad

    [ Upstream commit 6731d20 ]
    There are transients during normal FRTO procedure during which
    the packets_in_flight can go to zero between write_queue state
    updates and firing the resulting segments out. As FRTO processing
    occurs during that window the check must be more precise to
    not match "spuriously" :-). More specificly, e.g., when
    packets_in_flight is zero but FLAG_DATA_ACKED is true the problematic
    branch that set cwnd into zero would not be taken and new segments
    might be sent out later.
    Signed-off-by: Ilpo Järvinen <>
    Tested-by: Eric Dumazet <>
    Acked-by: Neal Cardwell <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Ilpo Järvinen committed with bwhacks Feb 4, 2013
  8. tcp: frto should not set snd_cwnd to 0

    [ Upstream commit 2e5f421 ]
    Commit 9dc2741 (tcp: fix ABC in tcp_slow_start())
    uncovered a bug in FRTO code :
    tcp_process_frto() is setting snd_cwnd to 0 if the number
    of in flight packets is 0.
    As Neal pointed out, if no packet is in flight we lost our
    chance to disambiguate whether a loss timeout was spurious.
    We should assume it was a proper loss.
    Reported-by: Pasi Kärkkäinen <>
    Signed-off-by: Neal Cardwell <>
    Signed-off-by: Eric Dumazet <>
    Cc: Ilpo Järvinen <>
    Cc: Yuchung Cheng <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Eric Dumazet committed with bwhacks Feb 3, 2013
  9. netback: correct netbk_tx_err to handle wrap around.

    [ Upstream commit b914972 ]
    Signed-off-by: Ian Campbell <>
    Acked-by: Jan Beulich <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Ian Campbell committed with bwhacks Feb 6, 2013
  10. xen/netback: free already allocated memory on failure in xen_netbk_ge…

    [ Upstream commit 4cc7c1c ]
    Signed-off-by: Ian Campbell <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Ian Campbell committed with bwhacks Feb 6, 2013
  11. xen/netback: don't leak pages on failure in xen_netbk_tx_check_gop.

    [ Upstream commit 7d5145d ]
    Signed-off-by: Matthew Daley <>
    Reviewed-by: Konrad Rzeszutek Wilk <>
    Acked-by: Ian Campbell <>
    Acked-by: Jan Beulich <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Matthew Daley committed with bwhacks Feb 6, 2013
  12. xen/netback: shutdown the ring if it contains garbage.

    [ Upstream commit 4885628 ]
    A buggy or malicious frontend should not be able to confuse netback.
    If we spot anything which is not as it should be then shutdown the
    device and don't try to continue with the ring in a potentially
    hostile state. Well behaved and non-hostile frontends will not be
    As well as making the existing checks for such errors fatal also add a
    new check that ensures that there isn't an insane number of requests
    on the ring (i.e. more than would fit in the ring). If the ring
    contains garbage then previously is was possible to loop over this
    insane number, getting an error each time and therefore not generating
    any more pending requests and therefore not exiting the loop in
    xen_netbk_tx_build_gops for an externded period.
    Also turn various netdev_dbg calls which no precipitate a fatal error
    into netdev_err, they are rate limited because the device is shutdown
    This fixes at least one known DoS/softlockup of the backend domain.
    Signed-off-by: Ian Campbell <>
    Reviewed-by: Konrad Rzeszutek Wilk <>
    Acked-by: Jan Beulich <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Ian Campbell committed with bwhacks Feb 6, 2013
  13. net: sctp: sctp_endpoint_free: zero out secret key data

    [ Upstream commit b5c37fe ]
    On sctp_endpoint_destroy, previously used sensitive keying material
    should be zeroed out before the memory is returned, as we already do
    with e.g. auth keys when released.
    Signed-off-by: Daniel Borkmann <>
    Acked-by: Vlad Yasevich <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    borkmann committed with bwhacks Feb 8, 2013
  14. net: sctp: sctp_setsockopt_auth_key: use kzfree instead of kfree

    [ Upstream commit 6ba542a ]
    In sctp_setsockopt_auth_key, we create a temporary copy of the user
    passed shared auth key for the endpoint or association and after
    internal setup, we free it right away. Since it's sensitive data, we
    should zero out the key before returning the memory back to the
    allocator. Thus, use kzfree instead of kfree, just as we do in
    Signed-off-by: Daniel Borkmann <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    borkmann committed with bwhacks Feb 8, 2013
  15. sctp: refactor sctp_outq_teardown to insure proper re-initalization

    [ Upstream commit 2f94aab ]
    Jamie Parsons reported a problem recently, in which the re-initalization of an
    association (The duplicate init case), resulted in a loss of receive window
    space.  He tracked down the root cause to sctp_outq_teardown, which discarded
    all the data on an outq during a re-initalization of the corresponding
    association, but never reset the outq->outstanding_data field to zero.  I wrote,
    and he tested this fix, which does a proper full re-initalization of the outq,
    fixing this problem, and hopefully future proofing us from simmilar issues down
    the road.
    Signed-off-by: Neil Horman <>
    Reported-by: Jamie Parsons <>
    Tested-by: Jamie Parsons <>
    CC: Jamie Parsons <>
    CC: Vlad Yasevich <>
    CC: "David S. Miller" <>
    Acked-by: Vlad Yasevich <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Neil Horman committed with bwhacks Jan 17, 2013
  16. atm/iphase: rename fregt_t -> ffreg_t

    [ Upstream commit ab54ee8 ]
    We have conflicting type qualifiers for "freg_t" in s390's ptrace.h and the
    iphase atm device driver, which causes the compile error below.
    Unfortunately the s390 typedef can't be renamed, since it's a user visible api,
    nor can I change the include order in s390 code to avoid the conflict.
    So simply rename the iphase typedef to a new name. Fixes this compile error:
    In file included from drivers/atm/iphase.c:66:0:
    drivers/atm/iphase.h:639:25: error: conflicting type qualifiers for 'freg_t'
    In file included from next/arch/s390/include/asm/ptrace.h:9:0,
                     from next/arch/s390/include/asm/lowcore.h:12,
                     from next/arch/s390/include/asm/thread_info.h:30,
                     from include/linux/thread_info.h:54,
                     from include/linux/preempt.h:9,
                     from include/linux/spinlock.h:50,
                     from include/linux/seqlock.h:29,
                     from include/linux/time.h:5,
                     from include/linux/stat.h:18,
                     from include/linux/module.h:10,
                     from drivers/atm/iphase.c:43:
    next/arch/s390/include/uapi/asm/ptrace.h:197:3: note: previous declaration of 'freg_t' was here
    Signed-off-by: Heiko Carstens <>
    Acked-by: chas williams - CONTRACTOR <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Heiko Carstens committed with bwhacks Feb 8, 2013
  17. packet: fix leakage of tx_ring memory

    [ Upstream commit 9665d5d ]
    When releasing a packet socket, the routine packet_set_ring() is reused
    to free rings instead of allocating them. But when calling it for the
    first time, it fills req->tp_block_nr with the value of rb->pg_vec_len
    which in the second invocation makes it bail out since req->tp_block_nr
    is greater zero but req->tp_block_size is zero.
    This patch solves the problem by passing a zeroed auto-variable to
    packet_set_ring() upon each invocation from packet_release().
    As far as I can tell, this issue exists even since 69e3c75 (net: TX_RING
    and packet mmap), i.e. the original inclusion of TX ring support into
    af_packet, but applies only to sockets with both RX and TX ring
    allocated, which is probably why this was unnoticed all the time.
    Signed-off-by: Phil Sutter <>
    Cc: Johann Baudy <>
    Cc: Daniel Borkmann <>
    Acked-by: Daniel Borkmann <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Phil Sutter committed with bwhacks Feb 1, 2013
  18. ipv6: do not create neighbor entries for local delivery

    [ Upstream commit bd30e94 ]
    They will be created at output, if ever needed. This avoids creating
    empty neighbor entries when TPROXYing/Forwarding packets for addresses
    that are not even directly reachable.
    Note that IPv4 already handles it this way. No neighbor entries are
    created for local input.
    Tested by myself and customer.
    Signed-off-by: Jiri Pirko <>
    Signed-off-by: Marcelo Ricardo Leitner <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Marcelo Ricardo Leitner committed with bwhacks Jan 29, 2013
  19. pktgen: correctly handle failures when adding a device

    [ Upstream commit 604dfd6 ]
    The return value of pktgen_add_device() is not checked, so
    even if we fail to add some device, for example, non-exist one,
    we still see "OK:...". This patch fixes it.
    After this patch, I got:
    	# echo "add_device non-exist" > /proc/net/pktgen/kpktgend_0
    	-bash: echo: write error: No such device
    	# cat /proc/net/pktgen/kpktgend_0
    	Result: ERROR: can not add device non-exist
    	# echo "add_device eth0" > /proc/net/pktgen/kpktgend_0
    	# cat /proc/net/pktgen/kpktgend_0
    	Stopped: eth0
    	Result: OK: add_device=eth0
    (Candidate for -stable)
    Cc: David S. Miller <>
    Signed-off-by: Cong Wang <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Cong Wang committed with bwhacks Jan 27, 2013
  20. net: loopback: fix a dst refcounting issue

    [ Upstream commit 794ed39 ]
    Ben Greear reported crashes in ip_rcv_finish() on a stress
    test involving many macvlans.
    We tracked the bug to a dst use after free. ip_rcv_finish()
    was calling dst->input() and got garbage for dst->input value.
    It appears the bug is in loopback driver, lacking
    a skb_dst_force() before calling netif_rx().
    As a result, a non refcounted dst, normally protected by a
    RCU read_lock section, was escaping this section and could
    be freed before the packet being processed.
      [<ffffffff813a3c4d>] loopback_xmit+0x64/0x83
      [<ffffffff81477364>] dev_hard_start_xmit+0x26c/0x35e
      [<ffffffff8147771a>] dev_queue_xmit+0x2c4/0x37c
      [<ffffffff81477456>] ? dev_hard_start_xmit+0x35e/0x35e
      [<ffffffff8148cfa6>] ? eth_header+0x28/0xb6
      [<ffffffff81480f09>] neigh_resolve_output+0x176/0x1a7
      [<ffffffff814ad835>] ip_finish_output2+0x297/0x30d
      [<ffffffff814ad6d5>] ? ip_finish_output2+0x137/0x30d
      [<ffffffff814ad90e>] ip_finish_output+0x63/0x68
      [<ffffffff814ae412>] ip_output+0x61/0x67
      [<ffffffff814ab904>] dst_output+0x17/0x1b
      [<ffffffff814adb6d>] ip_local_out+0x1e/0x23
      [<ffffffff814ae1c4>] ip_queue_xmit+0x315/0x353
      [<ffffffff814adeaf>] ? ip_send_unicast_reply+0x2cc/0x2cc
      [<ffffffff814c018f>] tcp_transmit_skb+0x7ca/0x80b
      [<ffffffff814c3571>] tcp_connect+0x53c/0x587
      [<ffffffff810c2f0c>] ? getnstimeofday+0x44/0x7d
      [<ffffffff810c2f56>] ? ktime_get_real+0x11/0x3e
      [<ffffffff814c6f9b>] tcp_v4_connect+0x3c2/0x431
      [<ffffffff814d6913>] __inet_stream_connect+0x84/0x287
      [<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
      [<ffffffff8108d695>] ? _local_bh_enable_ip+0x84/0x9f
      [<ffffffff8108d6c8>] ? local_bh_enable+0xd/0x11
      [<ffffffff8146763c>] ? lock_sock_nested+0x6e/0x79
      [<ffffffff814d6b38>] ? inet_stream_connect+0x22/0x49
      [<ffffffff814d6b49>] inet_stream_connect+0x33/0x49
      [<ffffffff814632c6>] sys_connect+0x75/0x98
    This bug was introduced in linux-2.6.35, in commit
    7fee226 (net: add a noref bit on skb dst)
    skb_dst_force() is enforced in dev_queue_xmit() for devices having a
    Reported-by: Ben Greear <>
    Signed-off-by: Eric Dumazet <>
    Tested-by: Ben Greear <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Eric Dumazet committed with bwhacks Jan 25, 2013
  21. r8169: remove the obsolete and incorrect AMD workaround

    [ Upstream commit 5d0feaf ]
    This was introduced in commit 6dccd16 "r8169: merge with version
    6.001.00 of Realtek's r8169 driver". I did not find the version
    6.001.00 online, but in 6.002.00 or any later r8169 from Realtek
    this hunk is no longer present.
    Also commit 05af214 "r8169: fix Ethernet Hangup for RTL8110SC
    rev d" claims to have fixed this issue otherwise.
    The magic compare mask of 0xfffe000 is dubious as it masks
    parts of the Reserved part, and parts of the VLAN tag. But this
    does not make much sense as the VLAN tag parts are perfectly
    valid there. In matter of fact this seems to be triggered with
    any VLAN tagged packet as RxVlanTag bit is matched. I would
    suspect 0xfffe0000 was intended to test reserved part only.
    Finally, this hunk is evil as it can cause more packets to be
    handled than what was NAPI quota causing net/core/dev.c:
    net_rx_action(): WARN_ON_ONCE(work > weight) to trigger, and
    mess up the NAPI state causing device to hang.
    As result, any system using VLANs and having high receive
    traffic (so that NAPI poll budget limits rtl_rx) would result
    in device hang.
    Signed-off-by: Timo Teräs <>
    Acked-by: Francois Romieu <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    fabled committed with bwhacks Jan 21, 2013
  22. netxen: fix off by one bug in netxen_release_tx_buffer()

    [ Upstream commit a05948f ]
    Christoph Paasch found netxen could trigger a BUG in its dismantle
    phase, in netxen_release_tx_buffer(), using full size TSO packets.
    cmd_buf->frag_count includes the skb->data part, so the loop must
    start at index 1 instead of 0, or else we can make an out
    of bound access to cmd_buff->frag_array[MAX_SKB_FRAGS + 2]
    Christoph provided the fixes in netxen_map_tx_skb() function.
    In case of a dma mapping error, its better to clear the dma fields
    so that we don't try to unmap them again in netxen_release_tx_buffer()
    Reported-by: Christoph Paasch <>
    Signed-off-by: Eric Dumazet <>
    Tested-by: Christoph Paasch <>
    Cc: Sony Chacko <>
    Cc: Rajesh Borundia <>
    Signed-off-by: Christoph Paasch <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Eric Dumazet committed with bwhacks Jan 22, 2013
  23. isdn/gigaset: fix zero size border case in debug dump

    [ Upstream commit d721a17 ]
    If subtracting 12 from l leaves zero we'd do a zero size allocation,
    leading to an oops later when we try to set the NUL terminator.
    Reported-by: Dan Carpenter <>
    Signed-off-by: Tilman Schmidt <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    tilmanschmidt committed with bwhacks Jan 21, 2013
  24. ipv6: fix header length calculation in ip6_append_data()

    [ Upstream commit 7efdba5 ]
    Commit 299b076 (ipv6: Fix IPsec slowpath fragmentation problem)
    has introduced a error in the header length calculation that
    provokes corrupted packets when non-fragmentable extensions
    headers (Destination Option or Routing Header Type 2) are used.
    rt->rt6i_nfheader_len is the length of the non-fragmentable
    extension header, and it should be substracted to
    rt->dst.header_len, and not to exthdrlen, as it was done before
    commit 299b076.
    This patch reverts to the original and correct behavior. It has
    been successfully tested with and without IPsec on packets
    that include non-fragmentable extensions headers.
    Signed-off-by: Romain Kuntz <>
    Acked-by: Steffen Klassert <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    ipflavors committed with bwhacks Jan 16, 2013
  25. MAINTAINERS: Stephen Hemminger email change

    [ Upstream commit adbbf69 ]
    I changed my email because the mail server is now
    redirected to; and the Brocade mail system
    is not friendly to Linux desktop users.
    Signed-off-by: Stephen Hemminger <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    Stephen Hemminger committed with bwhacks Jan 16, 2013
  26. ipv6: fix the noflags test in addrconf_get_prefix_route

    [ Upstream commit 85da53b ]
    The tests on the flags in addrconf_get_prefix_route() does no make
    much sense: the 'noflags' parameter contains the set of flags that
    must not match with the route flags, so the test must be done
    against 'noflags', and not against 'flags'.
    Signed-off-by: Romain Kuntz <>
    Acked-by: YOSHIFUJI Hideaki <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    ipflavors committed with bwhacks Jan 9, 2013
  27. net: prevent setting ttl=0 via IP_TTL

    [ Upstream commit c9be4a5 ]
    A regression is introduced by the following commit:
    	commit 4d52cfb
    	Author: Eric Dumazet <>
    	Date:   Tue Jun 2 00:42:16 2009 -0700
    	    net: ipv4/ip_sockglue.c cleanups
    	    Pure cleanups
    but it is not a pure cleanup...
    	-               if (val != -1 && (val < 1 || val>255))
    	+               if (val != -1 && (val < 0 || val > 255))
    Since there is no reason provided to allow ttl=0, change it back.
    Reported-by: nitin padalia <>
    Cc: nitin padalia <>
    Cc: Eric Dumazet <>
    Cc: David S. Miller <>
    Signed-off-by: Cong Wang <>
    Acked-by: Eric Dumazet <>
    Signed-off-by: David S. Miller <>
    Signed-off-by: Ben Hutchings <>
    congwang committed with bwhacks Jan 7, 2013
  28. kernel/resource.c: fix stack overflow in __reserve_region_with_split()

    commit 4965f56 upstream.
    Using a recursive call add a non-conflicting region in
    __reserve_region_with_split() could result in a stack overflow in the case
    that the recursive calls are too deep.  Convert the recursive calls to an
    iterative loop to avoid the problem.
    Tested on a machine containing 135 regions.  The kernel no longer panicked
    with stack overflow.
    Also tested with code arbitrarily adding regions with no conflict,
    embedding two consecutive conflicts and embedding two non-consecutive
    Signed-off-by: T Makphaibulchoke <>
    Reviewed-by: Ram Pai <>
    Cc: Paul Gortmaker <>
    Cc: Wei Yang <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Ben Hutchings <>
    T Makphaibulchoke committed with bwhacks Oct 5, 2012
  29. HID: usbhid: quirk for Formosa IR receiver

    commit 320cde1 upstream.
    Patch to add the Formosa Industrial Computing, Inc. Infrared Receiver
    [IR605A/Q] to hid-ids.h and hid-quirks.c.  This IR receiver causes about a 10
    second timeout when the usbhid driver attempts to initialze the device.  Adding
    this device to the quirks list with HID_QUIRK_NO_INIT_REPORTS removes the
    Signed-off-by: Nicholas Santos <>
    [ fix ordering]
    Signed-off-by: Jiri Kosina <>
    Signed-off-by: Ben Hutchings <>
    Nicholas Santos committed with bwhacks Dec 29, 2012
  30. Bluetooth: Fix sending HCI commands after reset

    commit dbccd79 upstream.
    After sending reset command wait for its command complete event before
    sending next command. Some chips sends CC event for command received
    before reset if reset was send before chip replied with CC.
    This is also required by specification that host shall not send
    additional HCI commands before receiving CC for reset.
    < HCI Command: Reset (0x03|0x0003) plen 0                              [hci0] 18.404612
    > HCI Event: Command Complete (0x0e) plen 4                            [hci0] 18.405850
          Write Extended Inquiry Response (0x03|0x0052) ncmd 1
            Status: Success (0x00)
    < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0      [hci0] 18.406079
    > HCI Event: Command Complete (0x0e) plen 4                            [hci0] 18.407864
          Reset (0x03|0x0003) ncmd 1
            Status: Success (0x00)
    < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0      [hci0] 18.408062
    > HCI Event: Command Complete (0x0e) plen 12                           [hci0] 18.408835
    Signed-off-by: Szymon Janc <>
    Acked-by: Johan Hedberg <>
    Signed-off-by: Gustavo Padovan <>
    Signed-off-by: Ben Hutchings <>
    Szymon Janc committed with bwhacks Dec 11, 2012
  31. wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACE…

    …D task
    commit 9067ac8 upstream.
    wake_up_process() should never wakeup a TASK_STOPPED/TRACED task.
    Change it to use TASK_NORMAL and add the WARN_ON().
    TASK_ALL has no other users, probably can be killed.
    Signed-off-by: Oleg Nesterov <>
    Signed-off-by: Linus Torvalds <>
    [bwh: Backported to 3.2: adjust filename]
    Signed-off-by: Ben Hutchings <>
    utrace committed with bwhacks Jan 21, 2013
  32. ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL

    commit 9899d11 upstream.
    putreg() assumes that the tracee is not running and pt_regs_access() can
    safely play with its stack.  However a killed tracee can return from
    ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
    that debugger can actually read/modify the kernel stack until the tracee
    does SAVE_REST again.
    set_task_blockstep() can race with SIGKILL too and in some sense this
    race is even worse, the very fact the tracee can be woken up breaks the
    As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
    call, this ensures that nobody can ever wakeup the tracee while the
    debugger looks at it.  Not only this fixes the mentioned problems, we
    can do some cleanups/simplifications in arch_ptrace() paths.
    Probably ptrace_unfreeze_traced() needs more callers, for example it
    makes sense to make the tracee killable for oom-killer before
    While at it, add the comment into may_ptrace_stop() to explain why
    ptrace_stop() still can't rely on SIGKILL and signal_pending_state().
    Reported-by: Salman Qazi <>
    Reported-by: Suleiman Souhlal <>
    Suggested-by: Linus Torvalds <>
    Signed-off-by: Oleg Nesterov <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Ben Hutchings <>
    utrace committed with bwhacks Jan 21, 2013
  33. ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up()

    commit 910ffdb upstream.
    Cleanup and preparation for the next change.
    signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
    actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
    necessary mask.
    Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
    signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
    which adds __TASK_TRACED.
    This way ptrace_signal_wake_up() can work "inside" ptrace_request()
    even if the tracee doesn't have the TASK_WAKEKILL bit set.
    Signed-off-by: Oleg Nesterov <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Ben Hutchings <>
    utrace committed with bwhacks Jan 21, 2013
  34. ptrace/x86: Partly fix set_task_blockstep()->update_debugctlmsr() logic

    commit 95cf00f upstream.
    Afaics the usage of update_debugctlmsr() and TIF_BLOCKSTEP in
    step.c was always very wrong.
    1. update_debugctlmsr() was simply unneeded. The child sleeps
       TASK_TRACED, __switch_to_xtra(next_p => child) should notice
       TIF_BLOCKSTEP and set/clear DEBUGCTLMSR_BTF after resume if
    2. It is wrong. The state of DEBUGCTLMSR_BTF bit in CPU register
       should always match the state of current's TIF_BLOCKSTEP bit.
    3. Even get_debugctlmsr() + update_debugctlmsr() itself does not
       look right. Irq can change other bits in MSR_IA32_DEBUGCTLMSR
       register or the caller can be preempted in between.
    4. It is not safe to play with TIF_BLOCKSTEP if task != current.
       DEBUGCTLMSR_BTF and TIF_BLOCKSTEP should always match each
       other if the task is running. The tracee is stopped but it
       can be SIGKILL'ed right before set/clear_tsk_thread_flag().
    However, now that uprobes uses user_enable_single_step(current)
    we can't simply remove update_debugctlmsr(). So this patch adds
    the additional "task == current" check and disables irqs to avoid
    the race with interrupts/preemption.
    Unfortunately this patch doesn't solve the last problem, we need
    another fix. Probably we should teach ptrace_stop() to set/clear
    single/block stepping after resume.
    And afaics there is yet another problem: perf can play with
    MSR_IA32_DEBUGCTLMSR from nmi, this obviously means that even
    __switch_to_xtra() has problems.
    Signed-off-by: Oleg Nesterov <>
    Signed-off-by: Ben Hutchings <>
    utrace committed with bwhacks Aug 11, 2012
  35. ptrace/x86: Introduce set_task_blockstep() helper

    commit 848e8f5 upstream.
    No functional changes, preparation for the next fix and for uprobes
    single-step fixes.
    Move the code playing with TIF_BLOCKSTEP/DEBUGCTLMSR_BTF into the
    new helper, set_task_blockstep().
    Signed-off-by: Oleg Nesterov <>
    Acked-by: Srikar Dronamraju <>
    Signed-off-by: Ben Hutchings <>
    utrace committed with bwhacks Aug 3, 2012