Re: [REGRESSION] NFC broken on Thinkpad T14 Gen since 9c328f5

[Lukas K.]

On 06.02.26 17:24, Thorsten Leemhuis wrote:
> On 2/6/26 16:15, Lukas K. wrote:
> > from 6.17.2 to 6.17.3, the integrated NFC reader (driver: nxp-nci_i2c)
> > in the Thinkpad T14 Gen 4 (AMD) stopped detecting tags. This can be
> > tested by running
> >
> > sudo nfctool -1 -p -d nfc0
> >
> > Looking at the commits between 6.17.2 and 6.17.3, 9c328f5 (net: nfc:
> > nci: Add parameter validation for packet data) was the only one related
> > to NFC.
> >
> > To see if that commit indeed was the culprit, I reverted it on 6.18.7
> > and nfctool is detecting tags again.
> >
> > Since the offending commit merely adds some bounds checks, the root
> > cause may very well be in another driver in the NFC stack.
>
> Thx for the report. Seems Michael (now CCed) also ran into problems and
> tried to fix them, but looks like that effort stalled; but might be good
> to know if this fixes your problem, too:
>
> https://lore.kernel.org/all/20260112124819.171028-1-michael.thalmeier@xxxxxxx/

Hi Thorsten,

thanks for the pointer. Tried the patch you linked to and it works for me.

Don't know how to reply to the linked mail as I'm new to LKML, but one 
thing caught my eye:

> static const __u8 *
> nci_extract_rf_params_nfca_passive_poll(struct nci_dev *ndev,
>                                        struct 
rf_tech_specific_params_nfca_poll *nfca_poll,
>-                                       const __u8 *data)
>+                                       const __u8 *data, size_t data_len)
> {
>+       /* Check if we have enough data for sens_res (2 bytes) */
>+       if (data_len < 2)
>+               return ERR_PTR(-EINVAL);
>+
>        nfca_poll->sens_res = __le16_to_cpu(*((__le16 *)data));
>        data += 2;
>+       data_len -= 2;
>+
>+       /* Check if we have enough data for nfcid1_len (1 byte) */
>+       if (data_len < 1)
>+               return ERR_PTR(-EINVAL);

If data_len underflows at any point it'll wrap to some large value and 
the less than comparisons will yield an incorrect result. Using ssize_t 
should fix that.

Best Regards,

Lukas