linux-toradex.git/net, branch v2.6.37.2

netfilter: ctnetlink: fix missing refcount increment during dumps

2011-02-24T22:54:36+00:00

commit c71caf4114a0e1da3451cc92fba6a152929cd4c2 upstream.

In 13ee6ac netfilter: fix race in conntrack between dump_table and
destroy, we recovered spinlocks to protect the dump of the conntrack
table according to reports from Stephen and acknowledgments on the
issue from Eric.

In that patch, the refcount bump that allows to keep a reference
to the current ct object was removed. However, we still decrement
the refcount for that object in the output path of
ctnetlink_dump_table():

        if (last)
                nf_ct_put(last)

Cc: Stephen Hemminger 
Signed-off-by: Pablo Neira Ayuso 
Acked-by: Eric Dumazet 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman

netfilter: fix race in conntrack between dump_table and destroy

2011-02-24T22:54:36+00:00

commit 13ee6ac579574a2a95e982b19920fd2495dce8cd upstream.

The netlink interface to dump the connection tracking table has a race
when entries are deleted at the same time. A customer reported a crash
and the backtrace showed thatctnetlink_dump_table was running while a
conntrack entry was being destroyed.
(see https://bugzilla.vyatta.com/show_bug.cgi?id=6402).

According to RCU documentation, when using hlist_nulls the reader
must handle the case of seeing a deleted entry and not proceed
further down the linked list.  The old code would continue
which caused the scan to walk into the free list.

This patch uses locking (rather than RCU) for this operation which
is guaranteed safe, and no longer requires getting reference while
doing dump operation.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

net: deinit automatic LIST_HEAD

2011-02-24T22:54:32+00:00

commit ceaaec98ad99859ac90ac6863ad0a6cd075d8e0e upstream.

commit 9b5e383c11b08784 (net: Introduce
unregister_netdevice_many()) left an active LIST_HEAD() in
rollback_registered(), with possible memory corruption.

Even if device is freed without touching its unreg_list (and therefore
touching the previous memory location holding LISTE_HEAD(single), better
close the bug for good, since its really subtle.

(Same fix for default_device_exit_batch() for completeness)

Reported-by: Michal Hocko 
Tested-by: Michal Hocko 
Reported-by: Eric W. Biderman 
Tested-by: Eric W. Biderman 
Signed-off-by: Linus Torvalds 
Signed-off-by: Eric Dumazet 
CC: Ingo Molnar 
CC: Octavian Purdila 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: clear heap allocation for ethtool_get_regs()

2011-02-17T23:14:58+00:00

commit b7c7d01aaed1f71d9afe815a569f0a81465a1744 upstream.

There is a conflict between commit b00916b1 and a77f5db3. This patch resolves
the conflict by clearing the heap allocation in ethtool_get_regs().

Signed-off-by: Eugene Teo 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: ax25: fix information leak to userland harder

2011-02-17T23:14:37+00:00

commit 5b919f833d9d60588d026ad82d17f17e8872c7a9 upstream.

Commit fe10ae53384e48c51996941b7720ee16995cbcb7 adds a memset() to clear
the structure being sent back to userspace, but accidentally used the
wrong size.

Reported-by: Brad Spengler 
Signed-off-by: Kees Cook 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: Fix ip link add netns oops

2011-02-17T23:14:33+00:00

commit 13ad17745c2cbd437d9e24b2d97393e0be11c439 upstream.

Ed Swierk  writes:
> On 2.6.35.7
>  ip link add link eth0 netns 9999 type macvlan
> where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang:
> [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d
>  [10663.821917] IP: [] __dev_alloc_name+0x9a/0x170
>  [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0
>  [10663.821944] Oops: 0000 [#1] SMP
>  [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
>  [10663.821959] CPU 3
>  [10663.821963] Modules linked in: macvlan ip6table_filter ip6_tables rfcomm ipt_MASQUERADE binfmt_misc iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack sco ipt_REJECT bnep l2cap xt_tcpudp iptable_filter ip_tables x_tables bridge stp vboxnetadp vboxnetflt vboxdrv kvm_intel kvm parport_pc ppdev snd_hda_codec_intelhdmi snd_hda_codec_conexant arc4 iwlagn iwlcore mac80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi i915 snd_seq_midi_event snd_seq thinkpad_acpi drm_kms_helper btusb tpm_tis nvram uvcvideo snd_timer snd_seq_device bluetooth videodev v4l1_compat v4l2_compat_ioctl32 tpm drm tpm_bios snd cfg80211 psmouse serio_raw intel_ips soundcore snd_page_alloc intel_agp i2c_algo_bit video output netconsole configfs lp parport usbhid hid e1000e sdhci_pci ahci libahci sdhci led_class
>  [10663.822155]
>  [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO
>  [10663.822167] RIP: 0010:[] [] __dev_alloc_name+0x9a/0x170
>  [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286
>  [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000
>  [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000
>  [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041
>  [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818
>  [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000
>  [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000
>  [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>  [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0
>  [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>  [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>  [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0)
>  [10663.822236] Stack:
>  [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6
>  [10663.822251] <0> 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818
>  [10663.822265] <0> ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413
>  [10663.822281] Call Trace:
>  [10663.822290] [] ? dev_addr_init+0x75/0xb0
>  [10663.822298] [] dev_alloc_name+0x43/0x90
>  [10663.822307] [] rtnl_create_link+0xbe/0x1b0
>  [10663.822314] [] rtnl_newlink+0x48a/0x570
>  [10663.822321] [] ? rtnl_newlink+0x1ac/0x570
>  [10663.822332] [] ? native_x2apic_icr_read+0x4/0x20
>  [10663.822339] [] rtnetlink_rcv_msg+0x177/0x290
>  [10663.822346] [] ? rtnetlink_rcv_msg+0x0/0x290
>  [10663.822354] [] netlink_rcv_skb+0xa9/0xd0
>  [10663.822360] [] rtnetlink_rcv+0x25/0x40
>  [10663.822367] [] netlink_unicast+0x2de/0x2f0
>  [10663.822374] [] netlink_sendmsg+0x1fe/0x2e0
>  [10663.822383] [] sock_sendmsg+0xf3/0x120
>  [10663.822391] [] ? _raw_spin_lock+0xe/0x20
>  [10663.822400] [] ? __d_lookup+0x136/0x150
>  [10663.822406] [] ? _raw_spin_lock+0xe/0x20
>  [10663.822414] [] ? _atomic_dec_and_lock+0x4d/0x80
>  [10663.822422] [] ? mntput_no_expire+0x30/0x110
>  [10663.822429] [] ? move_addr_to_kernel+0x65/0x70
>  [10663.822435] [] ? verify_iovec+0x88/0xe0
>  [10663.822442] [] sys_sendmsg+0x240/0x3a0
> [10663.822450] [] ? __do_fault+0x479/0x560
>  [10663.822457] [] ? _raw_spin_lock+0xe/0x20
>  [10663.822465] [] ? alloc_fd+0x10a/0x150
>  [10663.822473] [] ? do_page_fault+0x15e/0x350
>  [10663.822482] [] system_call_fastpath+0x16/0x1b
>  [10663.822487] Code: 90 48 8d 78 02 be 25 00 00 00 e8 92 1d e2 ff 48 85 c0 75 cf bf 20 00 00 00 e8 c3 b1 c6 ff 49 89 c7 b8 f4 ff ff ff 4d 85 ff 74 bd <4d> 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55
>  [10663.822618] RIP [] __dev_alloc_name+0x9a/0x170
>  [10663.822627] RSP 
>  [10663.822631] CR2: 000000000000006d
>  [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]---

This bug was introduced in:
commit 81adee47dfb608df3ad0b91d230fb3cef75f0060
Author: Eric W. Biederman 
Date:   Sun Nov 8 00:53:51 2009 -0800

    net: Support specifying the network namespace upon device creation.

    There is no good reason to not support userspace specifying the
    network namespace during device creation, and it makes it easier
    to create a network device and pass it to a child network namespace
    with a well known name.

    We have to be careful to ensure that the target network namespace
    for the new device exists through the life of the call.  To keep
    that logic clear I have factored out the network namespace grabbing
    logic into rtnl_link_get_net.

    In addtion we need to continue to pass the source network namespace
    to the rtnl_link_ops.newlink method so that we can find the base
    device source network namespace.

    Signed-off-by: Eric W. Biederman 
    Acked-by: Eric Dumazet 

Where apparently I forgot to add error handling to the path where we create
a new network device in a new network namespace, and pass in an invalid pid.

Reported-by: Ed Swierk 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net_sched: pfifo_head_drop problem

2011-02-17T23:14:23+00:00

[ Upstream commit 44b8288308ac9da27eab7d7bdbf1375a568805c3 ]

commit 57dbb2d83d100ea (sched: add head drop fifo queue)
introduced pfifo_head_drop, and broke the invariant that
sch->bstats.bytes and sch->bstats.packets are COUNTER (increasing
counters only)

This can break estimators because est_timer() handles unsigned deltas
only. A decreasing counter can then give a huge unsigned delta.

My mid term suggestion would be to change things so that
sch->bstats.bytes and sch->bstats.packets are incremented in dequeue()
only, not at enqueue() time. We also could add drop_bytes/drop_packets
and provide estimations of drop rates.

It would be more sensible anyway for very low speeds, and big bursts.
Right now, if we drop packets, they still are accounted in byte/packets
abolute counters and rate estimators.

Before this mid term change, this patch makes pfifo_head_drop behavior
similar to other qdiscs in case of drops :
Dont decrement sch->bstats.bytes and sch->bstats.packets

Signed-off-by: Eric Dumazet 
Acked-by: Hagen Paul Pfeifer 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv4: IP defragmentation must be ECN aware

2011-02-17T23:14:23+00:00

[ Upstream commit 6623e3b24a5ebb07e81648c478d286a1329ab891 ]

RFC3168 (The Addition of Explicit Congestion Notification to IP)
states :

5.3.  Fragmentation

   ECN-capable packets MAY have the DF (Don't Fragment) bit set.
   Reassembly of a fragmented packet MUST NOT lose indications of
   congestion.  In other words, if any fragment of an IP packet to be
   reassembled has the CE codepoint set, then one of two actions MUST be
   taken:

      * Set the CE codepoint on the reassembled packet.  However, this
        MUST NOT occur if any of the other fragments contributing to
        this reassembly carries the Not-ECT codepoint.

      * The packet is dropped, instead of being reassembled, for any
        other reason.

This patch implements this requirement for IPv4, choosing the first
action :

If one fragment had NO-ECT codepoint
        reassembled frame has NO-ECT
ElIf one fragment had CE codepoint
        reassembled frame has CE

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: add POLLPRI to sock_def_readable()

2011-02-17T23:14:23+00:00

[ Upstream commit 2c6607c611cb7bf0a6750bcea34a258144e302c5 ]

Leonardo Chiquitto found poll() could block forever on tcp sockets and
Urgent data was received, if the event flag only contains POLLPRI.

He did a bisection and found commit 4938d7e0233 (poll: avoid extra
wakeups in select/poll) was the source of the problem.

Problem is TCP sockets use standard sock_def_readable() function for
their sk_data_ready() handler, and sock_def_readable() doesnt signal
POLLPRI.

Only TCP is affected by the problem. Adding POLLPRI to the list of flags
might trigger unnecessary schedules, but URGENT handling is such a
seldom used feature this seems a good compromise.

Thanks a lot to Leonardo for providing the bisection result and a test
program as well.

Reference : http://www.spinics.net/lists/netdev/msg151793.html

Reported-and-bisected-by: Leonardo Chiquitto 
Signed-off-by: Eric Dumazet 
Tested-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

inet6: prevent network storms caused by linux IPv6 routers

2011-02-17T23:14:23+00:00

[ Upstream commit 72b43d0898e97f588293b4a24b33c58c46633d81 ]

Linux IPv6 forwards unicast packets, which are link layer multicasts...
The hole was present since day one. I was 100% this check is there, but it is not.

The problem shows itself, f.e. when Microsoft Network Load Balancer runs on a network.
This software resolves IPv6 unicast addresses to multicast MAC addresses.

Signed-off-by: Alexey Kuznetsov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman