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 11/12] crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
Date: Thu, 21 May 2026 12:17:34 +0200 [thread overview]
Message-ID: <2c2c82f5-21d2-4851-86c8-0dbc05537427@kernel.org> (raw)
In-Reply-To: <20260520155703.23018-12-l.rubusch@gmail.com>
On 20/05/2026 17:57, Lothar Rubusch wrote:
> When a non-blocking read operation is requested, the driver dynamically
> allocates memory to track asynchronous transfer status. If the underlying
> I2C transmission fails, atmel_sha204a_rng_done() logs a rate-limited
> warning but incorrectly proceeds to cache the pointer to this uninitialized
> buffer inside the rng->priv data field anyway.
>
> On subsequent execution passes, atmel_sha204a_rng_read_nonblocking()
> detects the stale rng->priv value, skips executing a hardware data read,
> and copies up to 32 bytes of uninitialized kernel heap data from this
> garbage memory pool straight back into the system's hwrng data stream.
>
> Fix this information disclosure vector by immediately releasing the
> allocated asynchronous work data buffer and explicitly clearing the
> tracking pointer context whenever an I2C transaction returns a non-zero
> error status.
>
> Additionally, duplicate the tfm counter decrement within the new error
> path to ensure the reference counter is properly released before executing
> the early return, maintaining the driver's availability for subsequent
> requests.
>
> Fixes: da001fb651b0 ("crypto: atmel-i2c - add support for SHA204A random number generator")
This and other fixes should be first in the patchset. Or even separate
patchset.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-05-21 10:17 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
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 [this message]
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=2c2c82f5-21d2-4851-86c8-0dbc05537427@kernel.org \
--to=krzk@kernel$(echo .)org \
--cc=alexandre.belloni@bootlin$(echo .)com \
--cc=ardb@kernel$(echo .)org \
--cc=claudiu.beznea@tuxon$(echo .)dev \
--cc=davem@davemloft$(echo .)net \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=l.rubusch@gmail$(echo .)com \
--cc=linusw@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-crypto@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=nicolas.ferre@microchip$(echo .)com \
--cc=thorsten.blum@linux$(echo .)dev \
--cc=tudor.ambarus@linaro$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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