<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/net, branch v3.0.12</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/net?h=v3.0.12</id>
<link rel='self' href='https://git.amat.us/linux/atom/net?h=v3.0.12'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2011-11-26T17:09:55Z</updated>
<entry>
<title>ip6_tunnel: copy parms.name after register_netdevice</title>
<updated>2011-11-26T17:09:55Z</updated>
<author>
<name>Josh Boyer</name>
<email>jwboyer@redhat.com</email>
</author>
<published>2011-11-10T15:10:23Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d11d8cff78f91d5b956975b5c9e4c271e15f864e'/>
<id>urn:sha1:d11d8cff78f91d5b956975b5c9e4c271e15f864e</id>
<content type='text'>
commit 731abb9cb27aef6013ce60808a04e04a545f3f4e upstream.

Commit 1c5cae815d removed an explicit call to dev_alloc_name in ip6_tnl_create
because register_netdevice will now create a valid name.  This works for the
net_device itself.

However the tunnel keeps a copy of the name in the parms structure for the
ip6_tnl associated with the tunnel.  parms.name is set by copying the net_device
name in ip6_tnl_dev_init_gen.  That function is called from ip6_tnl_dev_init in
ip6_tnl_create, but it is done before register_netdevice is called so the name
is set to a bogus value in the parms.name structure.

This shows up if you do a simple tunnel add, followed by a tunnel show:

[root@localhost ~]# ip -6 tunnel add remote fec0::100 local fec0::200
[root@localhost ~]# ip -6 tunnel show
ip6tnl0: ipv6/ipv6 remote :: local :: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
ip6tnl%d: ipv6/ipv6 remote fec0::100 local fec0::200 encaplimit 4 hoplimit 64 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000)
[root@localhost ~]#

Fix this by moving the strcpy out of ip6_tnl_dev_init_gen, and calling it after
register_netdevice has successfully returned.

Signed-off-by: Josh Boyer &lt;jwboyer@redhat.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>
</entry>
<entry>
<title>cfg80211: fix bug on regulatory core exit on access to last_request</title>
<updated>2011-11-26T17:09:55Z</updated>
<author>
<name>Luis R. Rodriguez</name>
<email>mcgrof@qca.qualcomm.com</email>
</author>
<published>2011-11-08T22:28:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5c02e3ae0a16cfc2fb86549cca9898ead2b0d666'/>
<id>urn:sha1:5c02e3ae0a16cfc2fb86549cca9898ead2b0d666</id>
<content type='text'>
commit 58ebacc66bd11be2327edcefc79de94bd6f5bb4a upstream.

Commit 4d9d88d1 by Scott James Remnant &lt;keybuk@google.com&gt; added
the .uevent() callback for the regulatory device used during
the platform device registration. The change was done to account
for queuing up udev change requests through udevadm triggers.
The change also meant that upon regulatory core exit we will now
send a uevent() but the uevent() callback, reg_device_uevent(),
also accessed last_request. Right before commiting device suicide
we free'd last_request but never set it to NULL so
platform_device_unregister() would lead to bogus kernel paging
request. Fix this and also simply supress uevents right before
we commit suicide as they are pointless.

This fix is required for kernels &gt;= v2.6.39

$ git describe --contains 4d9d88d1
v2.6.39-rc1~468^2~25^2^2~21

The impact of not having this present is that a bogus paging
access may occur (only read) upon cfg80211 unload time. You
may also get this BUG complaint below. Although Johannes
could not reproduce the issue this fix is theoretically correct.

mac80211_hwsim: unregister radios
mac80211_hwsim: closing netlink
BUG: unable to handle kernel paging request at ffff88001a06b5ab
IP: [&lt;ffffffffa030df9a&gt;] reg_device_uevent+0x1a/0x50 [cfg80211]
PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0
Modules linked in: cfg80211(-) [last unloaded: mac80211]

Pid: 2279, comm: rmmod Tainted: G        W   3.1.0-wl+ #663 Bochs Bochs
RIP: 0010:[&lt;ffffffffa030df9a&gt;]  [&lt;ffffffffa030df9a&gt;] reg_device_uevent+0x1a/0x50 [cfg80211]
RSP: 0000:ffff88001c5f9d58  EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc
RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0
RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0
R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001
FS:  00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780)
Stack:
 ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2
 000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820
 ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189
Call Trace:
 [&lt;ffffffff812ff7e5&gt;] dev_uevent+0xc5/0x170
 [&lt;ffffffff81241dc7&gt;] kobject_uevent_env+0x1f7/0x490
 [&lt;ffffffff81040189&gt;] ? sub_preempt_count+0x29/0x60
 [&lt;ffffffff814cab1a&gt;] ? _raw_spin_unlock_irqrestore+0x4a/0x90
 [&lt;ffffffff81305307&gt;] ? devres_release_all+0x27/0x60
 [&lt;ffffffff8124206b&gt;] kobject_uevent+0xb/0x10
 [&lt;ffffffff812fee27&gt;] device_del+0x157/0x1b0
 [&lt;ffffffff8130377d&gt;] platform_device_del+0x1d/0x90
 [&lt;ffffffff81303b76&gt;] platform_device_unregister+0x16/0x30
 [&lt;ffffffffa030fffd&gt;] regulatory_exit+0x5d/0x180 [cfg80211]
 [&lt;ffffffffa032bec3&gt;] cfg80211_exit+0x2b/0x45 [cfg80211]
 [&lt;ffffffff8109a84c&gt;] sys_delete_module+0x16c/0x220
 [&lt;ffffffff8108a23e&gt;] ? trace_hardirqs_on_caller+0x7e/0x120
 [&lt;ffffffff814cba02&gt;] system_call_fastpath+0x16/0x1b
Code: &lt;all your base are belong to me&gt;
RIP  [&lt;ffffffffa030df9a&gt;] reg_device_uevent+0x1a/0x50 [cfg80211]
 RSP &lt;ffff88001c5f9d58&gt;
CR2: ffff88001a06b5ab
---[ end trace 147c5099a411e8c0 ]---

Reported-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Cc: Scott James Remnant &lt;keybuk@google.com&gt;
Signed-off-by: Luis R. Rodriguez &lt;mcgrof@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>nl80211: fix HT capability attribute validation</title>
<updated>2011-11-26T17:09:55Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-11-03T08:27:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c1ce1705eb0778927a0b81a6eb29e8ff193aa3de'/>
<id>urn:sha1:c1ce1705eb0778927a0b81a6eb29e8ff193aa3de</id>
<content type='text'>
commit 6c7394197af90f6a332180e33f5d025d3037d883 upstream.

Since the NL80211_ATTR_HT_CAPABILITY attribute is
used as a struct, it needs a minimum, not maximum
length. Enforce that properly. Not doing so could
potentially lead to reading after the buffer.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>mac80211: fix bug in ieee80211_build_probe_req</title>
<updated>2011-11-26T17:09:54Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-11-08T12:04:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ae1e9df381d5197015356e22de9d7acaf646a9ab'/>
<id>urn:sha1:ae1e9df381d5197015356e22de9d7acaf646a9ab</id>
<content type='text'>
commit 5b2bbf75a24d6b06afff6de0eb4819413fd81971 upstream.

ieee80211_probereq_get() can return NULL in
which case we should clean up &amp; return NULL
in ieee80211_build_probe_req() as well.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>mac80211: fix NULL dereference in radiotap code</title>
<updated>2011-11-26T17:09:54Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-11-08T11:28:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=492d7eff2def54c6e5521ee82764ca22025e7030'/>
<id>urn:sha1:492d7eff2def54c6e5521ee82764ca22025e7030</id>
<content type='text'>
commit f8d1ccf15568268c76f913b45ecdd33134387f1a upstream.

When receiving failed PLCP frames is enabled, there
won't be a rate pointer when we add the radiotap
header and thus the kernel will crash. Fix this by
not assuming the rate pointer is always valid. It's
still always valid for frames that have good PLCP
though, and that is checked &amp; enforced.

This was broken by my
commit fc88518916793af8ad6a02e05ff254d95c36d875
Author: Johannes Berg &lt;johannes.berg@intel.com&gt;
Date:   Fri Jul 30 13:23:12 2010 +0200

    mac80211: don't check rates on PLCP error frames

where I removed the check in this case but didn't
take into account that the rate info would be used.

Reported-by: Xiaokang Qin &lt;xiaokang.qin@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>net: Handle different key sizes between address families in flow cache</title>
<updated>2011-11-11T17:37:17Z</updated>
<author>
<name>dpward</name>
<email>david.ward@ll.mit.edu</email>
</author>
<published>2011-09-05T16:47:24Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3fa57c1bf5fb311544199b7837a08b9f5bf5e6e4'/>
<id>urn:sha1:3fa57c1bf5fb311544199b7837a08b9f5bf5e6e4</id>
<content type='text'>
commit aa1c366e4febc7f5c2b84958a2dd7cd70e28f9d0 upstream.

With the conversion of struct flowi to a union of AF-specific structs, some
operations on the flow cache need to account for the exact size of the key.

Signed-off-by: David Ward &lt;david.ward@ll.mit.edu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Cc: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>mac80211: disable powersave for broken APs</title>
<updated>2011-11-11T17:37:13Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2011-10-28T09:59:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=041f9e20b7f794fd7b4932e05d0c938a9ebbf658'/>
<id>urn:sha1:041f9e20b7f794fd7b4932e05d0c938a9ebbf658</id>
<content type='text'>
commit 05cb91085760ca378f28fc274fbf77fc4fd9886c upstream.

Only AID values 1-2007 are valid, but some APs have been
found to send random bogus values, in the reported case an
AP that was sending the AID field value 0xffff, an AID of
0x3fff (16383).

There isn't much we can do but disable powersave since
there's no way it can work properly in this case.

Reported-by: Bill C Riemers &lt;briemers@redhat.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>mac80211: config hw when going back on-channel</title>
<updated>2011-11-11T17:37:12Z</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2011-10-20T17:05:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=42c6d01ce89d43598fc804cf7c141d3252fe93b5'/>
<id>urn:sha1:42c6d01ce89d43598fc804cf7c141d3252fe93b5</id>
<content type='text'>
commit 6911bf0453e0d6ea8eb694a4ce67a68d071c538e upstream.

When going back on-channel, we should reconfigure
the hw iff the hardware is not already configured
to the operational channel.

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>mac80211: fix remain_off_channel regression</title>
<updated>2011-11-11T17:37:12Z</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2011-10-20T17:05:49Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=632abf8b3f714da01daec2d43ffd9cd7b47f53a9'/>
<id>urn:sha1:632abf8b3f714da01daec2d43ffd9cd7b47f53a9</id>
<content type='text'>
commit eaa7af2ae582c9a8c51b374c48d5970b748a5ce2 upstream.

The offchannel code is currently broken - we should
remain_off_channel if the work was started, and
the work's channel and channel_type are the same
as local-&gt;tmp_channel and local-&gt;tmp_channel_type.

However, if wk-&gt;chan_type and local-&gt;tmp_channel_type
coexist (e.g. have the same channel type), we won't
remain_off_channel.

This behavior was introduced by commit da2fd1f
("mac80211: Allow work items to use existing
channel type.")

Tested-by: Ben Greear &lt;greearb@candelatech.com&gt;
Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>NFS/sunrpc: don't use a credential with extra groups.</title>
<updated>2011-11-11T17:37:07Z</updated>
<author>
<name>NeilBrown</name>
<email>neilb@suse.de</email>
</author>
<published>2011-10-24T23:25:49Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6fa9e3e3e01b8741eead6e00bb968ef3b4fddc3f'/>
<id>urn:sha1:6fa9e3e3e01b8741eead6e00bb968ef3b4fddc3f</id>
<content type='text'>
commit dc6f55e9f8dac4b6479be67c5c9128ad37bb491f upstream.

The sunrpc layer keeps a cache of recently used credentials and
'unx_match' is used to find the credential which matches the current
process.

However unx_match allows a match when the cached credential has extra
groups at the end of uc_gids list which are not in the process group list.

So if a process with a list of (say) 4 group accesses a file and gains
access because of the last group in the list, then another process
with the same uid and gid, and a gid list being the first tree of the
gids of the original process tries to access the file, it will be
granted access even though it shouldn't as the wrong rpc credential
will be used.

Signed-off-by: NeilBrown &lt;neilb@suse.de&gt;
Signed-off-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
</feed>
