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.