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.