<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/core, branch linux-2.6.36.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>net: Fix ip link add netns oops</title>
<updated>2011-02-17T22:47:15+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2011-01-29T14:57:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6066deb3a2ca62e7a990676ca3cc82014844881a'/>
<id>6066deb3a2ca62e7a990676ca3cc82014844881a</id>
<content type='text'>
commit 13ad17745c2cbd437d9e24b2d97393e0be11c439 upstream.

Ed Swierk &lt;eswierk@bigswitch.com&gt; writes:
&gt; On 2.6.35.7
&gt;  ip link add link eth0 netns 9999 type macvlan
&gt; where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang:
&gt; [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d
&gt;  [10663.821917] IP: [&lt;ffffffff8149c2fa&gt;] __dev_alloc_name+0x9a/0x170
&gt;  [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0
&gt;  [10663.821944] Oops: 0000 [#1] SMP
&gt;  [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
&gt;  [10663.821959] CPU 3
&gt;  [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
&gt;  [10663.822155]
&gt;  [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO
&gt;  [10663.822167] RIP: 0010:[&lt;ffffffff8149c2fa&gt;] [&lt;ffffffff8149c2fa&gt;] __dev_alloc_name+0x9a/0x170
&gt;  [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286
&gt;  [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000
&gt;  [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000
&gt;  [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041
&gt;  [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818
&gt;  [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000
&gt;  [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000
&gt;  [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&gt;  [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0
&gt;  [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
&gt;  [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
&gt;  [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0)
&gt;  [10663.822236] Stack:
&gt;  [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6
&gt;  [10663.822251] &lt;0&gt; 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818
&gt;  [10663.822265] &lt;0&gt; ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413
&gt;  [10663.822281] Call Trace:
&gt;  [10663.822290] [&lt;ffffffff814a2bb5&gt;] ? dev_addr_init+0x75/0xb0
&gt;  [10663.822298] [&lt;ffffffff8149c413&gt;] dev_alloc_name+0x43/0x90
&gt;  [10663.822307] [&lt;ffffffff814a85ee&gt;] rtnl_create_link+0xbe/0x1b0
&gt;  [10663.822314] [&lt;ffffffff814ab2aa&gt;] rtnl_newlink+0x48a/0x570
&gt;  [10663.822321] [&lt;ffffffff814aafcc&gt;] ? rtnl_newlink+0x1ac/0x570
&gt;  [10663.822332] [&lt;ffffffff81030064&gt;] ? native_x2apic_icr_read+0x4/0x20
&gt;  [10663.822339] [&lt;ffffffff814a8c17&gt;] rtnetlink_rcv_msg+0x177/0x290
&gt;  [10663.822346] [&lt;ffffffff814a8aa0&gt;] ? rtnetlink_rcv_msg+0x0/0x290
&gt;  [10663.822354] [&lt;ffffffff814c25d9&gt;] netlink_rcv_skb+0xa9/0xd0
&gt;  [10663.822360] [&lt;ffffffff814a8a85&gt;] rtnetlink_rcv+0x25/0x40
&gt;  [10663.822367] [&lt;ffffffff814c223e&gt;] netlink_unicast+0x2de/0x2f0
&gt;  [10663.822374] [&lt;ffffffff814c303e&gt;] netlink_sendmsg+0x1fe/0x2e0
&gt;  [10663.822383] [&lt;ffffffff81488533&gt;] sock_sendmsg+0xf3/0x120
&gt;  [10663.822391] [&lt;ffffffff815899fe&gt;] ? _raw_spin_lock+0xe/0x20
&gt;  [10663.822400] [&lt;ffffffff81168656&gt;] ? __d_lookup+0x136/0x150
&gt;  [10663.822406] [&lt;ffffffff815899fe&gt;] ? _raw_spin_lock+0xe/0x20
&gt;  [10663.822414] [&lt;ffffffff812b7a0d&gt;] ? _atomic_dec_and_lock+0x4d/0x80
&gt;  [10663.822422] [&lt;ffffffff8116ea90&gt;] ? mntput_no_expire+0x30/0x110
&gt;  [10663.822429] [&lt;ffffffff81486ff5&gt;] ? move_addr_to_kernel+0x65/0x70
&gt;  [10663.822435] [&lt;ffffffff81493308&gt;] ? verify_iovec+0x88/0xe0
&gt;  [10663.822442] [&lt;ffffffff81489020&gt;] sys_sendmsg+0x240/0x3a0
&gt; [10663.822450] [&lt;ffffffff8111e2a9&gt;] ? __do_fault+0x479/0x560
&gt;  [10663.822457] [&lt;ffffffff815899fe&gt;] ? _raw_spin_lock+0xe/0x20
&gt;  [10663.822465] [&lt;ffffffff8116cf4a&gt;] ? alloc_fd+0x10a/0x150
&gt;  [10663.822473] [&lt;ffffffff8158d76e&gt;] ? do_page_fault+0x15e/0x350
&gt;  [10663.822482] [&lt;ffffffff8100a0f2&gt;] system_call_fastpath+0x16/0x1b
&gt;  [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 &lt;4d&gt; 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55
&gt;  [10663.822618] RIP [&lt;ffffffff8149c2fa&gt;] __dev_alloc_name+0x9a/0x170
&gt;  [10663.822627] RSP &lt;ffff88014aebf7b8&gt;
&gt;  [10663.822631] CR2: 000000000000006d
&gt;  [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]---

This bug was introduced in:
commit 81adee47dfb608df3ad0b91d230fb3cef75f0060
Author: Eric W. Biederman &lt;ebiederm@aristanetworks.com&gt;
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 &lt;ebiederm@aristanetworks.com&gt;
    Acked-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;

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 &lt;eswierk@bigswitch.com&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 13ad17745c2cbd437d9e24b2d97393e0be11c439 upstream.

Ed Swierk &lt;eswierk@bigswitch.com&gt; writes:
&gt; On 2.6.35.7
&gt;  ip link add link eth0 netns 9999 type macvlan
&gt; where 9999 is a nonexistent PID triggers an oops and causes all network functions to hang:
&gt; [10663.821898] BUG: unable to handle kernel NULL pointer dereference at 000000000000006d
&gt;  [10663.821917] IP: [&lt;ffffffff8149c2fa&gt;] __dev_alloc_name+0x9a/0x170
&gt;  [10663.821933] PGD 1d3927067 PUD 22f5c5067 PMD 0
&gt;  [10663.821944] Oops: 0000 [#1] SMP
&gt;  [10663.821953] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
&gt;  [10663.821959] CPU 3
&gt;  [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
&gt;  [10663.822155]
&gt;  [10663.822161] Pid: 6000, comm: ip Not tainted 2.6.35-23-generic #41-Ubuntu 2901CTO/2901CTO
&gt;  [10663.822167] RIP: 0010:[&lt;ffffffff8149c2fa&gt;] [&lt;ffffffff8149c2fa&gt;] __dev_alloc_name+0x9a/0x170
&gt;  [10663.822177] RSP: 0018:ffff88014aebf7b8 EFLAGS: 00010286
&gt;  [10663.822182] RAX: 00000000fffffff4 RBX: ffff8801ad900800 RCX: 0000000000000000
&gt;  [10663.822187] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffff88014ad63000
&gt;  [10663.822191] RBP: ffff88014aebf808 R08: 0000000000000041 R09: 0000000000000041
&gt;  [10663.822196] R10: 0000000000000000 R11: dead000000200200 R12: ffff88014aebf818
&gt;  [10663.822201] R13: fffffffffffffffd R14: ffff88014aebf918 R15: ffff88014ad62000
&gt;  [10663.822207] FS: 00007f00c487f700(0000) GS:ffff880001f80000(0000) knlGS:0000000000000000
&gt;  [10663.822212] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
&gt;  [10663.822216] CR2: 000000000000006d CR3: 0000000231f19000 CR4: 00000000000026e0
&gt;  [10663.822221] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
&gt;  [10663.822226] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
&gt;  [10663.822231] Process ip (pid: 6000, threadinfo ffff88014aebe000, task ffff88014afb16e0)
&gt;  [10663.822236] Stack:
&gt;  [10663.822240] ffff88014aebf808 ffffffff814a2bb5 ffff88014aebf7e8 00000000a00ee8d6
&gt;  [10663.822251] &lt;0&gt; 0000000000000000 ffffffffa00ef940 ffff8801ad900800 ffff88014aebf818
&gt;  [10663.822265] &lt;0&gt; ffff88014aebf918 ffff8801ad900800 ffff88014aebf858 ffffffff8149c413
&gt;  [10663.822281] Call Trace:
&gt;  [10663.822290] [&lt;ffffffff814a2bb5&gt;] ? dev_addr_init+0x75/0xb0
&gt;  [10663.822298] [&lt;ffffffff8149c413&gt;] dev_alloc_name+0x43/0x90
&gt;  [10663.822307] [&lt;ffffffff814a85ee&gt;] rtnl_create_link+0xbe/0x1b0
&gt;  [10663.822314] [&lt;ffffffff814ab2aa&gt;] rtnl_newlink+0x48a/0x570
&gt;  [10663.822321] [&lt;ffffffff814aafcc&gt;] ? rtnl_newlink+0x1ac/0x570
&gt;  [10663.822332] [&lt;ffffffff81030064&gt;] ? native_x2apic_icr_read+0x4/0x20
&gt;  [10663.822339] [&lt;ffffffff814a8c17&gt;] rtnetlink_rcv_msg+0x177/0x290
&gt;  [10663.822346] [&lt;ffffffff814a8aa0&gt;] ? rtnetlink_rcv_msg+0x0/0x290
&gt;  [10663.822354] [&lt;ffffffff814c25d9&gt;] netlink_rcv_skb+0xa9/0xd0
&gt;  [10663.822360] [&lt;ffffffff814a8a85&gt;] rtnetlink_rcv+0x25/0x40
&gt;  [10663.822367] [&lt;ffffffff814c223e&gt;] netlink_unicast+0x2de/0x2f0
&gt;  [10663.822374] [&lt;ffffffff814c303e&gt;] netlink_sendmsg+0x1fe/0x2e0
&gt;  [10663.822383] [&lt;ffffffff81488533&gt;] sock_sendmsg+0xf3/0x120
&gt;  [10663.822391] [&lt;ffffffff815899fe&gt;] ? _raw_spin_lock+0xe/0x20
&gt;  [10663.822400] [&lt;ffffffff81168656&gt;] ? __d_lookup+0x136/0x150
&gt;  [10663.822406] [&lt;ffffffff815899fe&gt;] ? _raw_spin_lock+0xe/0x20
&gt;  [10663.822414] [&lt;ffffffff812b7a0d&gt;] ? _atomic_dec_and_lock+0x4d/0x80
&gt;  [10663.822422] [&lt;ffffffff8116ea90&gt;] ? mntput_no_expire+0x30/0x110
&gt;  [10663.822429] [&lt;ffffffff81486ff5&gt;] ? move_addr_to_kernel+0x65/0x70
&gt;  [10663.822435] [&lt;ffffffff81493308&gt;] ? verify_iovec+0x88/0xe0
&gt;  [10663.822442] [&lt;ffffffff81489020&gt;] sys_sendmsg+0x240/0x3a0
&gt; [10663.822450] [&lt;ffffffff8111e2a9&gt;] ? __do_fault+0x479/0x560
&gt;  [10663.822457] [&lt;ffffffff815899fe&gt;] ? _raw_spin_lock+0xe/0x20
&gt;  [10663.822465] [&lt;ffffffff8116cf4a&gt;] ? alloc_fd+0x10a/0x150
&gt;  [10663.822473] [&lt;ffffffff8158d76e&gt;] ? do_page_fault+0x15e/0x350
&gt;  [10663.822482] [&lt;ffffffff8100a0f2&gt;] system_call_fastpath+0x16/0x1b
&gt;  [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 &lt;4d&gt; 8b 75 70 49 8d 45 70 48 89 45 b8 49 83 ee 58 eb 28 48 8d 55
&gt;  [10663.822618] RIP [&lt;ffffffff8149c2fa&gt;] __dev_alloc_name+0x9a/0x170
&gt;  [10663.822627] RSP &lt;ffff88014aebf7b8&gt;
&gt;  [10663.822631] CR2: 000000000000006d
&gt;  [10663.822636] ---[ end trace 3dfd6c3ad5327ca7 ]---

This bug was introduced in:
commit 81adee47dfb608df3ad0b91d230fb3cef75f0060
Author: Eric W. Biederman &lt;ebiederm@aristanetworks.com&gt;
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 &lt;ebiederm@aristanetworks.com&gt;
    Acked-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;

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 &lt;eswierk@bigswitch.com&gt;
Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>net: fix skb_defer_rx_timestamp()</title>
<updated>2011-01-07T21:58:29+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>eric.dumazet@gmail.com</email>
</author>
<published>2010-12-05T18:50:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b1b27e4a677bc8c92b3c83541b4981c000934bc2'/>
<id>b1b27e4a677bc8c92b3c83541b4981c000934bc2</id>
<content type='text'>
[ Upstream commit a19faf0250e09b16cac169354126404bc8aa342b ]

After commit c1f19b51d1d8 (net: support time stamping in phy devices.),
kernel might crash if CONFIG_NETWORK_PHY_TIMESTAMPING=y and
skb_defer_rx_timestamp() handles a packet without an ethernet header.

Fixes kernel bugzilla #24102

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=24102
Reported-and-tested-by: Andrew Watts &lt;akwatts@ymail.com&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit a19faf0250e09b16cac169354126404bc8aa342b ]

After commit c1f19b51d1d8 (net: support time stamping in phy devices.),
kernel might crash if CONFIG_NETWORK_PHY_TIMESTAMPING=y and
skb_defer_rx_timestamp() handles a packet without an ethernet header.

Fixes kernel bugzilla #24102

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=24102
Reported-and-tested-by: Andrew Watts &lt;akwatts@ymail.com&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net/dst: dst_dev_event() called after other notifiers</title>
<updated>2011-01-07T21:58:29+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>eric.dumazet@gmail.com</email>
</author>
<published>2010-11-09T19:46:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=948ac19ea40013395fd277d43fd9ea3c3dcb491a'/>
<id>948ac19ea40013395fd277d43fd9ea3c3dcb491a</id>
<content type='text'>
[ Upstream commit 332dd96f7ac15e937088fe11f15cfe0210e8edd1 ]

Followup of commit ef885afbf8a37689 (net: use rcu_barrier() in
rollback_registered_many)

dst_dev_event() scans a garbage dst list that might be feeded by various
network notifiers at device dismantle time.

Its important to call dst_dev_event() after other notifiers, or we might
enter the infamous msleep(250) in netdev_wait_allrefs(), and wait one
second before calling again call_netdevice_notifiers(NETDEV_UNREGISTER,
dev) to properly remove last device references.

Use priority -10 to let dst_dev_notifier be called after other network
notifiers (they have the default 0 priority)

Reported-by: Ben Greear &lt;greearb@candelatech.com&gt;
Reported-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Reported-by: Octavian Purdila &lt;opurdila@ixiacom.com&gt;
Reported-by: Benjamin LaHaise &lt;bcrl@kvack.org&gt;
Tested-by: Ben Greear &lt;greearb@candelatech.com&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 332dd96f7ac15e937088fe11f15cfe0210e8edd1 ]

Followup of commit ef885afbf8a37689 (net: use rcu_barrier() in
rollback_registered_many)

dst_dev_event() scans a garbage dst list that might be feeded by various
network notifiers at device dismantle time.

Its important to call dst_dev_event() after other notifiers, or we might
enter the infamous msleep(250) in netdev_wait_allrefs(), and wait one
second before calling again call_netdevice_notifiers(NETDEV_UNREGISTER,
dev) to properly remove last device references.

Use priority -10 to let dst_dev_notifier be called after other network
notifiers (they have the default 0 priority)

Reported-by: Ben Greear &lt;greearb@candelatech.com&gt;
Reported-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Reported-by: Octavian Purdila &lt;opurdila@ixiacom.com&gt;
Reported-by: Benjamin LaHaise &lt;bcrl@kvack.org&gt;
Tested-by: Ben Greear &lt;greearb@candelatech.com&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>filter: fix sk_filter rcu handling</title>
<updated>2011-01-07T21:58:27+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>eric.dumazet@gmail.com</email>
</author>
<published>2010-12-06T17:29:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=414bdc25810282f9cf56a3335e695c263e487727'/>
<id>414bdc25810282f9cf56a3335e695c263e487727</id>
<content type='text'>
[ Upstream commit 46bcf14f44d8f31ecfdc8b6708ec15a3b33316d9 ]

Pavel Emelyanov tried to fix a race between sk_filter_(de|at)tach and
sk_clone() in commit 47e958eac280c263397

Problem is we can have several clones sharing a common sk_filter, and
these clones might want to sk_filter_attach() their own filters at the
same time, and can overwrite old_filter-&gt;rcu, corrupting RCU queues.

We can not use filter-&gt;rcu without being sure no other thread could do
the same thing.

Switch code to a more conventional ref-counting technique : Do the
atomic decrement immediately and queue one rcu call back when last
reference is released.

Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 46bcf14f44d8f31ecfdc8b6708ec15a3b33316d9 ]

Pavel Emelyanov tried to fix a race between sk_filter_(de|at)tach and
sk_clone() in commit 47e958eac280c263397

Problem is we can have several clones sharing a common sk_filter, and
these clones might want to sk_filter_attach() their own filters at the
same time, and can overwrite old_filter-&gt;rcu, corrupting RCU queues.

We can not use filter-&gt;rcu without being sure no other thread could do
the same thing.

Switch code to a more conventional ref-counting technique : Do the
atomic decrement immediately and queue one rcu call back when last
reference is released.

Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>filter: make sure filters dont read uninitialized memory</title>
<updated>2010-12-09T21:33:30+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2010-11-10T18:38:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2bd84dce08a6a782925f5e34c2e87ad957c57007'/>
<id>2bd84dce08a6a782925f5e34c2e87ad957c57007</id>
<content type='text'>
commit 57fe93b374a6b8711995c2d466c502af9f3a08bb upstream.

There is a possibility malicious users can get limited information about
uninitialized stack mem array. Even if sk_run_filter() result is bound
to packet length (0 .. 65535), we could imagine this can be used by
hostile user.

Initializing mem[] array, like Dan Rosenberg suggested in his patch is
expensive since most filters dont even use this array.

Its hard to make the filter validation in sk_chk_filter(), because of
the jumps. This might be done later.

In this patch, I use a bitmap (a single long var) so that only filters
using mem[] loads/stores pay the price of added security checks.

For other filters, additional cost is a single instruction.

[ Since we access fentry-&gt;k a lot now, cache it in a local variable
  and mark filter entry pointer as const. -DaveM ]

Reported-by: Dan Rosenberg &lt;drosenberg@vsecurity.com&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 57fe93b374a6b8711995c2d466c502af9f3a08bb upstream.

There is a possibility malicious users can get limited information about
uninitialized stack mem array. Even if sk_run_filter() result is bound
to packet length (0 .. 65535), we could imagine this can be used by
hostile user.

Initializing mem[] array, like Dan Rosenberg suggested in his patch is
expensive since most filters dont even use this array.

Its hard to make the filter validation in sk_chk_filter(), because of
the jumps. This might be done later.

In this patch, I use a bitmap (a single long var) so that only filters
using mem[] loads/stores pay the price of added security checks.

For other filters, additional cost is a single instruction.

[ Since we access fentry-&gt;k a lot now, cache it in a local variable
  and mark filter entry pointer as const. -DaveM ]

Reported-by: Dan Rosenberg &lt;drosenberg@vsecurity.com&gt;
Signed-off-by: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>vlan: Avoid hwaccel vlan packets when vid not used.</title>
<updated>2010-12-09T21:33:29+00:00</updated>
<author>
<name>Jesse Gross</name>
<email>jesse@nicira.com</email>
</author>
<published>2010-11-08T21:23:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1b7cd15c8c89f5c26dc525d985e45c9bd9265fe2'/>
<id>1b7cd15c8c89f5c26dc525d985e45c9bd9265fe2</id>
<content type='text'>
[This patch applies only to 2.6.36 stable.  The problem was introduced
in that release and is already fixed by larger changes to the vlan
code in 2.6.37.]

Normally hardware accelerated vlan packets are quickly dropped if
there is no corresponding vlan device configured.  The one exception
is promiscuous mode, where we allow all of these packets through so
they can be picked up by tcpdump.  However, this behavior causes a
crash if we actually try to receive these packets.  This fixes that
crash by ignoring packets with vids not corresponding to a configured
device in the vlan hwaccel routines and then dropping them before they
get to consumers in the network stack.


Reported-by: Ben Greear &lt;greearb@candelatech.com&gt;
Tested-by: Nikola Ciprich &lt;extmaillist@linuxbox.cz&gt;
Signed-off-by: Jesse Gross &lt;jesse@nicira.com&gt;
Acked-by: David Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[This patch applies only to 2.6.36 stable.  The problem was introduced
in that release and is already fixed by larger changes to the vlan
code in 2.6.37.]

Normally hardware accelerated vlan packets are quickly dropped if
there is no corresponding vlan device configured.  The one exception
is promiscuous mode, where we allow all of these packets through so
they can be picked up by tcpdump.  However, this behavior causes a
crash if we actually try to receive these packets.  This fixes that
crash by ignoring packets with vids not corresponding to a configured
device in the vlan hwaccel routines and then dropping them before they
get to consumers in the network stack.


Reported-by: Ben Greear &lt;greearb@candelatech.com&gt;
Tested-by: Nikola Ciprich &lt;extmaillist@linuxbox.cz&gt;
Signed-off-by: Jesse Gross &lt;jesse@nicira.com&gt;
Acked-by: David Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>net: Limit socket I/O iovec total length to INT_MAX.</title>
<updated>2010-12-09T21:33:28+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2010-10-28T18:41:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8612ab37c065833ad732341a87d2a2502b7a3b03'/>
<id>8612ab37c065833ad732341a87d2a2502b7a3b03</id>
<content type='text'>
commit 8acfe468b0384e834a303f08ebc4953d72fb690a upstream.

This helps protect us from overflow issues down in the
individual protocol sendmsg/recvmsg handlers.  Once
we hit INT_MAX we truncate out the rest of the iovec
by setting the iov_len members to zero.

This works because:

1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial
   writes are allowed and the application will just continue
   with another write to send the rest of the data.

2) For datagram oriented sockets, where there must be a
   one-to-one correspondance between write() calls and
   packets on the wire, INT_MAX is going to be far larger
   than the packet size limit the protocol is going to
   check for and signal with -EMSGSIZE.

Based upon a patch by Linus Torvalds.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8acfe468b0384e834a303f08ebc4953d72fb690a upstream.

This helps protect us from overflow issues down in the
individual protocol sendmsg/recvmsg handlers.  Once
we hit INT_MAX we truncate out the rest of the iovec
by setting the iov_len members to zero.

This works because:

1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial
   writes are allowed and the application will just continue
   with another write to send the rest of the data.

2) For datagram oriented sockets, where there must be a
   one-to-one correspondance between write() calls and
   packets on the wire, INT_MAX is going to be far larger
   than the packet size limit the protocol is going to
   check for and signal with -EMSGSIZE.

Based upon a patch by Linus Torvalds.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>net: NETIF_F_HW_CSUM does not imply FCoE CRC offload</title>
<updated>2010-12-09T21:32:37+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>bhutchings@solarflare.com</email>
</author>
<published>2010-10-22T04:38:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ffe7d99b862d4c70e1eb214605ff7e24e55c547a'/>
<id>ffe7d99b862d4c70e1eb214605ff7e24e55c547a</id>
<content type='text'>
commit 66c68bcc489fadd4f5e8839e966e3a366e50d1d5 upstream.

NETIF_F_HW_CSUM indicates the ability to update an TCP/IP-style 16-bit
checksum with the checksum of an arbitrary part of the packet data,
whereas the FCoE CRC is something entirely different.

Signed-off-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 66c68bcc489fadd4f5e8839e966e3a366e50d1d5 upstream.

NETIF_F_HW_CSUM indicates the ability to update an TCP/IP-style 16-bit
checksum with the checksum of an arbitrary part of the packet data,
whereas the FCoE CRC is something entirely different.

Signed-off-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>net: clear heap allocations for privileged ethtool actions</title>
<updated>2010-10-11T19:23:25+00:00</updated>
<author>
<name>Kees Cook</name>
<email>kees.cook@canonical.com</email>
</author>
<published>2010-10-11T19:23:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b00916b189d13a615ff05c9242201135992fcda3'/>
<id>b00916b189d13a615ff05c9242201135992fcda3</id>
<content type='text'>
Several other ethtool functions leave heap uncleared (potentially) by
drivers. Some interfaces appear safe (eeprom, etc), in that the sizes
are well controlled. In some situations (e.g. unchecked error conditions),
the heap will remain unchanged in areas before copying back to userspace.
Note that these are less of an issue since these all require CAP_NET_ADMIN.

Cc: stable@kernel.org
Signed-off-by: Kees Cook &lt;kees.cook@canonical.com&gt;
Acked-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Several other ethtool functions leave heap uncleared (potentially) by
drivers. Some interfaces appear safe (eeprom, etc), in that the sizes
are well controlled. In some situations (e.g. unchecked error conditions),
the heap will remain unchanged in areas before copying back to userspace.
Note that these are less of an issue since these all require CAP_NET_ADMIN.

Cc: stable@kernel.org
Signed-off-by: Kees Cook &lt;kees.cook@canonical.com&gt;
Acked-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: clear heap allocation for ETHTOOL_GRXCLSRLALL</title>
<updated>2010-10-08T17:48:28+00:00</updated>
<author>
<name>Kees Cook</name>
<email>kees.cook@canonical.com</email>
</author>
<published>2010-10-07T10:03:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ae6df5f96a51818d6376da5307d773baeece4014'/>
<id>ae6df5f96a51818d6376da5307d773baeece4014</id>
<content type='text'>
Calling ETHTOOL_GRXCLSRLALL with a large rule_cnt will allocate kernel
heap without clearing it. For the one driver (niu) that implements it,
it will leave the unused portion of heap unchanged and copy the full
contents back to userspace.

Signed-off-by: Kees Cook &lt;kees.cook@canonical.com&gt;
Acked-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Calling ETHTOOL_GRXCLSRLALL with a large rule_cnt will allocate kernel
heap without clearing it. For the one driver (niu) that implements it,
it will leave the unused portion of heap unchanged and copy the full
contents back to userspace.

Signed-off-by: Kees Cook &lt;kees.cook@canonical.com&gt;
Acked-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
