Re: [PATCH net] nfc: st21nfca: validate ATR_REQ length against the received frame

From: Simon Horman

Date: Thu Jul 16 2026 - 12:06:17 EST


On Sat, Jul 11, 2026 at 09:13:01AM +0200, Doruk Tan Ozturk wrote:
> 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->length
> is at least sizeof(struct st21nfca_atr_req), but never checks that
> atr_req->length does not exceed the actual received length (skb->len).
>
> st21nfca_tm_send_atr_res() then trusts the declared length:
>
> gb_len = atr_req->length - sizeof(struct st21nfca_atr_req);
> ...
> memcpy(atr_res->gbi, atr_req->gbi, gb_len);
>
> so an RF peer that sends a short frame but sets atr_req->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->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 & Target mode")
> Cc: stable@xxxxxxxxxxxxxxx
> Assisted-by: 0sec:claude-opus-4-8
> Signed-off-by: Doruk Tan Ozturk <doruk@xxxxxxx>

Reviewed-by: Simon Horman <horms@xxxxxxxxxx>

FTR, the AI-generated review of this patch on sashiko.dev does seem to
raise legitimate pre-existing issues which relate closely to this patch.
But I think they can be treated as potential follow-up rather than impeding
progress of this patch.