Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Lothar Rubusch <l.rubusch@gmail.com>,
	thorsten.blum@linux.dev, herbert@gondor.apana.org.au,
	davem@davemloft.net, nicolas.ferre@microchip.com,
	alexandre.belloni@bootlin.com, claudiu.beznea@tuxon.dev,
	tudor.ambarus@linaro.org, ardb@kernel.org, linusw@kernel.org
Cc: linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 02/12] crypto: atmel-ecc - fix use after free situation
Date: Thu, 21 May 2026 12:16:37 +0200	[thread overview]
Message-ID: <5c03ea16-036f-4967-9678-29774f151fe3@kernel.org> (raw)
In-Reply-To: <20260520155703.23018-3-l.rubusch@gmail.com>

On 20/05/2026 17:56, Lothar Rubusch wrote:
> Fixes the very likely race condition, having multiple of such devices
> attached (identified by sashiko feedback).
> 
> The Scenario:
>     Thread A (Device 1 Probe): Successfully adds i2c_priv to the global
>              list (Line 324). The lock is released.
>     Thread B (An active crypto request): Concurrently calls
>               atmel_ecc_i2c_client_alloc(). It scans the global list, sees
>               Device 1, and assigns a crypto job to it.
>     Thread A: Moves to line 332. crypto_register_kpp() fails (e.g., out of
>               memory or name clash).
>     Thread A: Enters the error path. It removes Device 1 from the list and
>               frees the i2c_priv memory.
>     Thread B: Is still actively trying to talk to the I2C hardware using
>               the i2c_priv pointer it grabbed in Step 2. The memory is now
>               gone. Result: Kernel crash (Use-After-Free).
> 
> Fixes: 11105693fa05 ("crypto: atmel-ecc - introduce Microchip / Atmel ECC driver")

Please add Cc-stable

> Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
> ---

And fixes must be before any code refactorings, so your rename patch
should be after.


Best regards,
Krzysztof


  reply	other threads:[~2026-05-21 10:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20 15:56 [PATCH v3 00/12] crypto: atmel - introduce shared i2c core client management and capability-based selection framework Lothar Rubusch
2026-05-20 15:56 ` [PATCH v3 01/12] crypto: atmel-ecc - rename driver_data before moving it into atmel-i2c Lothar Rubusch
2026-05-20 15:56 ` [PATCH v3 02/12] crypto: atmel-ecc - fix use after free situation Lothar Rubusch
2026-05-21 10:16   ` Krzysztof Kozlowski [this message]
2026-05-20 15:56 ` [PATCH v3 03/12] crypto: atmel-ecc - fix multi-device kpp registration Lothar Rubusch
2026-05-20 15:56 ` [PATCH v3 04/12] crypto: atmel - rename atmel_ecc_driver_data to atmel_i2c_client_mgmt Lothar Rubusch
2026-05-20 15:56 ` [PATCH v3 05/12] crypto: atmel-i2c - move client management instance into core Lothar Rubusch
2026-05-20 15:56 ` [PATCH v3 06/12] crypto: atmel-i2c - introduce shared teardown helpers and fix queue flush Lothar Rubusch
2026-05-20 15:56 ` [PATCH v3 07/12] crypto: atmel-ecc - switch to module_i2c_driver Lothar Rubusch
2026-05-20 15:56 ` [PATCH v3 08/12] crypto: atmel-i2c - move shared client allocation logic to core Lothar Rubusch
2026-05-20 15:57 ` [PATCH v3 09/12] crypto: atmel-i2c - implement capability-based client selection Lothar Rubusch
2026-05-20 15:57 ` [PATCH v3 10/12] crypto: atmel-sha204a - integrate into core management tracking Lothar Rubusch
2026-05-20 15:57 ` [PATCH v3 11/12] crypto: atmel-sha204a - fix heap info leak on I2C transfer failure Lothar Rubusch
2026-05-21 10:17   ` Krzysztof Kozlowski
2026-05-20 15:57 ` [PATCH v3 12/12] crypto: atmel-sha204a - switch to module_i2c_driver Lothar Rubusch

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=5c03ea16-036f-4967-9678-29774f151fe3@kernel.org \
    --to=krzk@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=ardb@kernel.org \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=l.rubusch@gmail.com \
    --cc=linusw@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=thorsten.blum@linux.dev \
    --cc=tudor.ambarus@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox