<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/Documentation, branch v5.15.212</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.212</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.212'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-07-24T13:51:58+00:00</updated>
<entry>
<title>PCI: Move Resizable BAR code to rebar.c</title>
<updated>2026-07-24T13:51:58+00:00</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@linux.intel.com</email>
</author>
<published>2026-07-15T11:16:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d92250b5fdf04582760d7dc9dd257fdae1a3c1f6'/>
<id>urn:sha1:d92250b5fdf04582760d7dc9dd257fdae1a3c1f6</id>
<content type='text'>
[ Upstream commit 9f71938cd77f32a448f40a288e409eca60e55486 ]

For lack of a better place to put it, Resizable BAR code has been placed
inside pci.c and setup-res.c that do not use it for anything.  Upcoming
changes are going to add more Resizable BAR related functions, increasing
the code size.

As pci.c is huge as is, move the Resizable BAR related code and the BAR
resize code from setup-res.c to rebar.c.

Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@linux.intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Link: https://patch.msgid.link/20251113180053.27944-2-ilpo.jarvinen@linux.intel.com
Stable-dep-of: ee7471fe968d ("PCI: Skip Resizable BAR restore on read error")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>cpufreq: Documentation: fix conservative governor freq_step description</title>
<updated>2026-07-24T13:51:33+00:00</updated>
<author>
<name>Pengjie Zhang</name>
<email>zhangpengjie2@huawei.com</email>
</author>
<published>2026-06-03T05:56:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0fee2063eb31b6fc765b6e6c501d0a7ebf219c2d'/>
<id>urn:sha1:0fee2063eb31b6fc765b6e6c501d0a7ebf219c2d</id>
<content type='text'>
[ Upstream commit 03120e1425262c7d11f93362a88e579a1720390b ]

The conservative governor documentation incorrectly states that setting
freq_step to 0 will use the default 5% frequency step. In reality, since
at least commit 8e677ce83bf4 ("[CPUFREQ] conservative: fixup governor to
function more like ondemand logic"), freq_step=0 has always caused the
governor to skip frequency updates entirely.

Correct the documentation to reflect the actual behavior: freq_step=0
disables frequency changes by the governor entirely.

Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation")
Signed-off-by: Pengjie Zhang &lt;zhangpengjie2@huawei.com&gt;
Reviewed-by: Zhongqiu Han &lt;zhongqiu.han@oss.qualcomm.com&gt;
[ rjw: Subject adjustment ]
Link: https://patch.msgid.link/20260603055635.1549943-1-zhangpengjie2@huawei.com
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>cpufreq: Documentation: fix sampling_down_factor range</title>
<updated>2026-07-24T13:51:29+00:00</updated>
<author>
<name>Pengjie Zhang</name>
<email>zhangpengjie2@huawei.com</email>
</author>
<published>2026-05-18T13:34:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac390c81dd888ada712c7370fa3845b437cc6d4b'/>
<id>urn:sha1:ac390c81dd888ada712c7370fa3845b437cc6d4b</id>
<content type='text'>
[ Upstream commit 85524e651d20944399322d46fb97960337831d43 ]

The ondemand governor implementation accepts sampling_down_factor values
from 1 to 100000 via MAX_SAMPLING_DOWN_FACTOR, but the documentation in
admin-guide/pm/cpufreq.rst still says the valid range is 1 to 100.

Update the documentation to match the actual code.

Fixes: 2a0e49279850 ("cpufreq: User/admin documentation update and consolidation")
Reviewed-by: Zhongqiu Han &lt;zhongqiu.han@oss.qualcomm.com&gt;
Signed-off-by: Pengjie Zhang &lt;zhangpengjie2@huawei.com&gt;
Link: https://patch.msgid.link/20260518133457.2408463-1-zhangpengjie2@huawei.com
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties</title>
<updated>2026-07-24T13:51:27+00:00</updated>
<author>
<name>Chen-Yu Tsai</name>
<email>wens@kernel.org</email>
</author>
<published>2025-12-25T10:36:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=af6b8ceebf9dc5499d0f1baef5e4991c5a24b087'/>
<id>urn:sha1:af6b8ceebf9dc5499d0f1baef5e4991c5a24b087</id>
<content type='text'>
commit 018f2dc3a42098d3b04edd1480adc51d268adb14 upstream.

The Allwinner video engine sits behind the MBUS that is represented as
an interconnect.

Make sure that the interconnect properties are valid in the binding.

Fixes: d41662e52a03 ("media: dt-bindings: media: allwinner,sun4i-a10-video-engine: Add R40 compatible")
Cc: stable@vger.kernel.org
Signed-off-by: Chen-Yu Tsai &lt;wens@kernel.org&gt;
Acked-by: Rob Herring (Arm) &lt;robh@kernel.org&gt;
Acked-by: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
Signed-off-by: Nicolas Dufresne &lt;nicolas.dufresne@collabora.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil+cisco@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>crypto: af_alg - Remove zero-copy support from skcipher and aead</title>
<updated>2026-07-24T13:51:27+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@kernel.org</email>
</author>
<published>2026-07-17T03:34:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=15dd81da3573241cdd98abc579b89e65ef0c01b0'/>
<id>urn:sha1:15dd81da3573241cdd98abc579b89e65ef0c01b0</id>
<content type='text'>
commit ffdd2bc378953b525aca61902534e753f1f8e734 upstream.

The zero-copy support is one of the riskiest aspects of AF_ALG.  It
allows userspace to request cryptographic operations directly on
pagecache pages of files like the 'su' binary.  It also allows userspace
to concurrently modify the memory which is being operated on, a recipe
for TOCTOU vulnerabilities.

While zero-copy support is more valuable in other areas of the kernel
like the frequently used networking and file I/O code, it has far less
value in AF_ALG, which is a niche UAPI.  AF_ALG primarily just exists
for backwards compatibility with a small set of userspace programs such
as 'iwd' that haven't yet been fixed to use userspace crypto code.

Originally AF_ALG was intended to be used to access hardware crypto
accelerators.  However, it isn't an efficient interface for that anyway,
and it turned out to be rarely used in this way in practice.

Thus, the risks of the zero-copy support in AF_ALG vastly outweigh its
benefits.  Let's just remove it.

This commit removes it from the "skcipher" and "aead" algorithm types.
"hash" will be handled separately.

This is a soft break, not a hard break.  Even after this commit, it
still works to use splice() or sendfile() to transfer data to an AF_ALG
request socket from a pipe or any file, respectively.  What changes is
just that the kernel now makes an internal, stable copy of the data
before doing the crypto operation.  So performance is slightly reduced,
but the UAPI isn't broken.  And, very importantly, it's much safer.

Tested with libkcapi/test.sh.  All its test cases still pass.  I also
verified that this would have prevented the copy.fail exploit as well.
I also used a custom test program to verify that sendfile() still works.

Fixes: 8ff590903d5f ("crypto: algif_skcipher - User-space interface for skcipher operations")
Fixes: 400c40cf78da ("crypto: algif - add AEAD support")
Reported-by: Taeyang Lee &lt;0wn@theori.io&gt;
Link: https://copy.fail/
Reported-by: Feng Ning &lt;feng@innora.ai&gt;
Closes: https://lore.kernel.org/r/afYcc-tZFwvZZo76@ans-MacBook-Pro.local
Reviewed-by: Demi Marie Obenour &lt;demiobenour@gmail.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers &lt;ebiggers@kernel.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>crypto: qat - remove unused character device and IOCTLs</title>
<updated>2026-07-04T11:39:41+00:00</updated>
<author>
<name>Giovanni Cabiddu</name>
<email>giovanni.cabiddu@intel.com</email>
</author>
<published>2026-06-25T18:42:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1de076f43e64bf65fbe7280a269c70e0e60518df'/>
<id>urn:sha1:1de076f43e64bf65fbe7280a269c70e0e60518df</id>
<content type='text'>
[ Upstream commit d237230728c567297f2f98b425d63156ab2ed17f ]

The QAT driver exposes a character device (qat_adf_ctl) with IOCTLs
for device configuration, start, stop, status query and enumeration.
These IOCTLs are not part of any public uAPI header and have no known
in-tree or out-of-tree users. Device lifecycle is already managed via
sysfs.

The ioctl interface also increases the attack surface and is the
subject of a number of bug reports.

Remove the character device, the IOCTL definitions, and the related
data structures (adf_dev_status_info, adf_user_cfg_key_val,
adf_user_cfg_section, adf_user_cfg_ctl_data). Drop the now-unused
adf_cfg_user.h header and strip adf_ctl_drv.c down to the minimal
module_init/module_exit hooks for workqueue, AER, and crypto/compression
algorithm registration.

Clean up leftover dead code that was only reachable from the removed
IOCTL paths: adf_cfg_del_all(), adf_devmgr_verify_id(),
adf_devmgr_get_num_dev(), adf_devmgr_get_dev_by_id(),
adf_get_vf_real_id() and the unused ADF_CFG macros.

Additionally, drop the entry associated to QAT IOCTLs in
ioctl-number.rst.

Cc: stable@vger.kernel.org
Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework")
Reported-by: Zhi Wang &lt;wangzhi@stu.xidian.edu.cn&gt;
Reported-by: Bin Yu &lt;byu@xidian.edu.cn&gt;
Reported-by: MingYu Wang &lt;w15303746062@163.com&gt;
Closes: https://lore.kernel.org/all/61d6d499.ab89.19b9b7f3186.Coremail.wangzhi_xd@stu.xidian.edu.cn/
Link: https://lore.kernel.org/all/20260508034841.256794-1-w15303746062@163.com/
Link: https://lore.kernel.org/all/20260508023542.256299-1-w15303746062@163.com/
Link: https://lore.kernel.org/all/20260504025120.98242-1-w15303746062@163.com/
Signed-off-by: Giovanni Cabiddu &lt;giovanni.cabiddu@intel.com&gt;
Reviewed-by: Ahsan Atta &lt;ahsan.atta@intel.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Documentation: ioctl-number: Extend "Include File" column width</title>
<updated>2026-07-04T11:39:41+00:00</updated>
<author>
<name>Bagas Sanjaya</name>
<email>bagasdotme@gmail.com</email>
</author>
<published>2026-06-25T18:42:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b57367c466f77afd3386ba84a1ba9f409b172424'/>
<id>urn:sha1:b57367c466f77afd3386ba84a1ba9f409b172424</id>
<content type='text'>
[ Upstream commit 15afd5def819e4df2a29cef6fcfa6ae7ba167c0f ]

Extend width of "Include File" column to fit full path to
papr-physical-attestation.h in later commit.

Reviewed-by: Haren Myneni &lt;haren@linux.ibm.com&gt;
Signed-off-by: Bagas Sanjaya &lt;bagasdotme@gmail.com&gt;
Acked-by: Madhavan Srinivasan &lt;maddy@linux.ibm.com&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
Link: https://lore.kernel.org/r/20250714015711.14525-3-bagasdotme@gmail.com
Stable-dep-of: d237230728c5 ("crypto: qat - remove unused character device and IOCTLs")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>arm64: errata: Mitigate TLBI errata on Microsoft Azure Cobalt 100 CPU</title>
<updated>2026-06-19T11:33:50+00:00</updated>
<author>
<name>Will Deacon</name>
<email>will@kernel.org</email>
</author>
<published>2026-06-16T05:23:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6a26fd2e6b6fccb15f1aeb2056a84f46cba08e52'/>
<id>urn:sha1:6a26fd2e6b6fccb15f1aeb2056a84f46cba08e52</id>
<content type='text'>
commit 1940e70a8144bf75e6df26bf6f600862ea7f7ea1 upstream.

Commit fb091ff39479 ("arm64: Subscribe Microsoft Azure Cobalt 100 to ARM
Neoverse N2 errata") states that Microsoft Azure Cobalt 100 CPU "is a
Microsoft implemented CPU based on r0p0 of the ARM Neoverse N2 CPU, and
therefore suffers from all the same errata.".

So enable the workaround for the latest broadcast TLB invalidation bug
on these parts.

Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
[Mark: backport to v5.15.y]
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU</title>
<updated>2026-06-19T11:33:50+00:00</updated>
<author>
<name>Shanker Donthineni</name>
<email>sdonthineni@nvidia.com</email>
</author>
<published>2026-06-16T05:23:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f040e78cde73c9363beec35514ea0242725402ef'/>
<id>urn:sha1:f040e78cde73c9363beec35514ea0242725402ef</id>
<content type='text'>
commit ec7216f92e4ebd485b1c6dc6aa3f6064b71a5768 upstream.

NVIDIA Olympus cores are affected by the TLBI completion issue tracked as
CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses
ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB
sequence and ensure affected memory write effects are globally observed.

Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same
mitigation is enabled on affected Olympus systems. Also document the
NVIDIA Olympus erratum in the arm64 silicon errata table and list it in
the Kconfig help text.

Signed-off-by: Shanker Donthineni &lt;sdonthineni@nvidia.com&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Will Deacon &lt;will@kernel.org&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Acked-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
[Mark: backport to v5.15.y]
Signed-off-by: Shanker Donthineni &lt;sdonthineni@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>arm64: errata: Mitigate TLBI errata on various Arm CPUs</title>
<updated>2026-06-19T11:33:50+00:00</updated>
<author>
<name>Mark Rutland</name>
<email>mark.rutland@arm.com</email>
</author>
<published>2026-06-16T05:23:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8364384ae82fbffdf8968abaac3455ed854da18d'/>
<id>urn:sha1:8364384ae82fbffdf8968abaac3455ed854da18d</id>
<content type='text'>
commit cfd391e74134db664feb499d43af286380b10ba8 upstream.

A number of CPUs developed by Arm suffer from errata whereby a broadcast
TLBI;DSB sequence may complete before the global observation of writes
which are translated by an affected TLB entry.

These errata ONLY affect the completion of memory accesses which have
been translated by an invalidated TLB entry, and these errata DO NOT
affect the actual invalidation of TLB entries. TLB entries are removed
correctly.

This issue has been assigned CVE ID CVE-2025-10263.

To mitigate this issue, Arm recommends that software follows any
affected TLBI;DSB sequence with an additional TLBI;DSB, which will
ensure that all memory write effects affected by the first TLBI have
been globally observed. The additional TLBI can use any operation that
is broadcast to affected CPUs, and the additional DSB can use any option
that is sufficient to complete the additional TLBI.

The ARM64_WORKAROUND_REPEAT_TLBI workaround is sufficient to mitigate
the issue. Enable this workaround for affected CPUs, and update the
silicon errata documentation accordingly.

Note that due to the manner in which Arm develops IP and tracks errata,
some CPUs share a common erratum number.

Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
[Mark: backport to v5.15.y]
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
