<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/nfc/nci/data.c, branch linux-4.14.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.14.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.14.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-12-08T10:16:30Z</updated>
<entry>
<title>NFC: nci: fix memory leak in nci_rx_data_packet()</title>
<updated>2022-12-08T10:16:30Z</updated>
<author>
<name>Liu Shixin</name>
</author>
<published>2022-11-18T08:24:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=03b93946b291ef6ef9b07dff572fb60534c4a3f2'/>
<id>urn:sha1:03b93946b291ef6ef9b07dff572fb60534c4a3f2</id>
<content type='text'>
[ Upstream commit 53270fb0fd77fe786d8c07a0793981d797836b93 ]

Syzbot reported a memory leak about skb:

unreferenced object 0xffff88810e144e00 (size 240):
  comm "syz-executor284", pid 3701, jiffies 4294952403 (age 12.620s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff83ab79a9&gt;] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:497
    [&lt;ffffffff82a5cf64&gt;] alloc_skb include/linux/skbuff.h:1267 [inline]
    [&lt;ffffffff82a5cf64&gt;] virtual_ncidev_write+0x24/0xe0 drivers/nfc/virtual_ncidev.c:116
    [&lt;ffffffff815f6503&gt;] do_loop_readv_writev fs/read_write.c:759 [inline]
    [&lt;ffffffff815f6503&gt;] do_loop_readv_writev fs/read_write.c:743 [inline]
    [&lt;ffffffff815f6503&gt;] do_iter_write+0x253/0x300 fs/read_write.c:863
    [&lt;ffffffff815f66ed&gt;] vfs_writev+0xdd/0x240 fs/read_write.c:934
    [&lt;ffffffff815f68f6&gt;] do_writev+0xa6/0x1c0 fs/read_write.c:977
    [&lt;ffffffff848802d5&gt;] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    [&lt;ffffffff848802d5&gt;] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
    [&lt;ffffffff84a00087&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In nci_rx_data_packet(), if we don't get a valid conn_info, we will return
directly but forget to release the skb.

Reported-by: syzbot+cdb9a427d1bc08815104@syzkaller.appspotmail.com
Fixes: 4aeee6871e8c ("NFC: nci: Add dynamic logical connections support")
Signed-off-by: Liu Shixin &lt;liushixin2@huawei.com&gt;
Link: https://lore.kernel.org/r/20221118082419.239475-1-liushixin2@huawei.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NFC: nci: fix sleep in atomic context bugs caused by nci_skb_alloc</title>
<updated>2022-05-25T06:41:20Z</updated>
<author>
<name>Duoming Zhou</name>
</author>
<published>2022-05-17T01:25:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=732acfaa2cea55b0734b2f451a949a7395c61938'/>
<id>urn:sha1:732acfaa2cea55b0734b2f451a949a7395c61938</id>
<content type='text'>
[ Upstream commit 23dd4581350d4ffa23d58976ec46408f8f4c1e16 ]

There are sleep in atomic context bugs when the request to secure
element of st-nci is timeout. The root cause is that nci_skb_alloc
with GFP_KERNEL parameter is called in st_nci_se_wt_timeout which is
a timer handler. The call paths that could trigger bugs are shown below:

    (interrupt context 1)
st_nci_se_wt_timeout
  nci_hci_send_event
    nci_hci_send_data
      nci_skb_alloc(..., GFP_KERNEL) //may sleep

   (interrupt context 2)
st_nci_se_wt_timeout
  nci_hci_send_event
    nci_hci_send_data
      nci_send_data
        nci_queue_tx_data_frags
          nci_skb_alloc(..., GFP_KERNEL) //may sleep

This patch changes allocation mode of nci_skb_alloc from GFP_KERNEL to
GFP_ATOMIC in order to prevent atomic context sleeping. The GFP_ATOMIC
flag makes memory allocation operation could be used in atomic context.

Fixes: ed06aeefdac3 ("nfc: st-nci: Rename st21nfcb to st-nci")
Signed-off-by: Duoming Zhou &lt;duoming@zju.edu.cn&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@linaro.org&gt;
Link: https://lore.kernel.org/r/20220517012530.75714-1-duoming@zju.edu.cn
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nfc: fix potential illegal memory access</title>
<updated>2019-07-31T05:28:45Z</updated>
<author>
<name>Yang Wei</name>
</author>
<published>2019-07-08T14:57:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d2814b0325b8f048d60ea126a63c4ff49f2d2430'/>
<id>urn:sha1:d2814b0325b8f048d60ea126a63c4ff49f2d2430</id>
<content type='text'>
[ Upstream commit dd006fc434e107ef90f7de0db9907cbc1c521645 ]

The frags_q is not properly initialized, it may result in illegal memory
access when conn_info is NULL.
The "goto free_exit" should be replaced by "goto exit".

Signed-off-by: Yang Wei &lt;albin_yang@163.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>
</entry>
<entry>
<title>networking: make skb_push &amp; __skb_push return void pointers</title>
<updated>2017-06-16T15:48:40Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2017-06-16T12:29:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d58ff35122847a83ba55394e2ae3a1527b6febf5'/>
<id>urn:sha1:d58ff35122847a83ba55394e2ae3a1527b6febf5</id>
<content type='text'>
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.

Make these functions return void * and remove all the casts across
the tree, adding a (u8 *) cast only where the unsigned char pointer
was used directly, all done with the following spatch:

    @@
    expression SKB, LEN;
    typedef u8;
    identifier fn = { skb_push, __skb_push, skb_push_rcsum };
    @@
    - *(fn(SKB, LEN))
    + *(u8 *)fn(SKB, LEN)

    @@
    expression E, SKB, LEN;
    identifier fn = { skb_push, __skb_push, skb_push_rcsum };
    type T;
    @@
    - E = ((T *)(fn(SKB, LEN)))
    + E = fn(SKB, LEN)

    @@
    expression SKB, LEN;
    identifier fn = { skb_push, __skb_push, skb_push_rcsum };
    @@
    - fn(SKB, LEN)[0]
    + *(u8 *)fn(SKB, LEN)

Note that the last part there converts from push(...)[0] to the
more idiomatic *(u8 *)push(...).

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>networking: introduce and use skb_put_data()</title>
<updated>2017-06-16T15:48:37Z</updated>
<author>
<name>Johannes Berg</name>
</author>
<published>2017-06-16T12:29:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=59ae1d127ac0ae404baf414c434ba2651b793f46'/>
<id>urn:sha1:59ae1d127ac0ae404baf414c434ba2651b793f46</id>
<content type='text'>
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.

An spatch similar to the one for skb_put_zero() converts many
of the places using it:

    @@
    identifier p, p2;
    expression len, skb, data;
    type t, t2;
    @@
    (
    -p = skb_put(skb, len);
    +p = skb_put_data(skb, data, len);
    |
    -p = (t)skb_put(skb, len);
    +p = skb_put_data(skb, data, len);
    )
    (
    p2 = (t2)p;
    -memcpy(p2, data, len);
    |
    -memcpy(p, data, len);
    )

    @@
    type t, t2;
    identifier p, p2;
    expression skb, data;
    @@
    t *p;
    ...
    (
    -p = skb_put(skb, sizeof(t));
    +p = skb_put_data(skb, data, sizeof(t));
    |
    -p = (t *)skb_put(skb, sizeof(t));
    +p = skb_put_data(skb, data, sizeof(t));
    )
    (
    p2 = (t2)p;
    -memcpy(p2, data, sizeof(*p));
    |
    -memcpy(p, data, sizeof(*p));
    )

    @@
    expression skb, len, data;
    @@
    -memcpy(skb_put(skb, len), data, len);
    +skb_put_data(skb, data, len);

(again, manually post-processed to retain some comments)

Reviewed-by: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>NFC: nci: Add function to get max packet size for conn</title>
<updated>2015-10-25T18:11:42Z</updated>
<author>
<name>Robert Dolca</name>
</author>
<published>2015-10-22T09:11:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2663589ce67e5429bac89544bb0e102bb1fcf617'/>
<id>urn:sha1:2663589ce67e5429bac89544bb0e102bb1fcf617</id>
<content type='text'>
FDP driver needs to send the firmware as regular packets
(not fragmented). The driver should have a way to
get the max packet size for a given connection.

Signed-off-by: Robert Dolca &lt;robert.dolca@intel.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>NFC: nci: Export nci data send API</title>
<updated>2015-10-25T18:11:35Z</updated>
<author>
<name>Robert Dolca</name>
</author>
<published>2015-10-22T09:11:33Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ea785c094d38bc5eae8011330759d68f45236559'/>
<id>urn:sha1:ea785c094d38bc5eae8011330759d68f45236559</id>
<content type='text'>
For the firmware update the driver may use nci_send_data.

Signed-off-by: Robert Dolca &lt;robert.dolca@intel.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>NFC: nci: Add dynamic logical connections support</title>
<updated>2015-02-02T20:50:31Z</updated>
<author>
<name>Christophe Ricard</name>
</author>
<published>2015-02-01T21:26:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4aeee6871e8c3b043ef02996db8ac70a1af8be92'/>
<id>urn:sha1:4aeee6871e8c3b043ef02996db8ac70a1af8be92</id>
<content type='text'>
The current NCI core only support the RF static connection.
For other NFC features such as Secure Element communication, we
may need to create logical connections to the NFCEE (Execution
Environment.

In order to track each logical connection ID dynamically, we add a
linked list of connection info pointers to the nci_dev structure.

Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>NFC: nci: Add status byte management in case of error.</title>
<updated>2014-12-02T21:46:47Z</updated>
<author>
<name>Christophe Ricard</name>
</author>
<published>2014-12-02T20:27:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=98ff416f97c53b727d6a52f4d2b29bdf4775ac69'/>
<id>urn:sha1:98ff416f97c53b727d6a52f4d2b29bdf4775ac69</id>
<content type='text'>
The nci status byte was ignored. In case of tag reading for example,
if the tag is removed from the antenna there is no way for the upper
layers (aka: stack) to get inform about such event.

Signed-off-by: Christophe Ricard &lt;christophe-h.ricard@st.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
</entry>
<entry>
<title>NFC: NCI: Forward data received in Target mode to nfc core</title>
<updated>2014-11-28T13:07:51Z</updated>
<author>
<name>Julien Lefrique</name>
</author>
<published>2014-10-21T14:52:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=122c195872e963c83f3a61dcab0937247b56786e'/>
<id>urn:sha1:122c195872e963c83f3a61dcab0937247b56786e</id>
<content type='text'>
Signed-off-by: Julien Lefrique &lt;lefrique@marvell.com&gt;
Signed-off-by: Samuel Ortiz &lt;sameo@linux.intel.com&gt;
</content>
</entry>
</feed>
