Re: [PATCH net] nfc: nci: fix out-of-bounds read in activation parameter parsing

Muhammad Bilal <[email protected]> Wed, 8 Jul 2026 20:10:28 +0500
Newsgroups dev.linux.lists.oe-linux-nfc,org.kernel.vger.linux-kernel,org.kernel.vger.netdev
Message-ID <CADqcGBkXtDGMsQ6XWYeUyuS6qL8DCHeTNxzbH3s=22vuvBfZaw@mail.gmail.com>
Hi Simon,

Thanks for the review and the Reviewed-by.

One of the issues raised by the AI review (the NFC-DEP general bytes
handling in nci_store_general_bytes_nfc_dep()) is already addressed by
a separate follow-up patch:

Link: https://lore.kernel.org/all/20260628214929.135152-1-meatuni001@gmail.=
com/

The remaining AI-raised points are independent of this fix and can be
investigated separately if they prove to be valid.

On Wed, Jul 8, 2026 at 6:07=E2=80=AFPM Simon Horman <[email protected]> wrot=
e:
>
> On Mon, Jun 29, 2026 at 02:00:26AM +0500, Muhammad Bilal wrote:
> > nci_extract_activation_params_iso_dep() and
> > nci_extract_activation_params_nfc_dep() receive a pointer into the
> > RF_INTF_ACTIVATED_NTF notification but are not told how many bytes
> > remain.  Each reads a one-byte length field (rats_res_len,
> > attrib_res_len, atr_res_len or atr_req_len) and then memcpy()s that man=
y
> > bytes from the packet.  The length is clamped to the destination size,
> > but it is never checked against the remaining activation-parameter data=
,
> > so a notification whose length field is larger than the data present
> > reads past the end of the buffer.
> >
> > The sibling nci_extract_rf_params_*() helpers were recently given a
> > data_len argument and matching remaining-length checks, but the
> > activation-parameter helpers were not updated.
> >
> > Pass the remaining length down and validate each field against it befor=
e
> > copying, as the rf_params helpers do.
> >
> > Fixes: ac2068384034 ("NFC: Parse NCI NFC-DEP activation params")
> > Cc: [email protected]
> > Signed-off-by: Muhammad Bilal <[email protected]>
>
> Reviewed-by: Simon Horman <[email protected]>
>
> FTR, there is an AI-=3Dgenerated review of this patch on sashiko.dev.
> However, I think that the issues raised there can be treated
> as possible follow-up rather than impeding the progress of this patch.