<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/net/nfc, branch v5.4.164</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>NFC: add NCI_UNREG flag to eliminate the race</title>
<updated>2021-12-01T08:23:35+00:00</updated>
<author>
<name>Lin Ma</name>
<email>linma@zju.edu.cn</email>
</author>
<published>2021-11-16T15:27:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=eff32973ecc3838d9a6dc5174bd24d76b120843c'/>
<id>eff32973ecc3838d9a6dc5174bd24d76b120843c</id>
<content type='text'>
commit 48b71a9e66c2eab60564b1b1c85f4928ed04e406 upstream.

There are two sites that calls queue_work() after the
destroy_workqueue() and lead to possible UAF.

The first site is nci_send_cmd(), which can happen after the
nci_close_device as below

nfcmrvl_nci_unregister_dev   |  nfc_genl_dev_up
  nci_close_device           |
    flush_workqueue          |
    del_timer_sync           |
  nci_unregister_device      |    nfc_get_device
    destroy_workqueue        |    nfc_dev_up
    nfc_unregister_device    |      nci_dev_up
      device_del             |        nci_open_device
                             |          __nci_request
                             |            nci_send_cmd
                             |              queue_work !!!

Another site is nci_cmd_timer, awaked by the nci_cmd_work from the
nci_send_cmd.

  ...                        |  ...
  nci_unregister_device      |  queue_work
    destroy_workqueue        |
    nfc_unregister_device    |  ...
      device_del             |  nci_cmd_work
                             |  mod_timer
                             |  ...
                             |  nci_cmd_timer
                             |    queue_work !!!

For the above two UAF, the root cause is that the nfc_dev_up can race
between the nci_unregister_device routine. Therefore, this patch
introduce NCI_UNREG flag to easily eliminate the possible race. In
addition, the mutex_lock in nci_close_device can act as a barrier.

Signed-off-by: Lin Ma &lt;linma@zju.edu.cn&gt;
Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
Reviewed-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Link: https://lore.kernel.org/r/20211116152732.19238-1-linma@zju.edu.cn
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.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 48b71a9e66c2eab60564b1b1c85f4928ed04e406 upstream.

There are two sites that calls queue_work() after the
destroy_workqueue() and lead to possible UAF.

The first site is nci_send_cmd(), which can happen after the
nci_close_device as below

nfcmrvl_nci_unregister_dev   |  nfc_genl_dev_up
  nci_close_device           |
    flush_workqueue          |
    del_timer_sync           |
  nci_unregister_device      |    nfc_get_device
    destroy_workqueue        |    nfc_dev_up
    nfc_unregister_device    |      nci_dev_up
      device_del             |        nci_open_device
                             |          __nci_request
                             |            nci_send_cmd
                             |              queue_work !!!

Another site is nci_cmd_timer, awaked by the nci_cmd_work from the
nci_send_cmd.

  ...                        |  ...
  nci_unregister_device      |  queue_work
    destroy_workqueue        |
    nfc_unregister_device    |  ...
      device_del             |  nci_cmd_work
                             |  mod_timer
                             |  ...
                             |  nci_cmd_timer
                             |    queue_work !!!

For the above two UAF, the root cause is that the nfc_dev_up can race
between the nci_unregister_device routine. Therefore, this patch
introduce NCI_UNREG flag to easily eliminate the possible race. In
addition, the mutex_lock in nci_close_device can act as a barrier.

Signed-off-by: Lin Ma &lt;linma@zju.edu.cn&gt;
Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
Reviewed-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Link: https://lore.kernel.org/r/20211116152732.19238-1-linma@zju.edu.cn
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NFC: reorder the logic in nfc_{un,}register_device</title>
<updated>2021-11-26T09:47:20+00:00</updated>
<author>
<name>Lin Ma</name>
<email>linma@zju.edu.cn</email>
</author>
<published>2021-11-16T15:26:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=307d2e6cebfca9d92f86c8e2c8e3dd4a8be46ba6'/>
<id>307d2e6cebfca9d92f86c8e2c8e3dd4a8be46ba6</id>
<content type='text'>
[ Upstream commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 ]

There is a potential UAF between the unregistration routine and the NFC
netlink operations.

The race that cause that UAF can be shown as below:

 (FREE)                      |  (USE)
nfcmrvl_nci_unregister_dev   |  nfc_genl_dev_up
  nci_close_device           |
  nci_unregister_device      |    nfc_get_device
    nfc_unregister_device    |    nfc_dev_up
      rfkill_destory         |
      device_del             |      rfkill_blocked
  ...                        |    ...

The root cause for this race is concluded below:
1. The rfkill_blocked (USE) in nfc_dev_up is supposed to be placed after
the device_is_registered check.
2. Since the netlink operations are possible just after the device_add
in nfc_register_device, the nfc_dev_up() can happen anywhere during the
rfkill creation process, which leads to data race.

This patch reorder these actions to permit
1. Once device_del is finished, the nfc_dev_up cannot dereference the
rfkill object.
2. The rfkill_register need to be placed after the device_add of nfc_dev
because the parent device need to be created first. So this patch keeps
the order but inject device_lock to prevent the data race.

Signed-off-by: Lin Ma &lt;linma@zju.edu.cn&gt;
Fixes: be055b2f89b5 ("NFC: RFKILL support")
Reviewed-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Link: https://lore.kernel.org/r/20211116152652.19217-1-linma@zju.edu.cn
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3e3b5dfcd16a3e254aab61bd1e8c417dd4503102 ]

There is a potential UAF between the unregistration routine and the NFC
netlink operations.

The race that cause that UAF can be shown as below:

 (FREE)                      |  (USE)
nfcmrvl_nci_unregister_dev   |  nfc_genl_dev_up
  nci_close_device           |
  nci_unregister_device      |    nfc_get_device
    nfc_unregister_device    |    nfc_dev_up
      rfkill_destory         |
      device_del             |      rfkill_blocked
  ...                        |    ...

The root cause for this race is concluded below:
1. The rfkill_blocked (USE) in nfc_dev_up is supposed to be placed after
the device_is_registered check.
2. Since the netlink operations are possible just after the device_add
in nfc_register_device, the nfc_dev_up() can happen anywhere during the
rfkill creation process, which leads to data race.

This patch reorder these actions to permit
1. Once device_del is finished, the nfc_dev_up cannot dereference the
rfkill object.
2. The rfkill_register need to be placed after the device_add of nfc_dev
because the parent device need to be created first. So this patch keeps
the order but inject device_lock to prevent the data race.

Signed-off-by: Lin Ma &lt;linma@zju.edu.cn&gt;
Fixes: be055b2f89b5 ("NFC: RFKILL support")
Reviewed-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Link: https://lore.kernel.org/r/20211116152652.19217-1-linma@zju.edu.cn
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NFC: reorganize the functions in nci_request</title>
<updated>2021-11-26T09:47:20+00:00</updated>
<author>
<name>Lin Ma</name>
<email>linma@zju.edu.cn</email>
</author>
<published>2021-11-15T14:56:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=e418bb556ff801e11592851fd465415757a2ef68'/>
<id>e418bb556ff801e11592851fd465415757a2ef68</id>
<content type='text'>
[ Upstream commit 86cdf8e38792545161dbe3350a7eced558ba4d15 ]

There is a possible data race as shown below:

thread-A in nci_request()       | thread-B in nci_close_device()
                                | mutex_lock(&amp;ndev-&gt;req_lock);
test_bit(NCI_UP, &amp;ndev-&gt;flags); |
...                             | test_and_clear_bit(NCI_UP, &amp;ndev-&gt;flags)
mutex_lock(&amp;ndev-&gt;req_lock);    |
                                |

This race will allow __nci_request() to be awaked while the device is
getting removed.

Similar to commit e2cb6b891ad2 ("bluetooth: eliminate the potential race
condition when removing the HCI controller"). this patch alters the
function sequence in nci_request() to prevent the data races between the
nci_close_device().

Signed-off-by: Lin Ma &lt;linma@zju.edu.cn&gt;
Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
Link: https://lore.kernel.org/r/20211115145600.8320-1-linma@zju.edu.cn
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 86cdf8e38792545161dbe3350a7eced558ba4d15 ]

There is a possible data race as shown below:

thread-A in nci_request()       | thread-B in nci_close_device()
                                | mutex_lock(&amp;ndev-&gt;req_lock);
test_bit(NCI_UP, &amp;ndev-&gt;flags); |
...                             | test_and_clear_bit(NCI_UP, &amp;ndev-&gt;flags)
mutex_lock(&amp;ndev-&gt;req_lock);    |
                                |

This race will allow __nci_request() to be awaked while the device is
getting removed.

Similar to commit e2cb6b891ad2 ("bluetooth: eliminate the potential race
condition when removing the HCI controller"). this patch alters the
function sequence in nci_request() to prevent the data races between the
nci_close_device().

Signed-off-by: Lin Ma &lt;linma@zju.edu.cn&gt;
Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
Link: https://lore.kernel.org/r/20211115145600.8320-1-linma@zju.edu.cn
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nfc: nci: fix the UAF of rf_conn_info object</title>
<updated>2021-10-27T07:54:28+00:00</updated>
<author>
<name>Lin Ma</name>
<email>linma@zju.edu.cn</email>
</author>
<published>2021-10-07T17:44:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1f75f8883b4fe9fe1856d71f055120315e758188'/>
<id>1f75f8883b4fe9fe1856d71f055120315e758188</id>
<content type='text'>
commit 1b1499a817c90fd1ce9453a2c98d2a01cca0e775 upstream.

The nci_core_conn_close_rsp_packet() function will release the conn_info
with given conn_id. However, it needs to set the rf_conn_info to NULL to
prevent other routines like nci_rf_intf_activated_ntf_packet() to trigger
the UAF.

Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: Lin Ma &lt;linma@zju.edu.cn&gt;
Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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 1b1499a817c90fd1ce9453a2c98d2a01cca0e775 upstream.

The nci_core_conn_close_rsp_packet() function will release the conn_info
with given conn_id. However, it needs to set the rf_conn_info to NULL to
prevent other routines like nci_rf_intf_activated_ntf_packet() to trigger
the UAF.

Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: Lin Ma &lt;linma@zju.edu.cn&gt;
Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NFC: digital: fix possible memory leak in digital_in_send_sdd_req()</title>
<updated>2021-10-20T09:40:16+00:00</updated>
<author>
<name>Ziyang Xuan</name>
<email>william.xuanziyang@huawei.com</email>
</author>
<published>2021-10-13T07:50:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2bde4aca56db9fe25405d39ddb062531493a65db'/>
<id>2bde4aca56db9fe25405d39ddb062531493a65db</id>
<content type='text'>
commit 291c932fc3692e4d211a445ba8aa35663831bac7 upstream.

'skb' is allocated in digital_in_send_sdd_req(), but not free when
digital_in_send_cmd() failed, which will cause memory leak. Fix it
by freeing 'skb' if digital_in_send_cmd() return failed.

Fixes: 2c66daecc409 ("NFC Digital: Add NFC-A technology support")
Signed-off-by: Ziyang Xuan &lt;william.xuanziyang@huawei.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.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 291c932fc3692e4d211a445ba8aa35663831bac7 upstream.

'skb' is allocated in digital_in_send_sdd_req(), but not free when
digital_in_send_cmd() failed, which will cause memory leak. Fix it
by freeing 'skb' if digital_in_send_cmd() return failed.

Fixes: 2c66daecc409 ("NFC Digital: Add NFC-A technology support")
Signed-off-by: Ziyang Xuan &lt;william.xuanziyang@huawei.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NFC: digital: fix possible memory leak in digital_tg_listen_mdaa()</title>
<updated>2021-10-20T09:40:16+00:00</updated>
<author>
<name>Ziyang Xuan</name>
<email>william.xuanziyang@huawei.com</email>
</author>
<published>2021-10-13T07:50:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=7ab488d7228a9dceb2456867f1f0919decf6efed'/>
<id>7ab488d7228a9dceb2456867f1f0919decf6efed</id>
<content type='text'>
commit 58e7dcc9ca29c14e44267a4d0ea61e3229124907 upstream.

'params' is allocated in digital_tg_listen_mdaa(), but not free when
digital_send_cmd() failed, which will cause memory leak. Fix it by
freeing 'params' if digital_send_cmd() return failed.

Fixes: 1c7a4c24fbfd ("NFC Digital: Add target NFC-DEP support")
Signed-off-by: Ziyang Xuan &lt;william.xuanziyang@huawei.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.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 58e7dcc9ca29c14e44267a4d0ea61e3229124907 upstream.

'params' is allocated in digital_tg_listen_mdaa(), but not free when
digital_send_cmd() failed, which will cause memory leak. Fix it by
freeing 'params' if digital_send_cmd() return failed.

Fixes: 1c7a4c24fbfd ("NFC Digital: Add target NFC-DEP support")
Signed-off-by: Ziyang Xuan &lt;william.xuanziyang@huawei.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nfc: fix error handling of nfc_proto_register()</title>
<updated>2021-10-20T09:40:16+00:00</updated>
<author>
<name>Ziyang Xuan</name>
<email>william.xuanziyang@huawei.com</email>
</author>
<published>2021-10-13T03:49:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=69b3a13f0d082c5b90cd36f31fc8149d1d2d8489'/>
<id>69b3a13f0d082c5b90cd36f31fc8149d1d2d8489</id>
<content type='text'>
commit 0911ab31896f0e908540746414a77dd63912748d upstream.

When nfc proto id is using, nfc_proto_register() return -EBUSY error
code, but forgot to unregister proto. Fix it by adding proto_unregister()
in the error handling case.

Fixes: c7fe3b52c128 ("NFC: add NFC socket family")
Signed-off-by: Ziyang Xuan &lt;william.xuanziyang@huawei.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Link: https://lore.kernel.org/r/20211013034932.2833737-1-william.xuanziyang@huawei.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.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 0911ab31896f0e908540746414a77dd63912748d upstream.

When nfc proto id is using, nfc_proto_register() return -EBUSY error
code, but forgot to unregister proto. Fix it by adding proto_unregister()
in the error handling case.

Fixes: c7fe3b52c128 ("NFC: add NFC socket family")
Signed-off-by: Ziyang Xuan &lt;william.xuanziyang@huawei.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Link: https://lore.kernel.org/r/20211013034932.2833737-1-william.xuanziyang@huawei.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net/nfc/rawsock.c: fix a permission check bug</title>
<updated>2021-06-16T09:59:33+00:00</updated>
<author>
<name>Jeimon</name>
<email>jjjinmeng.zhou@gmail.com</email>
</author>
<published>2021-05-08T03:52:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f3ed12af6bbbaf79eddb0ae14656b8ecacea74f0'/>
<id>f3ed12af6bbbaf79eddb0ae14656b8ecacea74f0</id>
<content type='text'>
[ Upstream commit 8ab78863e9eff11910e1ac8bcf478060c29b379e ]

The function rawsock_create() calls a privileged function sk_alloc(), which requires a ns-aware check to check net-&gt;user_ns, i.e., ns_capable(). However, the original code checks the init_user_ns using capable(). So we replace the capable() with ns_capable().

Signed-off-by: Jeimon &lt;jjjinmeng.zhou@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 8ab78863e9eff11910e1ac8bcf478060c29b379e ]

The function rawsock_create() calls a privileged function sk_alloc(), which requires a ns-aware check to check net-&gt;user_ns, i.e., ns_capable(). However, the original code checks the init_user_ns using capable(). So we replace the capable() with ns_capable().

Signed-off-by: Jeimon &lt;jjjinmeng.zhou@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect</title>
<updated>2021-06-10T11:37:12+00:00</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>krzysztof.kozlowski@canonical.com</email>
</author>
<published>2021-05-31T07:21:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=5d4c4b06ed9fb7a69d0b2e2a73fc73226d25ab70'/>
<id>5d4c4b06ed9fb7a69d0b2e2a73fc73226d25ab70</id>
<content type='text'>
commit 4ac06a1e013cf5fdd963317ffd3b968560f33bba upstream.

It's possible to trigger NULL pointer dereference by local unprivileged
user, when calling getsockname() after failed bind() (e.g. the bind
fails because LLCP_SAP_MAX used as SAP):

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  CPU: 1 PID: 426 Comm: llcp_sock_getna Not tainted 5.13.0-rc2-next-20210521+ #9
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014
  Call Trace:
   llcp_sock_getname+0xb1/0xe0
   __sys_getpeername+0x95/0xc0
   ? lockdep_hardirqs_on_prepare+0xd5/0x180
   ? syscall_enter_from_user_mode+0x1c/0x40
   __x64_sys_getpeername+0x11/0x20
   do_syscall_64+0x36/0x70
   entry_SYSCALL_64_after_hwframe+0x44/0xae

This can be reproduced with Syzkaller C repro (bind followed by
getpeername):
https://syzkaller.appspot.com/x/repro.c?x=14def446e00000

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: d646960f7986 ("NFC: Initial LLCP support")
Reported-by: syzbot+80fb126e7f7d8b1a5914@syzkaller.appspotmail.com
Reported-by: butt3rflyh4ck &lt;butterflyhuangxx@gmail.com&gt;
Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Link: https://lore.kernel.org/r/20210531072138.5219-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.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 4ac06a1e013cf5fdd963317ffd3b968560f33bba upstream.

It's possible to trigger NULL pointer dereference by local unprivileged
user, when calling getsockname() after failed bind() (e.g. the bind
fails because LLCP_SAP_MAX used as SAP):

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  CPU: 1 PID: 426 Comm: llcp_sock_getna Not tainted 5.13.0-rc2-next-20210521+ #9
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1 04/01/2014
  Call Trace:
   llcp_sock_getname+0xb1/0xe0
   __sys_getpeername+0x95/0xc0
   ? lockdep_hardirqs_on_prepare+0xd5/0x180
   ? syscall_enter_from_user_mode+0x1c/0x40
   __x64_sys_getpeername+0x11/0x20
   do_syscall_64+0x36/0x70
   entry_SYSCALL_64_after_hwframe+0x44/0xae

This can be reproduced with Syzkaller C repro (bind followed by
getpeername):
https://syzkaller.appspot.com/x/repro.c?x=14def446e00000

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: d646960f7986 ("NFC: Initial LLCP support")
Reported-by: syzbot+80fb126e7f7d8b1a5914@syzkaller.appspotmail.com
Reported-by: butt3rflyh4ck &lt;butterflyhuangxx@gmail.com&gt;
Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Link: https://lore.kernel.org/r/20210531072138.5219-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>NFC: nci: fix memory leak in nci_allocate_device</title>
<updated>2021-05-28T11:10:27+00:00</updated>
<author>
<name>Dongliang Mu</name>
<email>mudongliangabcd@gmail.com</email>
</author>
<published>2021-05-14T23:29:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=af2a4426baf71163c0c354580ae98c7888a9aba7'/>
<id>af2a4426baf71163c0c354580ae98c7888a9aba7</id>
<content type='text'>
commit e0652f8bb44d6294eeeac06d703185357f25d50b upstream.

nfcmrvl_disconnect fails to free the hci_dev field in struct nci_dev.
Fix this by freeing hci_dev in nci_free_device.

BUG: memory leak
unreferenced object 0xffff888111ea6800 (size 1024):
  comm "kworker/1:0", pid 19, jiffies 4294942308 (age 13.580s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff  .........`......
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;000000004bc25d43&gt;] kmalloc include/linux/slab.h:552 [inline]
    [&lt;000000004bc25d43&gt;] kzalloc include/linux/slab.h:682 [inline]
    [&lt;000000004bc25d43&gt;] nci_hci_allocate+0x21/0xd0 net/nfc/nci/hci.c:784
    [&lt;00000000c59cff92&gt;] nci_allocate_device net/nfc/nci/core.c:1170 [inline]
    [&lt;00000000c59cff92&gt;] nci_allocate_device+0x10b/0x160 net/nfc/nci/core.c:1132
    [&lt;00000000006e0a8e&gt;] nfcmrvl_nci_register_dev+0x10a/0x1c0 drivers/nfc/nfcmrvl/main.c:153
    [&lt;000000004da1b57e&gt;] nfcmrvl_probe+0x223/0x290 drivers/nfc/nfcmrvl/usb.c:345
    [&lt;00000000d506aed9&gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [&lt;00000000bc632c92&gt;] really_probe+0x159/0x4a0 drivers/base/dd.c:554
    [&lt;00000000f5009125&gt;] driver_probe_device+0x84/0x100 drivers/base/dd.c:740
    [&lt;000000000ce658ca&gt;] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846
    [&lt;000000007067d05f&gt;] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431
    [&lt;00000000f8e13372&gt;] __device_attach+0x122/0x250 drivers/base/dd.c:914
    [&lt;000000009cf68860&gt;] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491
    [&lt;00000000359c965a&gt;] device_add+0x5be/0xc30 drivers/base/core.c:3109
    [&lt;00000000086e4bd3&gt;] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164
    [&lt;00000000ca036872&gt;] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
    [&lt;00000000d40d36f6&gt;] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
    [&lt;00000000bc632c92&gt;] really_probe+0x159/0x4a0 drivers/base/dd.c:554

Reported-by: syzbot+19bcfc64a8df1318d1c3@syzkaller.appspotmail.com
Fixes: 11f54f228643 ("NFC: nci: Add HCI over NCI protocol support")
Signed-off-by: Dongliang Mu &lt;mudongliangabcd@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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 e0652f8bb44d6294eeeac06d703185357f25d50b upstream.

nfcmrvl_disconnect fails to free the hci_dev field in struct nci_dev.
Fix this by freeing hci_dev in nci_free_device.

BUG: memory leak
unreferenced object 0xffff888111ea6800 (size 1024):
  comm "kworker/1:0", pid 19, jiffies 4294942308 (age 13.580s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 60 fd 0c 81 88 ff ff  .........`......
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;000000004bc25d43&gt;] kmalloc include/linux/slab.h:552 [inline]
    [&lt;000000004bc25d43&gt;] kzalloc include/linux/slab.h:682 [inline]
    [&lt;000000004bc25d43&gt;] nci_hci_allocate+0x21/0xd0 net/nfc/nci/hci.c:784
    [&lt;00000000c59cff92&gt;] nci_allocate_device net/nfc/nci/core.c:1170 [inline]
    [&lt;00000000c59cff92&gt;] nci_allocate_device+0x10b/0x160 net/nfc/nci/core.c:1132
    [&lt;00000000006e0a8e&gt;] nfcmrvl_nci_register_dev+0x10a/0x1c0 drivers/nfc/nfcmrvl/main.c:153
    [&lt;000000004da1b57e&gt;] nfcmrvl_probe+0x223/0x290 drivers/nfc/nfcmrvl/usb.c:345
    [&lt;00000000d506aed9&gt;] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
    [&lt;00000000bc632c92&gt;] really_probe+0x159/0x4a0 drivers/base/dd.c:554
    [&lt;00000000f5009125&gt;] driver_probe_device+0x84/0x100 drivers/base/dd.c:740
    [&lt;000000000ce658ca&gt;] __device_attach_driver+0xee/0x110 drivers/base/dd.c:846
    [&lt;000000007067d05f&gt;] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431
    [&lt;00000000f8e13372&gt;] __device_attach+0x122/0x250 drivers/base/dd.c:914
    [&lt;000000009cf68860&gt;] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491
    [&lt;00000000359c965a&gt;] device_add+0x5be/0xc30 drivers/base/core.c:3109
    [&lt;00000000086e4bd3&gt;] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2164
    [&lt;00000000ca036872&gt;] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
    [&lt;00000000d40d36f6&gt;] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
    [&lt;00000000bc632c92&gt;] really_probe+0x159/0x4a0 drivers/base/dd.c:554

Reported-by: syzbot+19bcfc64a8df1318d1c3@syzkaller.appspotmail.com
Fixes: 11f54f228643 ("NFC: nci: Add HCI over NCI protocol support")
Signed-off-by: Dongliang Mu &lt;mudongliangabcd@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
