<feed xmlns='http://www.w3.org/2005/Atom'>
<title>talos-obmc-linux/net/bluetooth, branch dev-5.0</title>
<subtitle>Talos™ II Linux sources for OpenBMC</subtitle>
<id>https://git.raptorcs.com/git/talos-obmc-linux/atom?h=dev-5.0</id>
<link rel='self' href='https://git.raptorcs.com/git/talos-obmc-linux/atom?h=dev-5.0'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/'/>
<updated>2019-04-03T04:27:22+00:00</updated>
<entry>
<title>Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer</title>
<updated>2019-04-03T04:27:22+00:00</updated>
<author>
<name>Marcel Holtmann</name>
<email>marcel@holtmann.org</email>
</author>
<published>2019-01-18T12:43:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=a556547bae00528f24b42786b41a14047db14b84'/>
<id>urn:sha1:a556547bae00528f24b42786b41a14047db14b84</id>
<content type='text'>
commit 7c9cbd0b5e38a1672fcd137894ace3b042dfbf69 upstream.

The function l2cap_get_conf_opt will return L2CAP_CONF_OPT_SIZE + opt-&gt;len
as length value. The opt-&gt;len however is in control over the remote user
and can be used by an attacker to gain access beyond the bounds of the
actual packet.

To prevent any potential leak of heap memory, it is enough to check that
the resulting len calculation after calling l2cap_get_conf_opt is not
below zero. A well formed packet will always return &gt;= 0 here and will
end with the length value being zero after the last option has been
parsed. In case of malformed packets messing with the opt-&gt;len field the
length value will become negative. If that is the case, then just abort
and ignore the option.

In case an attacker uses a too short opt-&gt;len value, then garbage will
be parsed, but that is protected by the unknown option handling and also
the option parameter size checks.

Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.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>
</entry>
<entry>
<title>Bluetooth: Check L2CAP option sizes returned from l2cap_get_conf_opt</title>
<updated>2019-04-03T04:27:22+00:00</updated>
<author>
<name>Marcel Holtmann</name>
<email>marcel@holtmann.org</email>
</author>
<published>2019-01-18T11:56:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=8dac9b8d27b504734429cb0be541425a216ccba2'/>
<id>urn:sha1:8dac9b8d27b504734429cb0be541425a216ccba2</id>
<content type='text'>
commit af3d5d1c87664a4f150fcf3534c6567cb19909b0 upstream.

When doing option parsing for standard type values of 1, 2 or 4 octets,
the value is converted directly into a variable instead of a pointer. To
avoid being tricked into being a pointer, check that for these option
types that sizes actually match. In L2CAP every option is fixed size and
thus it is prudent anyway to ensure that the remote side sends us the
right option size along with option paramters.

If the option size is not matching the option type, then that option is
silently ignored. It is a protocol violation and instead of trying to
give the remote attacker any further hints just pretend that option is
not present and proceed with the default values. Implementation
following the specification and its qualification procedures will always
use the correct size and thus not being impacted here.

To keep the code readable and consistent accross all options, a few
cosmetic changes were also required.

Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.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>
</entry>
<entry>
<title>Bluetooth: Fix decrementing reference count twice in releasing socket</title>
<updated>2019-03-27T05:17:57+00:00</updated>
<author>
<name>Myungho Jung</name>
<email>mhjungk@gmail.com</email>
</author>
<published>2019-02-03T00:56:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=4d18023ade55906b1e1f4983f59082f747499778'/>
<id>urn:sha1:4d18023ade55906b1e1f4983f59082f747499778</id>
<content type='text'>
commit e20a2e9c42c9e4002d9e338d74e7819e88d77162 upstream.

When releasing socket, it is possible to enter hci_sock_release() and
hci_sock_dev_event(HCI_DEV_UNREG) at the same time in different thread.
The reference count of hdev should be decremented only once from one of
them but if storing hdev to local variable in hci_sock_release() before
detached from socket and setting to NULL in hci_sock_dev_event(),
hci_dev_put(hdev) is unexpectedly called twice. This is resolved by
referencing hdev from socket after bt_sock_unlink() in
hci_sock_release().

Reported-by: syzbot+fdc00003f4efff43bc5b@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung &lt;mhjungk@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>
</entry>
<entry>
<title>Bluetooth: Fix locking in bt_accept_enqueue() for BH context</title>
<updated>2019-03-10T06:09:01+00:00</updated>
<author>
<name>Matthias Kaehlcke</name>
<email>mka@chromium.org</email>
</author>
<published>2019-01-03T00:11:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=bc60931448e779c1f5650f7e0a27d2569df57841'/>
<id>urn:sha1:bc60931448e779c1f5650f7e0a27d2569df57841</id>
<content type='text'>
commit c4f5627f7eeecde1bb6b646d8c0907b96dc2b2a6 upstream.

With commit e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket
atomically") lock_sock[_nested]() is used to acquire the socket lock
before manipulating the socket. lock_sock[_nested]() may block, which
is problematic since bt_accept_enqueue() can be called in bottom half
context (e.g. from rfcomm_connect_ind()):

[&lt;ffffff80080d81ec&gt;] __might_sleep+0x4c/0x80
[&lt;ffffff800876c7b0&gt;] lock_sock_nested+0x24/0x58
[&lt;ffffff8000d7c27c&gt;] bt_accept_enqueue+0x48/0xd4 [bluetooth]
[&lt;ffffff8000e67d8c&gt;] rfcomm_connect_ind+0x190/0x218 [rfcomm]

Add a parameter to bt_accept_enqueue() to indicate whether the
function is called from BH context, and acquire the socket lock
with bh_lock_sock_nested() if that's the case.

Also adapt all callers of bt_accept_enqueue() to pass the new
parameter:

- l2cap_sock_new_connection_cb()
  - uses lock_sock() to lock the parent socket =&gt; process context

- rfcomm_connect_ind()
  - acquires the parent socket lock with bh_lock_sock() =&gt; BH
    context

- __sco_chan_add()
  - called from sco_chan_add(), which is called from sco_connect().
    parent is NULL, hence bt_accept_enqueue() isn't called in this
    code path and we can ignore it
  - also called from sco_conn_ready(). uses bh_lock_sock() to acquire
    the parent lock =&gt; BH context

Fixes: e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket atomically")
Signed-off-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Reviewed-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6</title>
<updated>2018-12-27T21:53:32+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-12-27T21:53:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=b71acb0e372160167bf6d5500b88b30b52ccef6e'/>
<id>urn:sha1:b71acb0e372160167bf6d5500b88b30b52ccef6e</id>
<content type='text'>
Pull crypto updates from Herbert Xu:
 "API:
   - Add 1472-byte test to tcrypt for IPsec
   - Reintroduced crypto stats interface with numerous changes
   - Support incremental algorithm dumps

  Algorithms:
   - Add xchacha12/20
   - Add nhpoly1305
   - Add adiantum
   - Add streebog hash
   - Mark cts(cbc(aes)) as FIPS allowed

  Drivers:
   - Improve performance of arm64/chacha20
   - Improve performance of x86/chacha20
   - Add NEON-accelerated nhpoly1305
   - Add SSE2 accelerated nhpoly1305
   - Add AVX2 accelerated nhpoly1305
   - Add support for 192/256-bit keys in gcmaes AVX
   - Add SG support in gcmaes AVX
   - ESN for inline IPsec tx in chcr
   - Add support for CryptoCell 703 in ccree
   - Add support for CryptoCell 713 in ccree
   - Add SM4 support in ccree
   - Add SM3 support in ccree
   - Add support for chacha20 in caam/qi2
   - Add support for chacha20 + poly1305 in caam/jr
   - Add support for chacha20 + poly1305 in caam/qi2
   - Add AEAD cipher support in cavium/nitrox"

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (130 commits)
  crypto: skcipher - remove remnants of internal IV generators
  crypto: cavium/nitrox - Fix build with !CONFIG_DEBUG_FS
  crypto: salsa20-generic - don't unnecessarily use atomic walk
  crypto: skcipher - add might_sleep() to skcipher_walk_virt()
  crypto: x86/chacha - avoid sleeping under kernel_fpu_begin()
  crypto: cavium/nitrox - Added AEAD cipher support
  crypto: mxc-scc - fix build warnings on ARM64
  crypto: api - document missing stats member
  crypto: user - remove unused dump functions
  crypto: chelsio - Fix wrong error counter increments
  crypto: chelsio - Reset counters on cxgb4 Detach
  crypto: chelsio - Handle PCI shutdown event
  crypto: chelsio - cleanup:send addr as value in function argument
  crypto: chelsio - Use same value for both channel in single WR
  crypto: chelsio - Swap location of AAD and IV sent in WR
  crypto: chelsio - remove set but not used variable 'kctx_len'
  crypto: ux500 - Use proper enum in hash_set_dma_transfer
  crypto: ux500 - Use proper enum in cryp_set_dma_transfer
  crypto: aesni - Add scatter/gather avx stubs, and use them in C
  crypto: aesni - Introduce partial block macro
  ..
</content>
</entry>
<entry>
<title>Bluetooth: Fix unnecessary error message for HCI request completion</title>
<updated>2018-12-19T13:37:03+00:00</updated>
<author>
<name>Johan Hedberg</name>
<email>johan.hedberg@intel.com</email>
</author>
<published>2018-11-27T09:37:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=1629db9c75342325868243d6bca5853017d91cf8'/>
<id>urn:sha1:1629db9c75342325868243d6bca5853017d91cf8</id>
<content type='text'>
In case a command which completes in Command Status was sent using the
hci_cmd_send-family of APIs there would be a misleading error in the
hci_get_cmd_complete function, since the code would be trying to fetch
the Command Complete parameters when there are none.

Avoid the misleading error and silently bail out from the function in
case the received event is a command status.

Signed-off-by: Johan Hedberg &lt;johan.hedberg@intel.com&gt;
Acked-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: clean an indentation issue, remove extraneous space</title>
<updated>2018-12-18T23:44:01+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2018-11-09T13:27:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=75edd1f2f916f06248cd6a6e8ea706b44431d3eb'/>
<id>urn:sha1:75edd1f2f916f06248cd6a6e8ea706b44431d3eb</id>
<content type='text'>
Trivial fix to clean up an indentation issue

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>Bluetooth: Change to use DEFINE_SHOW_ATTRIBUTE macro</title>
<updated>2018-12-18T23:28:20+00:00</updated>
<author>
<name>Yangtao Li</name>
<email>tiny.windzz@gmail.com</email>
</author>
<published>2018-11-05T14:56:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=8e2924e383b714748e5891ac9ff2f5c945666891'/>
<id>urn:sha1:8e2924e383b714748e5891ac9ff2f5c945666891</id>
<content type='text'>
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Yangtao Li &lt;tiny.windzz@gmail.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
</content>
</entry>
<entry>
<title>net: core: dev: Add extack argument to dev_open()</title>
<updated>2018-12-06T21:26:06+00:00</updated>
<author>
<name>Petr Machata</name>
<email>petrm@mellanox.com</email>
</author>
<published>2018-12-06T17:05:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=00f54e68924eaf075f3f24be18557899d347bc4a'/>
<id>urn:sha1:00f54e68924eaf075f3f24be18557899d347bc4a</id>
<content type='text'>
In order to pass extack together with NETDEV_PRE_UP notifications, it's
necessary to route the extack to __dev_open() from diverse (possibly
indirect) callers. One prominent API through which the notification is
invoked is dev_open().

Therefore extend dev_open() with and extra extack argument and update
all users. Most of the calls end up just encoding NULL, but bond and
team drivers have the extack readily available.

Signed-off-by: Petr Machata &lt;petrm@mellanox.com&gt;
Acked-by: Jiri Pirko &lt;jiri@mellanox.com&gt;
Reviewed-by: Ido Schimmel &lt;idosch@mellanox.com&gt;
Reviewed-by: David Ahern &lt;dsahern@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>crypto: drop mask=CRYPTO_ALG_ASYNC from 'shash' tfm allocations</title>
<updated>2018-11-20T06:26:55+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2018-11-14T20:21:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/talos-obmc-linux/commit/?id=3d234b3313cd12157946522fe35f5a4574f31169'/>
<id>urn:sha1:3d234b3313cd12157946522fe35f5a4574f31169</id>
<content type='text'>
'shash' algorithms are always synchronous, so passing CRYPTO_ALG_ASYNC
in the mask to crypto_alloc_shash() has no effect.  Many users therefore
already don't pass it, but some still do.  This inconsistency can cause
confusion, especially since the way the 'mask' argument works is
somewhat counterintuitive.

Thus, just remove the unneeded CRYPTO_ALG_ASYNC flags.

This patch shouldn't change any actual behavior.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
</entry>
</feed>
