<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net, branch v3.18.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>Revert "mac80211: Fix accounting of the tailroom-needed counter"</title>
<updated>2015-01-16T14:59:56+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2015-01-05T09:28:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a4a59e5833fb66f7776c4224d41d753aa1ee9fb7'/>
<id>a4a59e5833fb66f7776c4224d41d753aa1ee9fb7</id>
<content type='text'>
commit 1e359a5de861a57aa04d92bb620f52a5c1d7f8b1 upstream.

This reverts commit ca34e3b5c808385b175650605faa29e71e91991b.

It turns out that the p54 and cw2100 drivers assume that there's
tailroom even when they don't say they really need it. However,
there's currently no way for them to explicitly say they do need
it, so for now revert this.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=90331.

Fixes: ca34e3b5c808 ("mac80211: Fix accounting of the tailroom-needed counter")
Reported-by: Christopher Chavez &lt;chrischavez@gmx.us&gt;
Bisected-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Debugged-by: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

This reverts commit ca34e3b5c808385b175650605faa29e71e91991b.

It turns out that the p54 and cw2100 drivers assume that there's
tailroom even when they don't say they really need it. However,
there's currently no way for them to explicitly say they do need
it, so for now revert this.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=90331.

Fixes: ca34e3b5c808 ("mac80211: Fix accounting of the tailroom-needed counter")
Reported-by: Christopher Chavez &lt;chrischavez@gmx.us&gt;
Bisected-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Debugged-by: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>rpc: fix xdr_truncate_encode to handle buffer ending on page boundary</title>
<updated>2015-01-16T14:59:55+00:00</updated>
<author>
<name>J. Bruce Fields</name>
<email>bfields@redhat.com</email>
</author>
<published>2014-12-22T21:14:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9e80aeb7c7244c29b2c28049cd2149d3ab10a56a'/>
<id>9e80aeb7c7244c29b2c28049cd2149d3ab10a56a</id>
<content type='text'>
commit 49a068f82a1d30eb585d7804b05948376be6cf9a upstream.

A struct xdr_stream at a page boundary might point to the end of one
page or the beginning of the next, but xdr_truncate_encode isn't
prepared to handle the former.

This can cause corruption of NFSv4 READDIR replies in the case that a
readdir entry that would have exceeded the client's dircount/maxcount
limit would have ended exactly on a 4k page boundary.  You're more
likely to hit this case on large directories.

Other xdr_truncate_encode callers are probably also affected.

Reported-by: Holger Hoffstätte &lt;holger.hoffstaette@googlemail.com&gt;
Tested-by: Holger Hoffstätte &lt;holger.hoffstaette@googlemail.com&gt;
Fixes: 3e19ce762b53 "rpc: xdr_truncate_encode"
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

A struct xdr_stream at a page boundary might point to the end of one
page or the beginning of the next, but xdr_truncate_encode isn't
prepared to handle the former.

This can cause corruption of NFSv4 READDIR replies in the case that a
readdir entry that would have exceeded the client's dircount/maxcount
limit would have ended exactly on a 4k page boundary.  You're more
likely to hit this case on large directories.

Other xdr_truncate_encode callers are probably also affected.

Reported-by: Holger Hoffstätte &lt;holger.hoffstaette@googlemail.com&gt;
Tested-by: Holger Hoffstätte &lt;holger.hoffstaette@googlemail.com&gt;
Fixes: 3e19ce762b53 "rpc: xdr_truncate_encode"
Signed-off-by: J. Bruce Fields &lt;bfields@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix accepting connections when not using mgmt</title>
<updated>2015-01-16T14:59:47+00:00</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2014-12-24T18:43:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2b81cffdf46dba7685937194a9515310607c6596'/>
<id>2b81cffdf46dba7685937194a9515310607c6596</id>
<content type='text'>
commit 6a8fc95c87110a466ee81675b41170b963f82bdb upstream.

When connectable mode is enabled (page scan on) through some non-mgmt
method the HCI_CONNECTABLE flag will not be set. For backwards
compatibility with user space versions not using mgmt we should not
require HCI_CONNECTABLE to be set if HCI_MGMT is not set.

Reported-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Tested-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

When connectable mode is enabled (page scan on) through some non-mgmt
method the HCI_CONNECTABLE flag will not be set. For backwards
compatibility with user space versions not using mgmt we should not
require HCI_CONNECTABLE to be set if HCI_MGMT is not set.

Reported-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Tested-by: Pali Rohár &lt;pali.rohar@gmail.com&gt;
Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix controller configuration with HCI_QUIRK_INVALID_BDADDR</title>
<updated>2015-01-16T14:59:47+00:00</updated>
<author>
<name>Marcel Holtmann</name>
<email>marcel@holtmann.org</email>
</author>
<published>2014-12-23T22:10:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ad976d1c00c4a34415ce254a942ba6e165f2c9de'/>
<id>ad976d1c00c4a34415ce254a942ba6e165f2c9de</id>
<content type='text'>
commit 8bfe8442ff20fdc2d965c197103d935a99bd3296 upstream.

When controllers set the HCI_QUIRK_INVALID_BDADDR flag, it is required
by userspace to program a valid public Bluetooth device address into
the controller before it can be used.

After successful address configuration, the internal state changes and
the controller runs the complete initialization procedure. However one
small difference is that this is no longer the HCI_SETUP stage. The
HCI_SETUP stage is only valid during initial controller setup. In this
case the stack runs the initialization as part of the HCI_CONFIG stage.

The controller version information, default name and supported commands
are only stored during HCI_SETUP. While these information are static,
they are not read initially when HCI_QUIRK_INVALID_BDADDR is set. So
when running in HCI_CONFIG state, these information need to be updated
as well.

This especially impacts Bluetooth 4.1 and later controllers using
extended feature pages and second event mask page.

Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

When controllers set the HCI_QUIRK_INVALID_BDADDR flag, it is required
by userspace to program a valid public Bluetooth device address into
the controller before it can be used.

After successful address configuration, the internal state changes and
the controller runs the complete initialization procedure. However one
small difference is that this is no longer the HCI_SETUP stage. The
HCI_SETUP stage is only valid during initial controller setup. In this
case the stack runs the initialization as part of the HCI_CONFIG stage.

The controller version information, default name and supported commands
are only stored during HCI_SETUP. While these information are static,
they are not read initially when HCI_QUIRK_INVALID_BDADDR is set. So
when running in HCI_CONFIG state, these information need to be updated
as well.

This especially impacts Bluetooth 4.1 and later controllers using
extended feature pages and second event mask page.

Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Clear LE white list when resetting controller</title>
<updated>2015-01-16T14:59:47+00:00</updated>
<author>
<name>Marcel Holtmann</name>
<email>marcel@holtmann.org</email>
</author>
<published>2014-10-29T22:37:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0de8cd646b0152c9ddd10257d8284938d0df0181'/>
<id>0de8cd646b0152c9ddd10257d8284938d0df0181</id>
<content type='text'>
commit a4d5504d5c39cc84f1f828e19967595597a8136e upstream.

The internal representation of the LE white list needs to be cleared
when receiving a successful HCI_Reset command. A reset of the controller
is expected to start with an empty LE white list.

When the LE white list is not cleared on controller reset, the passive
background scanning might skip programming the remote devices. Only
changes to the LE white list are programmed when passive background
is started.

Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

The internal representation of the LE white list needs to be cleared
when receiving a successful HCI_Reset command. A reset of the controller
is expected to start with an empty LE white list.

When the LE white list is not cleared on controller reset, the passive
background scanning might skip programming the remote devices. Only
changes to the LE white list are programmed when passive background
is started.

Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix check for direct advertising</title>
<updated>2015-01-16T14:59:47+00:00</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2014-10-28T21:23:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=18368232e651470a1dbb2c3504bb274f35b2e3d3'/>
<id>18368232e651470a1dbb2c3504bb274f35b2e3d3</id>
<content type='text'>
commit 0b1db38ca26b322296cbd141f3080eccfe1cc3e1 upstream.

These days we allow simultaneous LE scanning and advertising. Checking
for whether advertising is enabled or not is therefore not a reliable
way to determine whether directed advertising was used to trigger the
connection creation. The appropriate place to check (instead of the hdev
context) is the connection role that's stored in the hci_conn. This
patch fixes such a check in le_conn_timeout() which could otherwise lead
to incorrect HCI commands being sent.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

These days we allow simultaneous LE scanning and advertising. Checking
for whether advertising is enabled or not is therefore not a reliable
way to determine whether directed advertising was used to trigger the
connection creation. The appropriate place to check (instead of the hdev
context) is the connection role that's stored in the hci_conn. This
patch fixes such a check in le_conn_timeout() which could otherwise lead
to incorrect HCI commands being sent.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: Fix LE connection timeout deadlock</title>
<updated>2015-01-16T14:59:47+00:00</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2014-10-28T21:23:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f3d02a6c4f7d683e301d600e0736c09fcb8fa899'/>
<id>f3d02a6c4f7d683e301d600e0736c09fcb8fa899</id>
<content type='text'>
commit 980ffc0a2cec2c37589cc97993e1ad17252f4f47 upstream.

The le_conn_timeout() may call hci_le_conn_failed() which in turn may
call hci_conn_del(). Trying to use the _sync variant for cancelling the
conn timeout from hci_conn_del() could therefore result in a deadlock.
This patch converts hci_conn_del() to use the non-sync variant so the
deadlock is not possible.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

The le_conn_timeout() may call hci_le_conn_failed() which in turn may
call hci_conn_del(). Trying to use the _sync variant for cancelling the
conn timeout from hci_conn_del() could therefore result in a deadlock.
This patch converts hci_conn_del() to use the non-sync variant so the
deadlock is not possible.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: 6lowpan: fix skb_unshare behaviour</title>
<updated>2015-01-16T14:59:47+00:00</updated>
<author>
<name>Alexander Aring</name>
<email>alex.aring@gmail.com</email>
</author>
<published>2014-10-08T08:24:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bff7d3f06a2ff8036e310e2e7a4192c4bed4a9da'/>
<id>bff7d3f06a2ff8036e310e2e7a4192c4bed4a9da</id>
<content type='text'>
commit b0c42cd7b210efc74aa4bfc3e39a2814dfaa9b89 upstream.

This patch reverts commit:

a7807d73 ("Bluetooth: 6lowpan: Avoid memory leak if memory allocation
fails")

which was wrong suggested by Alexander Aring. The function skb_unshare
run also kfree_skb on failure.

Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

This patch reverts commit:

a7807d73 ("Bluetooth: 6lowpan: Avoid memory leak if memory allocation
fails")

which was wrong suggested by Alexander Aring. The function skb_unshare
run also kfree_skb on failure.

Signed-off-by: Alexander Aring &lt;alex.aring@gmail.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: free management frame keys when removing station</title>
<updated>2015-01-08T18:30:23+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2014-12-17T12:55:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9e2a8e62a4c520b78266c2682cec3abde1d4f23e'/>
<id>9e2a8e62a4c520b78266c2682cec3abde1d4f23e</id>
<content type='text'>
commit 28a9bc68124c319b2b3dc861e80828a8865fd1ba upstream.

When writing the code to allow per-station GTKs, I neglected to
take into account the management frame keys (index 4 and 5) when
freeing the station and only added code to free the first four
data frame keys.

Fix this by iterating the array of keys over the right length.

Fixes: e31b82136d1a ("cfg80211/mac80211: allow per-station GTKs")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

When writing the code to allow per-station GTKs, I neglected to
take into account the management frame keys (index 4 and 5) when
freeing the station and only added code to free the first four
data frame keys.

Fix this by iterating the array of keys over the right length.

Fixes: e31b82136d1a ("cfg80211/mac80211: allow per-station GTKs")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix multicast LED blinking and counter</title>
<updated>2015-01-08T18:30:23+00:00</updated>
<author>
<name>Andreas Müller</name>
<email>goo@stapelspeicher.org</email>
</author>
<published>2014-12-12T11:11:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4286afc16688b959e30f77beba0b5607c89a952f'/>
<id>4286afc16688b959e30f77beba0b5607c89a952f</id>
<content type='text'>
commit d025933e29872cb1fe19fc54d80e4dfa4ee5779c upstream.

As multicast-frames can't be fragmented, "dot11MulticastReceivedFrameCount"
stopped being incremented after the use-after-free fix. Furthermore, the
RX-LED will be triggered by every multicast frame (which wouldn't happen
before) which wouldn't allow the LED to rest at all.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=89431 which also had the
patch.

Fixes: b8fff407a180 ("mac80211: fix use-after-free in defragmentation")
Signed-off-by: Andreas Müller &lt;goo@stapelspeicher.org&gt;
[rewrite commit message]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

As multicast-frames can't be fragmented, "dot11MulticastReceivedFrameCount"
stopped being incremented after the use-after-free fix. Furthermore, the
RX-LED will be triggered by every multicast frame (which wouldn't happen
before) which wouldn't allow the LED to rest at all.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=89431 which also had the
patch.

Fixes: b8fff407a180 ("mac80211: fix use-after-free in defragmentation")
Signed-off-by: Andreas Müller &lt;goo@stapelspeicher.org&gt;
[rewrite commit message]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
