<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel, branch linux-6.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2026-03-05T15:02:32Z</updated>
<entry>
<title>Linux 6.1.166</title>
<updated>2026-03-05T15:02:32Z</updated>
<author>
<name>Sasha Levin</name>
<email>sashal@kernel.org</email>
</author>
<published>2026-03-05T15:02:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f2ddafa93a259310ca47507153b7811ec54ab7fd'/>
<id>urn:sha1:f2ddafa93a259310ca47507153b7811ec54ab7fd</id>
<content type='text'>
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Revert "x86/kexec: add a sanity check on previous kernel's ima kexec buffer"</title>
<updated>2026-03-05T14:58:09Z</updated>
<author>
<name>Sasha Levin</name>
<email>sashal@kernel.org</email>
</author>
<published>2026-03-05T14:48:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=0ae716c6d1396f62f6012a1c1f2852533df973ea'/>
<id>urn:sha1:0ae716c6d1396f62f6012a1c1f2852533df973ea</id>
<content type='text'>
This reverts commit c5489d04337b47e93c0623e8145fcba3f5739efd.

The commit introduces a call to ima_validate_range() in
arch/x86/kernel/setup.c, but the function declaration is not available
in the 6.12 stable tree, resulting in build failures due to implicit
function declaration errors across multiple stable branches.

Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Linux 6.1.165</title>
<updated>2026-03-04T12:35:21Z</updated>
<author>
<name>Sasha Levin</name>
<email>sashal@kernel.org</email>
</author>
<published>2026-03-04T12:33:24Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2f66dd9cff421f27dbe192f2035ce61b811561b1'/>
<id>urn:sha1:2f66dd9cff421f27dbe192f2035ce61b811561b1</id>
<content type='text'>
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Tested-by: Hardik Garg &lt;hargar@linux.microsoft.com&gt;
Tested-by: Miguel Ojeda &lt;ojeda@kernel.org&gt;
Tested-by: Mark Brown &lt;broonie@kernel.org&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Ron Economos &lt;re@w6rz.net&gt;
Tested-by: Francesco Dolcini &lt;francesco.dolcini@toradex.com&gt;
Tested-by: Florian Fainelli &lt;florian.fainelli@broadcom.com&gt;
Tested-by: Peter Schneider &lt;pschneider1968@googlemail.com&gt;
Tested-by: Brett A C Sheffield &lt;bacs@librecast.net&gt;
</content>
</entry>
<entry>
<title>arm64: Fix sampling the "stable" virtual counter in preemptible section</title>
<updated>2026-03-04T12:20:56Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2026-02-26T08:22:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=594d85ce95d2c2fc90fbfa81ff66876ce7c3a2df'/>
<id>urn:sha1:594d85ce95d2c2fc90fbfa81ff66876ce7c3a2df</id>
<content type='text'>
[ Upstream commit e5cb94ba5f96d691d8885175d4696d6ae6bc5ec9 ]

Ben reports that when running with CONFIG_DEBUG_PREEMPT, using
__arch_counter_get_cntvct_stable() results in well deserves warnings,
as we access a per-CPU variable without preemption disabled.

Fix the issue by disabling preemption on reading the counter. We can
probably do a lot better by not disabling preemption on systems that
do not require horrible workarounds to return a valid counter value,
but this plugs the issue for the time being.

Fixes: 29cc0f3aa7c6 ("arm64: Force the use of CNTVCT_EL0 in __delay()")
Reported-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/aZw3EGs4rbQvbAzV@e134344.arm.com
Tested-by: Ben Horgan &lt;ben.horgan@arm.com&gt;
Tested-by: André Draszik &lt;andre.draszik@linaro.org&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>NTB: ntb_transport: Fix too small buffer for debugfs_name</title>
<updated>2026-03-04T12:20:56Z</updated>
<author>
<name>Koichiro Den</name>
<email>den@valinux.co.jp</email>
</author>
<published>2026-01-07T04:24:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=409fe5e265bf23cdf6d9cc24f93cb561dc6527d2'/>
<id>urn:sha1:409fe5e265bf23cdf6d9cc24f93cb561dc6527d2</id>
<content type='text'>
[ Upstream commit 6a4b50585d74fe45d3ade1e3e86ba8aae79761a5 ]

The buffer used for "qp%d" was only 4 bytes, which truncates names like
"qp10" to "qp1" and causes multiple queues to share the same directory.

Enlarge the buffer and use sizeof() to avoid truncation.

Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support")
Cc: &lt;stable@vger.kernel.org&gt; # v3.9+
Reviewed-by: Frank Li &lt;Frank.Li@nxp.com&gt;
Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Koichiro Den &lt;den@valinux.co.jp&gt;
Signed-off-by: Jon Mason &lt;jdmason@kudzu.us&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: nfc: nci: Fix parameter validation for packet data</title>
<updated>2026-03-04T12:20:56Z</updated>
<author>
<name>Michael Thalmeier</name>
<email>michael.thalmeier@hale.at</email>
</author>
<published>2026-02-18T08:30:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f5218426f765eee22e178df9c126d974792fb6a5'/>
<id>urn:sha1:f5218426f765eee22e178df9c126d974792fb6a5</id>
<content type='text'>
[ Upstream commit 571dcbeb8e635182bb825ae758399831805693c2 ]

Since commit 9c328f54741b ("net: nfc: nci: Add parameter validation for
packet data") communication with nci nfc chips is not working any more.

The mentioned commit tries to fix access of uninitialized data, but
failed to understand that in some cases the data packet is of variable
length and can therefore not be compared to the maximum packet length
given by the sizeof(struct).

Fixes: 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data")
Cc: stable@vger.kernel.org
Signed-off-by: Michael Thalmeier &lt;michael.thalmeier@hale.at&gt;
Reported-by: syzbot+740e04c2a93467a0f8c8@syzkaller.appspotmail.com
Link: https://patch.msgid.link/20260218083000.301354-1-michael.thalmeier@hale.at
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: Force the use of CNTVCT_EL0 in __delay()</title>
<updated>2026-03-04T12:20:56Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2026-02-13T14:16:19Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=27c731ce8287f3e40c3d451dd0aab1b7b7633ccc'/>
<id>urn:sha1:27c731ce8287f3e40c3d451dd0aab1b7b7633ccc</id>
<content type='text'>
[ Upstream commit 29cc0f3aa7c64d3b3cb9d94c0a0984ba6717bf72 ]

Quentin forwards a report from Hyesoo Yu, describing an interesting
problem with the use of WFxT in __delay() when a vcpu is loaded and
that KVM is *not* in VHE mode (either nVHE or hVHE).

In this case, CNTVOFF_EL2 is set to a non-zero value to reflect the
state of the guest virtual counter. At the same time, __delay() is
using get_cycles() to read the counter value, which is indirected to
reading CNTPCT_EL0.

The core of the issue is that WFxT is using the *virtual* counter,
while the kernel is using the physical counter, and that the offset
introduces a really bad discrepancy between the two.

Fix this by forcing the use of CNTVCT_EL0, making __delay() consistent
irrespective of the value of CNTVOFF_EL2.

Reported-by: Hyesoo Yu &lt;hyesoo.yu@samsung.com&gt;
Reported-by: Quentin Perret &lt;qperret@google.com&gt;
Reviewed-by: Quentin Perret &lt;qperret@google.com&gt;
Fixes: 7d26b0516a0d ("arm64: Use WFxT for __delay() when possible")
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/ktosachvft2cgqd5qkukn275ugmhy6xrhxur4zqpdxlfr3qh5h@o3zrfnsq63od
Cc: stable@vger.kernel.org
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86/kexec: Copy ACPI root pointer address from config table</title>
<updated>2026-03-04T12:20:56Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2026-02-17T11:09:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=54eb0882df813746d6067f3aa3d1ce34d17c986f'/>
<id>urn:sha1:54eb0882df813746d6067f3aa3d1ce34d17c986f</id>
<content type='text'>
[ Upstream commit e00ac9e5afb5d80c0168ec88d8e8662a54af8249 ]

Dave reports that kexec may fail when the first kernel boots via the EFI
stub but without EFI runtime services, as in that case, the RSDP address
field in struct bootparams is never assigned. Kexec copies this value
into the version of struct bootparams that it provides to the incoming
kernel, which may have no other means to locate the ACPI root pointer.

So take the value from the EFI config tables if no root pointer has been
set in the first kernel's struct bootparams.

Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
Cc: &lt;stable@vger.kernel.org&gt; # v6.1
Reported-by: Dave Young &lt;dyoung@redhat.com&gt;
Tested-by: Dave Young &lt;dyoung@redhat.com&gt;
Link: https://lore.kernel.org/linux-efi/aZQg_tRQmdKNadCg@darkstar.users.ipa.redhat.com/
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/sched: act_skbedit: fix divide-by-zero in tcf_skbedit_hash()</title>
<updated>2026-03-04T12:20:56Z</updated>
<author>
<name>Ruitong Liu</name>
<email>cnitlrt@gmail.com</email>
</author>
<published>2026-02-13T17:59:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=59809fda4da7730cfe84a948033f47eb45db073d'/>
<id>urn:sha1:59809fda4da7730cfe84a948033f47eb45db073d</id>
<content type='text'>
[ Upstream commit be054cc66f739a9ba615dba9012a07fab8e7dd6f ]

Commit 38a6f0865796 ("net: sched: support hash selecting tx queue")
added SKBEDIT_F_TXQ_SKBHASH support. The inclusive range size is
computed as:

mapping_mod = queue_mapping_max - queue_mapping + 1;

The range size can be 65536 when the requested range covers all possible
u16 queue IDs (e.g. queue_mapping=0 and queue_mapping_max=U16_MAX).
That value cannot be represented in a u16 and previously wrapped to 0,
so tcf_skbedit_hash() could trigger a divide-by-zero:

queue_mapping += skb_get_hash(skb) % params-&gt;mapping_mod;

Compute mapping_mod in a wider type and reject ranges larger than U16_MAX
to prevent params-&gt;mapping_mod from becoming 0 and avoid the crash.

Fixes: 38a6f0865796 ("net: sched: support hash selecting tx queue")
Cc: stable@vger.kernel.org # 6.12+
Signed-off-by: Ruitong Liu &lt;cnitlrt@gmail.com&gt;
Link: https://patch.msgid.link/20260213175948.1505257-1-cnitlrt@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: ethernet: ec_bhf: Fix dma_free_coherent() dma handle</title>
<updated>2026-03-04T12:20:56Z</updated>
<author>
<name>Thomas Fourier</name>
<email>fourier.thomas@gmail.com</email>
</author>
<published>2026-02-13T16:43:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8320727be7ff704e07c87624efc2a4a75f54b3ce'/>
<id>urn:sha1:8320727be7ff704e07c87624efc2a4a75f54b3ce</id>
<content type='text'>
[ Upstream commit ffe68c3766997d82e9ccaf1cdbd47eba269c4aa2 ]

dma_free_coherent() in error path takes priv-&gt;rx_buf.alloc_len as
the dma handle. This would lead to improper unmapping of the buffer.

Change the dma handle to priv-&gt;rx_buf.alloc_phys.

Fixes: 6af55ff52b02 ("Driver for Beckhoff CX5020 EtherCAT master module.")
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Thomas Fourier &lt;fourier.thomas@gmail.com&gt;
Link: https://patch.msgid.link/20260213164340.77272-2-fourier.thomas@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
