All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Doruk Tan Ozturk <doruk@0sec.ai>
Cc: David Heidelberg <david@ixit.cz>,
	oe-linux-nfc@lists.linux.dev, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH net] nfc: st21nfca: validate ATR_REQ length against the received frame
Date: Thu, 16 Jul 2026 15:58:46 +0100	[thread overview]
Message-ID: <20260716145846.GM95246@horms.kernel.org> (raw)
In-Reply-To: <20260711071301.58071-1-doruk@0sec.ai>

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@vger.kernel.org
> Assisted-by: 0sec:claude-opus-4-8
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>

Reviewed-by: Simon Horman <horms@kernel.org>

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.

      reply	other threads:[~2026-07-16 14:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-11  7:13 [PATCH net] nfc: st21nfca: validate ATR_REQ length against the received frame Doruk Tan Ozturk
2026-07-16 14:58 ` Simon Horman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260716145846.GM95246@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=david@ixit.cz \
    --cc=doruk@0sec.ai \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=oe-linux-nfc@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.