All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-93159: crypto: atmel-sha204a - fix heap info leak on I2C transfer failure
Date: Thu, 17 Sep 2026 17:17:16 +0100	[thread overview]
Message-ID: <2026091757-CVE-2026-93159-617c@gregkh> (raw)

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

crypto: atmel-sha204a - fix heap info leak on I2C transfer failure

The nonblocking RNG path allocates a work_data structure to track the
state of an in-flight asynchronous I2C request. This pointer is stored
in rng->priv and later consumed by the read path once the transaction
completes.

If the underlying I2C transfer fails, the completion callback is invoked
with a non-zero status. In this case, the allocated work_data is not
usable for producing RNG output and must not remain associated with the
hwrng state.

Previously, the failure path only logged a warning but left the pointer
state uncleared, which can result in subsequent read attempts observing
stale state and interpreting it as valid completion data.

Fix this by freeing the pending work_data. The I2C transaction reports
an error. This ensures that failed requests do not leave residual state
behind that could be interpreted as valid RNG data on later reads.
Clearing rng->priv is done at the subsequent call to nonblocking read.

The Linux kernel CVE team has assigned CVE-2026-93159 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.3 with commit da001fb651b00e1deeaf24767dd691ae8152a4f5 and fixed in 5.10.270 with commit a430b5b6d2ddd2b266330f8507a655be1148347d
	Issue introduced in 5.3 with commit da001fb651b00e1deeaf24767dd691ae8152a4f5 and fixed in 5.15.221 with commit 4e76d85e505b7451925efbcd67c015e8c2440c68
	Issue introduced in 5.3 with commit da001fb651b00e1deeaf24767dd691ae8152a4f5 and fixed in 6.1.188 with commit bcac9052e19490231ff6e0678a06bd2fcf8db3af
	Issue introduced in 5.3 with commit da001fb651b00e1deeaf24767dd691ae8152a4f5 and fixed in 6.6.157 with commit 28cc179252347718f97045dd5ea74165609dbd7d
	Issue introduced in 5.3 with commit da001fb651b00e1deeaf24767dd691ae8152a4f5 and fixed in 6.12.110 with commit 0d6db386133d9230befb77967bbf130443964860
	Issue introduced in 5.3 with commit da001fb651b00e1deeaf24767dd691ae8152a4f5 and fixed in 6.18.52 with commit f4d347fb1309b69ea6f817a17e6b2893c8d754b7
	Issue introduced in 5.3 with commit da001fb651b00e1deeaf24767dd691ae8152a4f5 and fixed in 7.2.6 with commit 94abda77b57a35b82bba0365bad072d94d67ffe9
	Issue introduced in 5.3 with commit da001fb651b00e1deeaf24767dd691ae8152a4f5 and fixed in 7.3-rc1 with commit 72bbf11ba14bd7d5fbf31a1ec42fff608b657f74

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-93159
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	drivers/crypto/atmel-sha204a.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/a430b5b6d2ddd2b266330f8507a655be1148347d
	https://git.kernel.org/stable/c/4e76d85e505b7451925efbcd67c015e8c2440c68
	https://git.kernel.org/stable/c/bcac9052e19490231ff6e0678a06bd2fcf8db3af
	https://git.kernel.org/stable/c/28cc179252347718f97045dd5ea74165609dbd7d
	https://git.kernel.org/stable/c/0d6db386133d9230befb77967bbf130443964860
	https://git.kernel.org/stable/c/f4d347fb1309b69ea6f817a17e6b2893c8d754b7
	https://git.kernel.org/stable/c/94abda77b57a35b82bba0365bad072d94d67ffe9
	https://git.kernel.org/stable/c/72bbf11ba14bd7d5fbf31a1ec42fff608b657f74

                 reply	other threads:[~2026-09-17 16:41 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=2026091757-CVE-2026-93159-617c@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=cve@kernel.org \
    --cc=gregkh@kernel.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@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.