Re: [PATCH net v5 0/3] nfc: fix remaining OOB bugs in NCI/LLCP parsing

David Heidelberg <[email protected]> Sun, 19 Jul 2026 17:04:19 +0200
Newsgroups dev.linux.lists.oe-linux-nfc,org.kernel.vger.linux-kernel,org.kernel.vger.netdev
Message-ID <[email protected]>
On 16/07/2026 22:35, Lekë Hapçiu wrote:
> Rebased against David's linux-nfc for-linus tree [1], as requested.
> 
> This was originally a 5-patch series. Two of the five (the
> parse_gb_tlv()/parse_connection_tlv() offset-wrap fix and the
> nfc_llcp_recv_snl() TLV bounds fix) have since been fixed independently
> by other contributors already merged into for-linus:
> 
>    d8bd2dedbde5 ("nfc: llcp: fix OOB read and u8 offset wrap in TLV parsers")
>    27256cdb290e ("nfc: llcp: bound SNL TLV parsing to the skb and add length checks")
> 
> Those two are dropped from this series to avoid duplicating work. The
> remaining three patches are unchanged in substance from v4, just
> rebased and renumbered:
> 
>    1/3 (was 1/5) - nci_store_general_bytes_nfc_dep() u8 underflow
>    2/3 (was 4/5) - nfc_llcp_recv_dm() OOB read of the reason byte
>    3/3 (was 5/5) - nfc_llcp_connect_sn() TLV parsing OOB
> 
> All three still reproduce against current for-linus (verified against
> 1671b8fb7300 before rebase). checkpatch --strict is clean on all three.
> 
> [1] https://codeberg.org/linux-nfc/linux.git for-linus
> 
> Lekë Hapçiu (3):
>    nfc: nci: fix u8 underflow in nci_store_general_bytes_nfc_dep
>    nfc: llcp: fix OOB read of DM reason byte in nfc_llcp_recv_dm
>    nfc: llcp: fix TLV parsing OOB in nfc_llcp_connect_sn
> 
>   net/nfc/llcp_core.c | 19 +++++++++++++++++--
>   net/nfc/nci/ntf.c   |  6 ++++++
>   2 files changed, 23 insertions(+), 2 deletions(-)
> 

Hello Lekë,

I'm afraid I won't make you happy here, but after merging the outstanding 
backlog today, I ran into conflicts again with your patch series. I'm very sorry 
about that, but I've been receiving a high number of fixes.

Now that I'm back from the conference, if you send the next revision based on 
the current for-linus / for-next, I believe I'll be able to apply it quickly 
enough to avoid conflicts.

Thank you for your understanding.

David