<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/next/linux-next.git/drivers/nfc, branch master</title>
<subtitle>The linux-next integration testing tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/'/>
<updated>2026-08-28T12:34:49+00:00</updated>
<entry>
<title>Merge branch 'for-linus' of https://codeberg.org/linux-nfc/linux.git</title>
<updated>2026-08-28T12:34:49+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2026-08-28T12:34:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c7398d8634178c26a5139226444b44d4cd7407dc'/>
<id>urn:sha1:c7398d8634178c26a5139226444b44d4cd7407dc</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2026-08-18T17:42:41+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2026-08-18T17:42:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=61eb236c41c2a4717015dff18016a75a5eb90052'/>
<id>urn:sha1:61eb236c41c2a4717015dff18016a75a5eb90052</id>
<content type='text'>
Merge in late fixes in preparation for the net-next PR.

Conflicts:

drivers/dpll/dpll_core.c
drivers/dpll/dpll_netlink.c
  33f016b23a219 ("dpll: fix NULL deref in dpll_device_ops() during teardown race")
  b1d0c412088e3 ("dpll: add STATE_CONNECTED_OVERRIDE pin capability")
https://lore.kernel.org/aoR9YYY2P5--3x0N@sirena.org.uk
https://lore.kernel.org/aoR9VmKllVGwmQn_@sirena.org.uk

No adjacent changes.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>nfc: port100: reject frames whose declared length exceeds the received data</title>
<updated>2026-08-17T17:27:51+00:00</updated>
<author>
<name>Doruk Tan Ozturk</name>
<email>doruk@0sec.ai</email>
</author>
<published>2026-07-11T12:36:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5c0f3a8d40f8a68a7d3f768c1f7a4cd111ff4879'/>
<id>urn:sha1:5c0f3a8d40f8a68a7d3f768c1f7a4cd111ff4879</id>
<content type='text'>
port100_recv_response() passes the URB transfer buffer to
port100_rx_frame_is_valid(), which checksums le16_to_cpu(frame-&gt;datalen)
bytes of frame-&gt;data. datalen is a 16-bit field supplied by the device
and is never checked against the number of bytes actually received
(urb-&gt;actual_length), so a device reporting a datalen larger than the
received frame makes port100_data_checksum() read out of bounds past the
transfer buffer.

Reject a response whose declared frame size does not fit the received
length before validating it.

Found by 0sec (https://0sec.ai) using automated source analysis; the
missing bound is evident from source. Compile-tested.

Fixes: 562d4d59b8a1 ("NFC: Sony Port-100 Series driver")
Cc: stable@vger.kernel.org
Assisted-by: 0sec:claude-opus-4-8
Signed-off-by: Doruk Tan Ozturk &lt;doruk@0sec.ai&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://patch.msgid.link/20260711123651.32595-1-doruk@0sec.ai
Signed-off-by: David Heidelberg &lt;david@ixit.cz&gt;
</content>
</entry>
<entry>
<title>nfc: st21nfca: validate received frame size</title>
<updated>2026-08-17T17:27:50+00:00</updated>
<author>
<name>Pengpeng Hou</name>
<email>pengpeng@iscas.ac.cn</email>
</author>
<published>2026-07-15T08:44:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ff825ed2b74983453ec851d1a7053dd3576d7667'/>
<id>urn:sha1:ff825ed2b74983453ec851d1a7053dd3576d7667</id>
<content type='text'>
st21nfca_hci_i2c_repack() trims a received frame at its EOF marker
before removing byte stuffing.  It then assumes the truncated frame
contains the LLC header and two CRC bytes, and it unconditionally reads
the byte after an escape marker.

A malformed frame can place EOF immediately after the start marker or can
end its data portion with an escape marker.  The former leaves too few
bytes for check_crc(), while the latter makes the unstuffing loop read past
the current skb length.

Require the minimum framing bytes both before and after unstuffing.  Use
separate input and output cursors while removing byte stuffing, and reject
an escape marker without its encoded byte.  This keeps malformed frames
within the received frame boundary before CRC processing.

Fixes: 3096e25a3e40 ("NFC: st21nfca: Fix incorrect byte stuffing revocation")
Signed-off-by: Pengpeng Hou &lt;pengpeng@iscas.ac.cn&gt;
Link: https://patch.msgid.link/20260715084405.41546-1-pengpeng@iscas.ac.cn
Signed-off-by: David Heidelberg &lt;david@ixit.cz&gt;
</content>
</entry>
<entry>
<title>nfc: nfcmrvl: validate helper command length before pull</title>
<updated>2026-08-17T17:27:50+00:00</updated>
<author>
<name>Pengpeng Hou</name>
<email>pengpeng@iscas.ac.cn</email>
</author>
<published>2026-07-15T08:43:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=831cfb7ba99e99f4106d2e933f565c7f72bbe5c6'/>
<id>urn:sha1:831cfb7ba99e99f4106d2e933f565c7f72bbe5c6</id>
<content type='text'>
The firmware download receive path removes the NCI data header and
reads the helper command before validating the remaining packet length.
A short frame can therefore reach the data access before the malformed
packet is rejected.

Validate the complete helper command length before stripping the NCI
data header.

Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
Signed-off-by: Pengpeng Hou &lt;pengpeng@iscas.ac.cn&gt;
Link: https://patch.msgid.link/20260715084325.40276-1-pengpeng@iscas.ac.cn
Signed-off-by: David Heidelberg &lt;david@ixit.cz&gt;
</content>
</entry>
<entry>
<title>nfc: microread: validate target discovery payload lengths</title>
<updated>2026-08-17T17:27:50+00:00</updated>
<author>
<name>Pengpeng Hou</name>
<email>pengpeng@iscas.ac.cn</email>
</author>
<published>2026-07-23T02:37:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4108ab8dffc555a154df143d21508eb9e9658f53'/>
<id>urn:sha1:4108ab8dffc555a154df143d21508eb9e9658f53</id>
<content type='text'>
microread_target_discovered() parses target discovery payloads from
skb-&gt;data according to the HCI gate. The fixed field offsets and UID
copies were checked only against the destination nfc_target buffers, not
against the actual skb length.

Validate that each gate-specific payload contains the fixed fields and
UID bytes before reading or copying them.

Fixes: cfad1ba87150 ("NFC: Initial support for Inside Secure microread")
Cc: stable@vger.kernel.org
Signed-off-by: Pengpeng Hou &lt;pengpeng@iscas.ac.cn&gt;
Link: https://patch.msgid.link/20260723103508.1-microread-v2-pengpeng@iscas.ac.cn
Signed-off-by: David Heidelberg &lt;david@ixit.cz&gt;
</content>
</entry>
<entry>
<title>nfc: pn533: purge fragmented skbs during cleanup</title>
<updated>2026-08-17T17:27:50+00:00</updated>
<author>
<name>Xu Rao</name>
<email>raoxu@uniontech.com</email>
</author>
<published>2026-07-20T02:14:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5644560f08dd018b10abecbd971a7dd4ab540d81'/>
<id>urn:sha1:5644560f08dd018b10abecbd971a7dd4ab540d81</id>
<content type='text'>
pn53x_common_clean() purges resp_q before freeing the common PN533 state,
but it leaves fragment_skb untouched.  The fragmentation helpers queue
transmit fragments there while sending large initiator or target-mode
frames, and those skbs remain owned by the driver until they are sent or
discarded.

If the device is removed while fragments are still queued, the common
cleanup path frees the PN533 state without releasing the queued fragment
skbs, leaking them.

Purge fragment_skb during cleanup alongside resp_q.

Fixes: 963a82e07d4e ("NFC: pn533: Split large Tx frames in chunks")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Rao &lt;raoxu@uniontech.com&gt;
Link: https://patch.msgid.link/2D896607CAE4408E+20260720021444.3362044-1-raoxu@uniontech.com
Signed-off-by: David Heidelberg &lt;david@ixit.cz&gt;
</content>
</entry>
<entry>
<title>nfc: st21nfca: validate ATR_REQ length against the received frame</title>
<updated>2026-08-17T17:27:50+00:00</updated>
<author>
<name>Doruk Tan Ozturk</name>
<email>doruk@0sec.ai</email>
</author>
<published>2026-07-11T07:13:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c1e561d3bf658edfa095985c56a45019ad182585'/>
<id>urn:sha1:c1e561d3bf658edfa095985c56a45019ad182585</id>
<content type='text'>
st21nfca_tm_recv_atr_req() checks that the received ATR_REQ frame is at
least ST21NFCA_ATR_REQ_MIN_SIZE and that the self-declared atr_req-&gt;length
is at least sizeof(struct st21nfca_atr_req), but never checks that
atr_req-&gt;length does not exceed the actual received length (skb-&gt;len).

st21nfca_tm_send_atr_res() then trusts the declared length:

	gb_len = atr_req-&gt;length - sizeof(struct st21nfca_atr_req);
	...
	memcpy(atr_res-&gt;gbi, atr_req-&gt;gbi, gb_len);

so an RF peer that sends a short frame but sets atr_req-&gt;length larger
than the frame makes gb_len exceed the general bytes actually present,
and the memcpy reads out of bounds past the received skb. Those bytes are
placed in the ATR_RES and sent back to the peer (kernel-memory disclosure
to a proximity attacker); a larger declared length is an out-of-bounds
read (DoS).

Reject frames whose declared length exceeds the received length. The
adjacent nfc_tm_activated() path in the same function already derives its
general-bytes length from skb-&gt;len rather than the declared field.

Found by 0sec (https://0sec.ai) using automated source analysis; the
missing bound is evident from source. Compile-tested.

Fixes: 1892bf844ea0 ("NFC: st21nfca: Adding P2P support to st21nfca in Initiator &amp; Target mode")
Cc: stable@vger.kernel.org
Assisted-by: 0sec:claude-opus-4-8
Signed-off-by: Doruk Tan Ozturk &lt;doruk@0sec.ai&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://patch.msgid.link/20260711071301.58071-1-doruk@0sec.ai
Signed-off-by: David Heidelberg &lt;david@ixit.cz&gt;
</content>
</entry>
<entry>
<title>nfc: pn533: hold a reference to the request skb during send_frame</title>
<updated>2026-08-17T17:27:49+00:00</updated>
<author>
<name>Yinhao Hu</name>
<email>dddddd@hust.edu.cn</email>
</author>
<published>2026-06-26T07:34:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4b992fb2ce3e7bb394b3d57e2bf22928e70cfb83'/>
<id>urn:sha1:4b992fb2ce3e7bb394b3d57e2bf22928e70cfb83</id>
<content type='text'>
__pn533_send_async() publishes the command and then calls
dev-&gt;phy_ops-&gt;send_frame(). Once dev-&gt;cmd is set, an incoming frame
can be matched to this command: the I2C threaded IRQ runs
pn533_recv_frame(), which queues cmd_complete_work, and
pn533_send_async_complete() frees cmd-&gt;req with consume_skb().

On the I2C transport, pn533_i2c_send_frame() still dereferences the same
skb after i2c_master_send() returns, so a completion that races the
send can free the skb while the transport is still using it.

The request skb is owned by the command object and may be freed by
command completion at any time after dev-&gt;cmd is published, so the
transport send path must not assume it stays alive. Hold a temporary
reference to the request skb across the send_frame() call so the
transport always sees a live skb even if completion races the send.
Add a pn533_send_cmd_frame() helper and use it from all three send
paths.

Fixes: 9815c7cf22da ("NFC: pn533: Separate physical layer from the core implementation")
Signed-off-by: Yinhao Hu &lt;dddddd@hust.edu.cn&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://patch.msgid.link/20260626073434.3977525-1-dddddd@hust.edu.cn
Signed-off-by: David Heidelberg &lt;david@ixit.cz&gt;
</content>
</entry>
<entry>
<title>nfc: fdp: bound the device-reported read length and fix an skb leak</title>
<updated>2026-08-17T17:27:49+00:00</updated>
<author>
<name>Bryam Vargas</name>
<email>hexlabsecurity@proton.me</email>
</author>
<published>2026-06-17T04:33:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=1e3a87ee69b0b41dcc617622dac8ba595183eaad'/>
<id>urn:sha1:1e3a87ee69b0b41dcc617622dac8ba595183eaad</id>
<content type='text'>
fdp_nci_i2c_read() takes the next packet length from two device-supplied
bytes and never validates it. The value is a u16 used as the
i2c_master_recv() count into a 261-byte on-stack buffer: a malicious,
counterfeit or malfunctioning controller (or an i2c bus interposer) can
drive it far past the buffer for a stack out-of-bounds write that
clobbers the canary and return address, or below the minimum frame size
(directly, or by truncating the computed sum) so the header/LRC strip
and the next length read run past a short receive. Reject a length
outside [FDP_NCI_I2C_MIN_PAYLOAD, FDP_NCI_I2C_MAX_PAYLOAD], as a
corrupted packet already is, and force resynchronization.

The same loop allocates one data skb per iteration and assumes a length
packet followed by a data packet; a device that sends two data packets
in one call leaks the first skb when the second allocation overwrites
it. Free a previously allocated skb before allocating the next.

Fixes: a06347c04c13 ("NFC: Add Intel Fields Peak NFC solution driver")
Cc: stable@vger.kernel.org
Suggested-by: Simon Horman &lt;horms@kernel.org&gt;
Signed-off-by: Bryam Vargas &lt;hexlabsecurity@proton.me&gt;
Link: https://patch.msgid.link/20260616-b4-disp-b1f8ab4c-v2-1-2d1fe5955325@proton.me
Signed-off-by: David Heidelberg &lt;david@ixit.cz&gt;
</content>
</entry>
</feed>
