* [STATUS] stable/linux-6.6.y - 0a40c6fbd105802fbbcaadca249e0948fbf8095a
From: KernelCI bot @ 2026-05-24 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: stable
Hello,
Status summary for stable/linux-6.6.y
Dashboard:
https://d.kernelci.org/c/stable/linux-6.6.y/0a40c6fbd105802fbbcaadca249e0948fbf8095a/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-6.6.y
commit hash: 0a40c6fbd105802fbbcaadca249e0948fbf8095a
origin: maestro
test start time: 2026-05-23 11:13:22.220000+00:00
Builds: 44 ✅ 0 ❌ 0 ⚠️
Boots: 63 ✅ 0 ❌ 6 ⚠️
Tests: 4653 ✅ 1611 ❌ 1469 ⚠️
### POSSIBLE REGRESSIONS
Hardware: mt8183-kukui-jacuzzi-juniper-sku16
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kernelci_watchdog_reset.wdt-reset.wdt-get-timeout
last run: https://d.kernelci.org/test/maestro:6a1196635bf5d05c97445d26
history: > ✅ > ❌
Hardware: mt8195-cherry-tomato-r2
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kernelci_watchdog_reset.wdt-reset.wdt-get-timeout
last run: https://d.kernelci.org/test/maestro:6a1196065bf5d05c97445a1b
history: > ✅ > ❌
### FIXED REGRESSIONS
Hardware: asus-CX3402CVA-brya
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- kernelci_sleep
last run: https://d.kernelci.org/test/maestro:6a11932a5bf5d05c97442f68
history: > ❌ > ✅
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11963c5bf5d05c97445c17
history: > ✅ > ⚠️ > ✅ > ✅ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.mm.mm_run_vmtests_sh_khugepaged
last run: https://d.kernelci.org/test/maestro:6a1198ac5bf5d05c97447823
history: > ⚠️ > ❌
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11921e5bf5d05c97442ceb
history: > ✅ > ✅ > ⚠️ > ✅
Hardware: imx6dl-udoo
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11921f5bf5d05c97442cee
history: > ✅ > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a1193265bf5d05c97442f62
history: > ✅ > ✅ > ⚠️ > ✅
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* [STATUS] stable/linux-5.15.y - 241d66fa280c91b65942d641e92d06c9ae6a0b95
From: KernelCI bot @ 2026-05-24 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: stable
Hello,
Status summary for stable/linux-5.15.y
Dashboard:
https://d.kernelci.org/c/stable/linux-5.15.y/241d66fa280c91b65942d641e92d06c9ae6a0b95/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-5.15.y
commit hash: 241d66fa280c91b65942d641e92d06c9ae6a0b95
origin: maestro
test start time: 2026-05-23 12:15:07.678000+00:00
Builds: 38 ✅ 4 ❌ 0 ⚠️
Boots: 36 ✅ 0 ❌ 5 ⚠️
Tests: 483 ✅ 170 ❌ 340 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11af0b5bf5d05c9744fc4e
history: > ⚠️ > ✅ > ✅
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a6715bf5d05c9744f2ff
history: > ✅ > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a0065bf5d05c9744e276
history: > ✅ > ⚠️ > ✅
This branch has 4 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* [STATUS] stable/linux-5.10.y - 7adbe121223f7e32ab7e2592a72093f80f4e11a8
From: KernelCI bot @ 2026-05-24 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: stable
Hello,
Status summary for stable/linux-5.10.y
Dashboard:
https://d.kernelci.org/c/stable/linux-5.10.y/7adbe121223f7e32ab7e2592a72093f80f4e11a8/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-5.10.y
commit hash: 7adbe121223f7e32ab7e2592a72093f80f4e11a8
origin: maestro
test start time: 2026-05-23 12:15:07.250000+00:00
Builds: 40 ✅ 2 ❌ 0 ⚠️
Boots: 36 ✅ 0 ❌ 4 ⚠️
Tests: 315 ✅ 78 ❌ 44 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a1965bf5d05c9744e875
history: > ⚠️ > ✅ > ✅ > ✅
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a07c5bf5d05c9744e2cd
history: > ✅ > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11ade45bf5d05c9744f85e
history: > ✅ > ⚠️ > ✅
This branch has 2 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* [STATUS] stable/linux-6.12.y - c4ffbe29c40ed851601bce640d5ead48eaaae08d
From: KernelCI bot @ 2026-05-24 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: stable
Hello,
Status summary for stable/linux-6.12.y
Dashboard:
https://d.kernelci.org/c/stable/linux-6.12.y/c4ffbe29c40ed851601bce640d5ead48eaaae08d/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-6.12.y
commit hash: c4ffbe29c40ed851601bce640d5ead48eaaae08d
origin: maestro
test start time: 2026-05-23 11:13:22.651000+00:00
Builds: 44 ✅ 0 ❌ 0 ⚠️
Boots: 78 ✅ 0 ❌ 6 ⚠️
Tests: 9165 ✅ 575 ❌ 2822 ⚠️
### POSSIBLE REGRESSIONS
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.device_error_logs
last run: https://d.kernelci.org/test/maestro:6a119b8e5bf5d05c97448cea
history: > ✅ > ❌
- kselftest.device_error_logs.devices_error_logs_test_device_error_logs_py
last run: https://d.kernelci.org/test/maestro:6a11c8315bf5d05c974527b0
history: > ✅ > ❌
Hardware: mt8183-kukui-jacuzzi-juniper-sku16
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kernelci_watchdog_reset
last run: https://d.kernelci.org/test/maestro:6a1196e95bf5d05c97445f6c
history: > ✅ > ❌
- kernelci_watchdog_reset.wdt-reset.wdt-trigger-reset
last run: https://d.kernelci.org/test/maestro:6a11984b5bf5d05c97446f79
history: > ✅ > ❌
### FIXED REGRESSIONS
Hardware: imx8mp-evk
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.kvm_arch_timer_edge_cases
last run: https://d.kernelci.org/test/maestro:6a1199d75bf5d05c97448023
history: > ❌ > ✅
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a119b665bf5d05c97448bd3
history: > ✅ > ⚠️ > ✅ > ✅ > ✅
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a1194815bf5d05c974443b5
history: > ✅ > ✅ > ✅ > ⚠️ > ✅
Hardware: imx6dl-udoo
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a1194835bf5d05c974443b8
history: > ✅ > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a1193f15bf5d05c97443af3
history: > ✅ > ✅ > ⚠️ > ✅
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* [STATUS] stable/linux-6.1.y - dcbcab9d707928cd1679eba21ef0697fbb73b88a
From: KernelCI bot @ 2026-05-24 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: stable
Hello,
Status summary for stable/linux-6.1.y
Dashboard:
https://d.kernelci.org/c/stable/linux-6.1.y/dcbcab9d707928cd1679eba21ef0697fbb73b88a/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
branch: linux-6.1.y
commit hash: dcbcab9d707928cd1679eba21ef0697fbb73b88a
origin: maestro
test start time: 2026-05-23 12:15:08.086000+00:00
Builds: 41 ✅ 1 ❌ 0 ⚠️
Boots: 45 ✅ 0 ❌ 5 ⚠️
Tests: 1715 ✅ 146 ❌ 806 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a3dd5bf5d05c9744ef31
history: > ⚠️ > ✅ > ✅ > ✅
Hardware: beaglebone-black
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a5975bf5d05c9744f173
history: > ✅ > ⚠️ > ✅
Hardware: imx6dl-udoo
> Config: multi_v7_defconfig
- Architecture/compiler: arm/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a5985bf5d05c9744f176
history: > ⚠️ > ✅
Hardware: qemu-x86_64
> Config: x86_64_defconfig+lab-setup+x86-board+kselftest
- Architecture/compiler: x86_64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a11a5175bf5d05c9744f101
history: > ✅ > ⚠️ > ✅
This branch has 1 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: Linux 6.12.91
From: Wang Yugui @ 2026-05-24 0:56 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, akpm, torvalds, stable, lwn, jslaby
In-Reply-To: <2026052319-chastity-viper-7530@gregkh>
Hi,
> I'm announcing the release of the 6.12.91 kernel.
>
> All users of the 6.12 kernel series must upgrade.
>
> The updated 6.12.y git tree can be found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.12.y
> and can be browsed at the normal kernel.org git web browser:
> https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
2 regression of 6.12.91 are found here. Both of them are in perf tool
1, undefined reference to `parse_events__term_type_str'
Could we add a patch
d2f3ecb0ca2099d13bf8bf69219214c1425dc453 perf parse-events: Expose/rename config_term_name
or do some funcation rename(parse_events__term_type_str->config_term_name)?
2, undefined first_wildcard_match
Could we revert the patch (perf cgroup: Update metric leader in evlist__expand_cgroup)?
Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2026/05/24
^ permalink raw reply
* Linux 6.12.91 / build breakage / perf cgroup: Update metric leader in evlist__expand_cgroup
From: Marek Vasut @ 2026-05-24 3:56 UTC (permalink / raw)
To: linux-stable, Sasha Levin; +Cc: Ian Rogers, Sun Jian, Namhyung Kim
Hello everyone,
the following commit landed in Linux 6.12.91:
d26e31446c0f ("perf cgroup: Update metric leader in evlist__expand_cgroup")
However, the first_wildcard_match field does not exist in Linux 6.12.91,
which prevents perf from being built:
"
$ git grep first_wildcard_match
tools/perf/util/cgroup.c: if
(pos->first_wildcard_match)
tools/perf/util/cgroup.c:
evsel->first_wildcard_match = pos->first_wildcard_match->priv;
"
Either this commit should be dropped, or 137359b7895f ("perf
parse-events: Use wildcard processing to set an event to merge into")
needs to be backported too (?).
Furthermore, it also seems 7cfcd01f33fc ("perf tool_pmu: Factor tool
events into their own PMU") calls parse_events__term_type_str() which is
also not defined on 6.12.y .
Thank you for your help !
--
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH net v2 0/4] net: trust-after-modification fixes for IPv4 options + netlabel
From: Qi Tang @ 2026-05-24 4:14 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: netdev, fw, lyutoon, stable, Qi Tang, David Ahern, Ido Schimmel,
Simon Horman, Paul Moore, Casey Schaufler, Huw Davies,
linux-security-module
Four small bounds-check fixes for a recurring pattern in IPv4 options
and CIPSO/CALIPSO consumers. The parse-time validator stores only
the option offset into IPCB / skb metadata. Later consumers (cmsg
echo, mrouted report, netlabel getattr) re-read the length /
pointer / cat_len bytes from the skb body and use them for indexed
memcpy or bitmap walk. An nftables payload mutation reachable from
an unprivileged user namespace (CAP_NET_ADMIN inside the namespace)
rewrites those bytes between parse and consume.
1/4 __ip_options_echo() 40-byte stack OOB write
(KASAN: stack-out-of-bounds,
Write of size 255).
2/4 ipmr_cache_report() Up to 40-byte OOB read of
skb head leaked into the
IGMPMSG cmsg delivered to
mrouted.
3/4 netlbl_skbuff_getattr() / CALIPSO ~232-byte slab OOB read
driving SELinux MLS
category bitmap.
4/4 netlbl_skbuff_getattr() / CIPSO Sibling of 3/4 on the
AF_INET (CIPSO IPv4) path.
Florian Westphal's [PATCH net 05/10] netfilter: disable payload
mangling in userns blocks the unprivileged-userns side of nft
payload-set at the source:
https://lore.kernel.org/netdev/20260522104257.2008-6-fw@strlen.de/
These four consumer-side bounds checks land in the same direction
as defense in depth, also covering root / CAP_NET_ADMIN nft
FORWARD payload mangling in the init userns and any non-nft
mutation path.
Changes v1 -> v2:
- 3/4 + 4/4 return -EINVAL on bounds-check failure instead of
falling through to netlbl_unlabel_getattr() (Paul Moore).
- 3/4 commit message drops the "Smack" mention from the CALIPSO
consume path; Smack does not currently consume CALIPSO (Casey
Schaufler).
- 4/4 inline comment explains the literal 8: CIPSO option header
(type+len+DOI = 6) plus first tag header (type+len = 2) (Paul
Moore).
- All four pick up Cc: stable@vger.kernel.org.
v1: https://lore.kernel.org/netdev/20260514165139.436961-1-tpluszz77@gmail.com/
Qi Tang (4):
ipv4: validate ip_options length in __ip_options_echo() against skb
tail
ipv4: ipmr: clamp ip_hdrlen against skb_headlen in ipmr_cache_report
netlabel: validate CALIPSO option against skb tail in
netlbl_skbuff_getattr
netlabel: validate CIPSO option against skb tail in
netlbl_skbuff_getattr
net/ipv4/ip_options.c | 8 ++++++++
net/ipv4/ipmr.c | 2 +-
net/netlabel/netlabel_kapi.c | 32 ++++++++++++++++++++++++++++----
3 files changed, 37 insertions(+), 5 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH net v2 1/4] ipv4: validate ip_options length in __ip_options_echo() against skb tail
From: Qi Tang @ 2026-05-24 4:14 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: netdev, fw, lyutoon, stable, Qi Tang, David Ahern, Ido Schimmel,
Simon Horman
In-Reply-To: <20260524041442.2432071-1-tpluszz77@gmail.com>
__ip_options_echo() re-reads each option length byte (RR/TS/SRR/CIPSO)
from skb->data when building the echoed options into a 40-byte
__data[] buffer. __ip_options_compile() saved only the option offset
into IPCB(skb)->opt, not the length. An nftables LOCAL_IN payload
write reachable from an unprivileged user namespace can mutate the
length byte between parse and recvmsg, turning a parse-time validated
7-byte option into a 255-byte read.
unsigned char optbuf[sizeof(struct ip_options) + 40];
/* in __ip_options_echo: */
optlen = sptr[sopt->rr + 1]; /* re-read; nft can mutate */
memcpy(dptr, sptr + sopt->rr, optlen); /* into 40-byte buffer */
The destination is a stack buffer in ip_cmsg_recv_retopts() and a
DEFINE_RAW_FLEX() buffer in icmp.c / ip_output.c sized
IP_OPTIONS_DATA_FIXED_SIZE (40). KASAN reports a stack-out-of-bounds
write of size 255:
BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0x7fc/0x1310
Write of size 255 at addr ffff88800a657950
__asan_memcpy+0x3c/0x60
__ip_options_echo+0x7fc/0x1310
ip_cmsg_recv_offset+0x58b/0xd10
udp_recvmsg+0x8da/0xc20
____sys_recvmsg+0x1b1/0x620
Validate that each re-read option length stays within
skb_tail_pointer(skb) before the memcpy.
Cc: stable@vger.kernel.org
Reported-by: Qi Tang <tpluszz77@gmail.com>
Reported-by: Tong Liu <lyutoon@gmail.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Qi Tang <tpluszz77@gmail.com>
---
net/ipv4/ip_options.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/ipv4/ip_options.c b/net/ipv4/ip_options.c
index be8815ce3ac24..1cc6096e6dd9d 100644
--- a/net/ipv4/ip_options.c
+++ b/net/ipv4/ip_options.c
@@ -91,6 +91,8 @@ int __ip_options_echo(struct net *net, struct ip_options *dopt,
if (sopt->rr) {
optlen = sptr[sopt->rr+1];
+ if (sptr + sopt->rr + optlen > skb_tail_pointer(skb))
+ return -EINVAL;
soffset = sptr[sopt->rr+2];
dopt->rr = dopt->optlen + sizeof(struct iphdr);
memcpy(dptr, sptr+sopt->rr, optlen);
@@ -105,6 +107,8 @@ int __ip_options_echo(struct net *net, struct ip_options *dopt,
}
if (sopt->ts) {
optlen = sptr[sopt->ts+1];
+ if (sptr + sopt->ts + optlen > skb_tail_pointer(skb))
+ return -EINVAL;
soffset = sptr[sopt->ts+2];
dopt->ts = dopt->optlen + sizeof(struct iphdr);
memcpy(dptr, sptr+sopt->ts, optlen);
@@ -145,6 +149,8 @@ int __ip_options_echo(struct net *net, struct ip_options *dopt,
__be32 faddr;
optlen = start[1];
+ if (start + optlen > skb_tail_pointer(skb))
+ return -EINVAL;
soffset = start[2];
doffset = 0;
if (soffset > optlen)
@@ -174,6 +180,8 @@ int __ip_options_echo(struct net *net, struct ip_options *dopt,
}
if (sopt->cipso) {
optlen = sptr[sopt->cipso+1];
+ if (sptr + sopt->cipso + optlen > skb_tail_pointer(skb))
+ return -EINVAL;
dopt->cipso = dopt->optlen+sizeof(struct iphdr);
memcpy(dptr, sptr+sopt->cipso, optlen);
dptr += optlen;
--
2.47.3
^ permalink raw reply related
* [PATCH net v2 2/4] ipv4: ipmr: clamp ip_hdrlen against skb_headlen in ipmr_cache_report
From: Qi Tang @ 2026-05-24 4:14 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: netdev, fw, lyutoon, stable, Qi Tang, David Ahern, Ido Schimmel,
Simon Horman
In-Reply-To: <20260524041442.2432071-1-tpluszz77@gmail.com>
ipmr_cache_report() copies ip_hdrlen(pkt) bytes from pkt->data into
a freshly allocated 128-byte skb that is delivered to userspace via
the mrouted IGMP raw socket and via igmpmsg_netlink_event:
const int ihl = ip_hdrlen(pkt);
...
skb_put(skb, ihl);
skb_copy_to_linear_data(skb, pkt->data, ihl);
ip_rcv_core() validates iph->ihl and pskb_may_pull()s ihl*4 bytes at
parse time. An nftables PRE_ROUTING payload write reachable from an
unprivileged user namespace can flip the ihl nibble from 5 to 15
between parse and ipmr_cache_report(). When the original skb is
non-linear (received via a NIC driver that uses paged frags), only
the parse-time ihl*4 = 20 bytes are in the linear region; the
consumer copies 60 bytes, and the extra 40 bytes are read from
skb_shared_info or adjacent slab memory and queued back to userspace,
a kernel heap-content infoleak. PoC observation: recvfrom on the
mroute socket returns 28 bytes without mutation, 68 bytes with
mutation (40 extra bytes leaked).
Clamp ihl against skb_headlen(pkt) so only bytes actually present
in the linear region are copied.
Cc: stable@vger.kernel.org
Reported-by: Qi Tang <tpluszz77@gmail.com>
Reported-by: Tong Liu <lyutoon@gmail.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Qi Tang <tpluszz77@gmail.com>
---
net/ipv4/ipmr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 2628cd3a93a68..b40f3dd8f650f 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1056,7 +1056,7 @@ static void ipmr_cache_resolve(struct net *net, struct mr_table *mrt,
static int ipmr_cache_report(const struct mr_table *mrt,
struct sk_buff *pkt, vifi_t vifi, int assert)
{
- const int ihl = ip_hdrlen(pkt);
+ const int ihl = min_t(int, ip_hdrlen(pkt), skb_headlen(pkt));
struct sock *mroute_sk;
struct igmphdr *igmp;
struct igmpmsg *msg;
--
2.47.3
^ permalink raw reply related
* [PATCH net v2 3/4] netlabel: validate CALIPSO option against skb tail in netlbl_skbuff_getattr
From: Qi Tang @ 2026-05-24 4:14 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: netdev, fw, lyutoon, stable, Qi Tang, Paul Moore, Simon Horman,
Huw Davies, linux-security-module
In-Reply-To: <20260524041442.2432071-1-tpluszz77@gmail.com>
netlbl_skbuff_getattr() locates the CALIPSO option in the IPv6 HBH
header via calipso_optptr() and hands the bare pointer to
calipso_getattr() -> calipso_opt_getattr(). The consumer re-reads
calipso[1] (option data length) and calipso[6] (cat_len/4) and walks
calipso + 10 for cat_len bytes via netlbl_bitmap_walk().
ipv6_hop_calipso() validates these bytes only at parse time inside
ipv6_parse_hopopts(). An nftables PRE_ROUTING payload write reachable
from an unprivileged user namespace can rewrite both bytes between
parse and the SELinux peer-label consume path
(selinux_sock_rcv_skb_compat -> selinux_netlbl_sock_rcv_skb ->
netlbl_skbuff_getattr). The self-consistency check
(cat_len + 8 > len) inside calipso_opt_getattr() is defeated by
mutating both bytes consistently, allowing a ~232-byte
slab-out-of-bounds read from calipso + 10 whose set bits become MLS
categories driving the access decision.
netlbl_skbuff_getattr() has the skb; gate the consume on the option
fitting within skb_tail_pointer(). The IPv6 option layout is
type(1) + length(1) + length bytes of data, so requiring
ptr + 2 + ptr[1] <= skb_tail covers the option and its embedded
bitmap. When the bounds check fails the packet has been mutated
after parse, so return -EINVAL rather than fall through to the
unlabeled path.
Runtime confirmation (SELinux compat path with selinux=1 enforcing=0
and a CALIPSO DOI added via netlabelctl): Udp6InDatagrams increments
to 1 with the mutated cat_len, showing
selinux_socket_sock_rcv_skb -> netlbl_skbuff_getattr ->
calipso_opt_getattr -> netlbl_bitmap_walk runs end-to-end past the
option's true bound; with this patch the consume path returns
-EINVAL at the bounds check and the counter stays 0.
Cc: stable@vger.kernel.org
Reported-by: Qi Tang <tpluszz77@gmail.com>
Reported-by: Tong Liu <lyutoon@gmail.com>
Fixes: 2917f57b6bc1 ("calipso: Allow the lsm to label the skbuff directly.")
Signed-off-by: Qi Tang <tpluszz77@gmail.com>
---
net/netlabel/netlabel_kapi.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 3583fa63dd01f..d0d6220b8d59d 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -1399,11 +1399,22 @@ int netlbl_skbuff_getattr(const struct sk_buff *skb,
return 0;
break;
#if IS_ENABLED(CONFIG_IPV6)
- case AF_INET6:
+ case AF_INET6: {
+ const unsigned char *tail = skb_tail_pointer(skb);
+ u8 opt_data_len;
+
ptr = calipso_optptr(skb);
- if (ptr && calipso_getattr(ptr, secattr) == 0)
+ if (!ptr)
+ break;
+ if (ptr + 2 > tail)
+ return -EINVAL;
+ opt_data_len = ptr[1]; /* IPv6 option data length */
+ if (ptr + 2 + opt_data_len > tail)
+ return -EINVAL;
+ if (calipso_getattr(ptr, secattr) == 0)
return 0;
break;
+ }
#endif /* IPv6 */
}
--
2.47.3
^ permalink raw reply related
* [PATCH net v2 4/4] netlabel: validate CIPSO option against skb tail in netlbl_skbuff_getattr
From: Qi Tang @ 2026-05-24 4:14 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet
Cc: netdev, fw, lyutoon, stable, Qi Tang, Paul Moore, Simon Horman,
linux-security-module
In-Reply-To: <20260524041442.2432071-1-tpluszz77@gmail.com>
netlbl_skbuff_getattr() locates the CIPSO option in the IPv4 IP header
via cipso_v4_optptr() and hands the bare pointer to cipso_v4_getattr().
The consumer re-reads cipso[1] (option length), cipso[6] (tag type),
and then cipso_v4_parsetag_*() re-reads further bytes from the skb.
__ip_options_compile() validates these bytes only at parse time. An
nftables LOCAL_IN payload write reachable from an unprivileged user
namespace can rewrite them after parse and before the SELinux/Smack
peer-label consume path (selinux_sock_rcv_skb_compat ->
selinux_netlbl_sock_rcv_skb -> netlbl_skbuff_getattr). This is the
IPv4 analogue of the CALIPSO IPv6 trust-after-modification fixed in
the previous patch: the tag parsers walk the option using attacker-
controlled length bytes, producing slab-out-of-bounds reads whose
contents feed into the MLS access decision.
Validate the option fits within skb_tail_pointer(skb) before invoking
cipso_v4_getattr(). The pre-tag-walk guard "ptr + 8 > tail" covers
the CIPSO option header (type + length + DOI = 6 bytes) plus the
first tag header (type + length = 2 bytes), which are the bytes
cipso_v4_getattr() reads to dispatch on the tag. When the bounds
check fails the packet has been mutated after parse, so return
-EINVAL rather than fall through to the unlabeled path.
Runtime confirmation (Smack peer-label policy + nft LOCAL_IN
mutation of tag_len): UdpInDatagrams increments to 1 and recvfrom
returns the payload, showing netlbl_skbuff_getattr ->
cipso_v4_getattr -> cipso_v4_parsetag_rbm -> netlbl_bitmap_walk runs
end-to-end past the option's true bound; with this patch the
consume path returns -EINVAL at the bounds check and the counter
stays 0.
Cc: stable@vger.kernel.org
Reported-by: Qi Tang <tpluszz77@gmail.com>
Reported-by: Tong Liu <lyutoon@gmail.com>
Fixes: 04f81f0154e4 ("cipso: don't use IPCB() to locate the CIPSO IP option")
Signed-off-by: Qi Tang <tpluszz77@gmail.com>
---
net/netlabel/netlabel_kapi.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index d0d6220b8d59d..c2d3ea751f4e1 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -1393,11 +1393,24 @@ int netlbl_skbuff_getattr(const struct sk_buff *skb,
unsigned char *ptr;
switch (family) {
- case AF_INET:
+ case AF_INET: {
+ const unsigned char *tail = skb_tail_pointer(skb);
+ u8 opt_len, tag_len;
+
ptr = cipso_v4_optptr(skb);
- if (ptr && cipso_v4_getattr(ptr, secattr) == 0)
+ if (!ptr)
+ break;
+ /* CIPSO header (type+len+DOI = 6) + first tag header (type+len = 2) */
+ if (ptr + 8 > tail)
+ return -EINVAL;
+ opt_len = ptr[1]; /* total CIPSO option length */
+ tag_len = ptr[7]; /* first tag length */
+ if (ptr + opt_len > tail || ptr + 6 + tag_len > tail)
+ return -EINVAL;
+ if (cipso_v4_getattr(ptr, secattr) == 0)
return 0;
break;
+ }
#if IS_ENABLED(CONFIG_IPV6)
case AF_INET6: {
const unsigned char *tail = skb_tail_pointer(skb);
--
2.47.3
^ permalink raw reply related
* [PATCH] accel/ethosu: fix integer overflow in dma_length()
From: Muhammad Bilal @ 2026-05-24 5:16 UTC (permalink / raw)
To: robh
Cc: tomeu, ogabbay, tzimmermann, Frank.Li, dri-devel, linux-kernel,
stable, Muhammad Bilal
dma_length() computes the total DMA transfer length as:
len = ((len + stride[0]) * size0 + stride[1]) * size1
where len and stride[] are 64-bit values derived from user-supplied
40-bit command stream fields, and size0/size1 are user-supplied u16
values.
The final multiplication by size1 (up to 65535) on an intermediate
result that can already be ~2^55 easily exceeds 2^64, wrapping the
u64 result to a small positive value.
This wrapped value is then stored in info->region_size[] and compared
against gem->size in ethosu_job.c:
if (cmd_info->region_size[i] > gem->size)
return -EOVERFLOW;
A userspace caller can craft stride and size values so that the
calculated length wraps to zero or a small value, passing this check
while the hardware executes a DMA transfer with the original large
strides, accessing memory far outside the GEM buffer.
Fix by replacing the unchecked multiplications with
check_mul_overflow(), returning U64_MAX on overflow. The callers
of dma_length() already treat U64_MAX as an error sentinel.
Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
drivers/accel/ethosu/ethosu_gem.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/accel/ethosu/ethosu_gem.c b/drivers/accel/ethosu/ethosu_gem.c
index 5a02285a4986..1f132611a6ce 100644
--- a/drivers/accel/ethosu/ethosu_gem.c
+++ b/drivers/accel/ethosu/ethosu_gem.c
@@ -2,6 +2,7 @@
/* Copyright 2025 Arm, Ltd. */
#include <linux/err.h>
+#include <linux/overflow.h>
#include <linux/slab.h>
#include <drm/ethosu_accel.h>
@@ -165,11 +166,13 @@ static u64 dma_length(struct ethosu_validated_cmdstream_info *info,
if (mode >= 1) {
len += dma->stride[0];
- len *= dma_st->size0;
+ if (check_mul_overflow(len, (u64)dma_st->size0, &len))
+ return U64_MAX;
}
if (mode == 2) {
len += dma->stride[1];
- len *= dma_st->size1;
+ if (check_mul_overflow(len, (u64)dma_st->size1, &len))
+ return U64_MAX;
}
if (dma->region >= 0)
info->region_size[dma->region] = max(info->region_size[dma->region],
--
2.53.0
^ permalink raw reply related
* [PATCH v2] accel/ethosu: fix integer overflow and underflow in dma_length()
From: Muhammad Bilal @ 2026-05-24 6:06 UTC (permalink / raw)
To: robh
Cc: tomeu, ogabbay, tzimmermann, Frank.Li, dri-devel, linux-kernel,
stable, Muhammad Bilal
In-Reply-To: <20260524051659.70654-1-meatuni001@gmail.com>
dma_length() computes the total DMA transfer length as:
len = ((len + stride[0]) * size0 + stride[1]) * size1
where len and stride[] are 64-bit values derived from user-supplied
40-bit command stream fields, and size0/size1 are user-supplied u16
values.
Two bugs exist:
1. Integer overflow: the final multiplication by size1 (up to 65535)
on an intermediate result that can already be ~2^55 easily exceeds
2^64, wrapping the u64 result to a small positive value. This
wrapped value passes the region_size[i] <= gem->size check in
ethosu_job.c while the hardware executes DMA with the original
large strides, accessing memory outside the GEM buffer.
2. Negative stride underflow: stride[0] and stride[1] are signed
64-bit values sign-extended from 40-bit user input, and can be
negative. Adding a large negative stride to a small u64 len wraps
to a huge value. With size0 or size1 == 1, check_mul_overflow()
does not trigger, and len + offset can wrap back to a small value,
bypassing the bounds check while the hardware accesses memory below
the GEM buffer base.
3. Missing caller check: dma_length() returned U64_MAX on error but
the caller only used the result for dev_dbg(), never checking for
U64_MAX. This left info->region_size[] at 0, causing ethosu_job.c
to skip the region entirely and allow hardware to run with stale
physical addresses.
Fix by adding underflow checks before each stride addition, replacing
the unchecked multiplications with check_mul_overflow(), and adding
a U64_MAX check in the caller that returns -EINVAL.
Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
drivers/accel/ethosu/ethosu_gem.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/accel/ethosu/ethosu_gem.c b/drivers/accel/ethosu/ethosu_gem.c
index 5a02285a4986..0383b7a6c3d3 100644
--- a/drivers/accel/ethosu/ethosu_gem.c
+++ b/drivers/accel/ethosu/ethosu_gem.c
@@ -2,6 +2,7 @@
/* Copyright 2025 Arm, Ltd. */
#include <linux/err.h>
+#include <linux/overflow.h>
#include <linux/slab.h>
#include <drm/ethosu_accel.h>
@@ -164,12 +165,18 @@ static u64 dma_length(struct ethosu_validated_cmdstream_info *info,
u64 len = dma->len;
if (mode >= 1) {
+ if (dma->stride[0] < 0 && (u64)(-dma->stride[0]) > len)
+ return U64_MAX;
len += dma->stride[0];
- len *= dma_st->size0;
+ if (check_mul_overflow(len, (u64)dma_st->size0, &len))
+ return U64_MAX;
}
if (mode == 2) {
+ if (dma->stride[1] < 0 && (u64)(-dma->stride[1]) > len)
+ return U64_MAX;
len += dma->stride[1];
- len *= dma_st->size1;
+ if (check_mul_overflow(len, (u64)dma_st->size1, &len))
+ return U64_MAX;
}
if (dma->region >= 0)
info->region_size[dma->region] = max(info->region_size[dma->region],
@@ -397,6 +404,8 @@ static int ethosu_gem_cmdstream_copy_and_validate(struct drm_device *ddev,
case NPU_OP_DMA_START:
srclen = dma_length(info, &st.dma, &st.dma.src);
dstlen = dma_length(info, &st.dma, &st.dma.dst);
+ if (srclen == U64_MAX || dstlen == U64_MAX)
+ return -EINVAL;
if (st.dma.dst.region >= 0)
info->output_region[st.dma.dst.region] = true;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] USB: iowarrior: fix use-after-free on disconnect
From: Greg Kroah-Hartman @ 2026-05-24 6:09 UTC (permalink / raw)
To: Johan Hovold
Cc: Joseph Bursey, linux-usb, linux-kernel,
syzbot+ad2aac2febc3bedf0962, stable
In-Reply-To: <20260523170523.1074563-1-johan@kernel.org>
On Sat, May 23, 2026 at 07:05:23PM +0200, Johan Hovold wrote:
> Submitted write URBs are not stopped on close() and therefore need to be
> stopped unconditionally on disconnect() to avoid use-after-free in the
> completion handler.
>
> Fixes: b5f8d46867ca ("USB: iowarrior: fix use-after-free after driver unbind")
> Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
> Reported-by: syzbot+ad2aac2febc3bedf0962@syzkaller.appspotmail.com
> Link: https://lore.kernel.org/all/6a0ce39b.170a0220.39a13.0007.GAE@google.com/
> Cc: stable@vger.kernel.org
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH net v3] xfrm: iptfs: preserve shared-frag marker in iptfs_consume_frags()
From: Christian Hopps @ 2026-05-24 6:19 UTC (permalink / raw)
To: Takao Sato; +Cc: netdev, steffen.klassert, w, davem, herbert, stable
In-Reply-To: <20260522142504.1394864-1-takaosato1997@gmail.com>
Takao Sato <takaosato1997@gmail.com> writes:
> iptfs_consume_frags() transfers paged fragments from one socket buffer
> to another but fails to propagate the SKBFL_SHARED_FRAG flag. This is
> the same class of bug that was fixed in skb_try_coalesce() for
> CVE-2026-46300: when fragments backed by read-only page-cache pages are
> merged, the marker indicating their shared nature must be preserved so
> that ESP can decide correctly whether in-place encryption is safe.
>
> Apply the same two-line fix used in skb_try_coalesce() to
> iptfs_consume_frags().
>
> Fixes: b96ba312e21c ("xfrm: iptfs: share page fragments of inner packets")
> Cc: stable@vger.kernel.org # 6.8+
> Signed-off-by: Takao Sato <takaosato1997@gmail.com>
> ---
> net/xfrm/xfrm_iptfs.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/xfrm/xfrm_iptfs.c b/net/xfrm/xfrm_iptfs.c
> index 97bc979e5..4db85e158 100644
> --- a/net/xfrm/xfrm_iptfs.c
> +++ b/net/xfrm/xfrm_iptfs.c
> @@ -2168,6 +2168,8 @@ static void iptfs_consume_frags(struct sk_buff *to, struct sk_buff *from)
> memcpy(&toi->frags[toi->nr_frags], fromi->frags,
> sizeof(fromi->frags[0]) * fromi->nr_frags);
> toi->nr_frags += fromi->nr_frags;
> + if (fromi->nr_frags)
> + toi->flags |= fromi->flags & SKBFL_SHARED_FRAG;
> fromi->nr_frags = 0;
> from->data_len = 0;
> from->len = 0;
LGTM, Thanks!
Reviewed-by: Christian Hopps <chopps@labn.net>
^ permalink raw reply
* Re: [PATCH] uio: fix IRQ vector leak on probe failure and remove
From: Guangshuo Li @ 2026-05-24 6:29 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Yaxing Guo, linux-kernel, stable
In-Reply-To: <2026052229-overspend-preoccupy-2f6f@gregkh>
Hi Greg,
Thank you for reviewing the patch.
On Fri, 22 May 2026 at 18:03, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Thu, Apr 16, 2026 at 11:54:43PM +0800, Guangshuo Li wrote:
> > probe() allocates MSI/MSI-X vectors with pci_alloc_irq_vectors(), but
> > neither the error path nor remove() releases them with
> > pci_free_irq_vectors().
> >
> > Unlike drivers using pcim_enable_device(), this driver uses
> > pci_enable_device(), so the IRQ vectors are not managed automatically
> > and must be freed explicitly.
> >
> > Add pci_free_irq_vectors() to the probe error path after successful
> > vector allocation and to remove(). The issue was identified by a
> > static analysis tool I developed.
> >
> > Fixes: 3397c3cd859a ("uio: Add SVA support for PCI devices via uio_pci_generic_sva.c")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> > ---
> > drivers/uio/uio_pci_generic_sva.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/uio/uio_pci_generic_sva.c b/drivers/uio/uio_pci_generic_sva.c
> > index 4a46acd994a8..ea531f9a164c 100644
> > --- a/drivers/uio/uio_pci_generic_sva.c
> > +++ b/drivers/uio/uio_pci_generic_sva.c
> > @@ -62,7 +62,7 @@ static int uio_pci_sva_release(struct uio_info *info, struct inode *inode)
> > static int probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > {
> > struct uio_pci_sva_dev *udev;
> > - int ret, i, irq = 0;
> > + int ret, i, irq = 0, have_irq_vectors = 0;
>
> have_irq_vectors should be a bool.
I will change have_irq_vectors to a bool and send a v2.
Best regards,
Guangshuo
^ permalink raw reply
* [PATCH v2] uio: fix IRQ vector leak on probe failure and remove
From: Guangshuo Li @ 2026-05-24 6:42 UTC (permalink / raw)
To: Greg Kroah-Hartman, Yaxing Guo, linux-kernel; +Cc: Guangshuo Li, stable
probe() allocates MSI/MSI-X vectors with pci_alloc_irq_vectors(), but
neither the error path nor remove() releases them with
pci_free_irq_vectors().
Unlike drivers using pcim_enable_device(), this driver uses
pci_enable_device(), so the IRQ vectors are not managed automatically
and must be freed explicitly.
Add pci_free_irq_vectors() to the probe error path after successful
vector allocation and to remove(). The issue was identified by a
static analysis tool I developed.
Fixes: 3397c3cd859a ("uio: Add SVA support for PCI devices via uio_pci_generic_sva.c")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
v2:
- Change have_irq_vectors from int to bool.
- Set have_irq_vectors immediately after successful IRQ vector allocation.
drivers/uio/uio_pci_generic_sva.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/uio/uio_pci_generic_sva.c b/drivers/uio/uio_pci_generic_sva.c
index 4a46acd994a8..e216436c9116 100644
--- a/drivers/uio/uio_pci_generic_sva.c
+++ b/drivers/uio/uio_pci_generic_sva.c
@@ -63,6 +63,7 @@ static int probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct uio_pci_sva_dev *udev;
int ret, i, irq = 0;
+ bool have_irq_vectors = false;
ret = pci_enable_device(pdev);
if (ret) {
@@ -78,6 +79,8 @@ static int probe(struct pci_dev *pdev, const struct pci_device_id *id)
ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_MSIX | PCI_IRQ_MSI);
if (ret > 0) {
+ have_irq_vectors = true;
+
irq = pci_irq_vector(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "Failed to get MSI vector\n");
@@ -139,6 +142,8 @@ static int probe(struct pci_dev *pdev, const struct pci_device_id *id)
out_free:
kfree(udev);
out_disable:
+ if (have_irq_vectors)
+ pci_free_irq_vectors(pdev);
pci_disable_device(pdev);
return ret;
@@ -148,6 +153,7 @@ static void remove(struct pci_dev *pdev)
{
struct uio_pci_sva_dev *udev = pci_get_drvdata(pdev);
+ pci_free_irq_vectors(pdev);
pci_release_regions(pdev);
pci_disable_device(pdev);
kfree(udev);
--
2.43.0
^ permalink raw reply related
* [PATCH net] octeontx2-af: cn10k: restrict LMTLINE sharing to same PF
From: Junrui Luo @ 2026-05-24 7:29 UTC (permalink / raw)
To: Sunil Goutham, Linu Cherian, Geetha sowjanya, hariprasad,
Subbaraya Sundeep, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: netdev, linux-kernel, Yuhao Jiang, stable, Junrui Luo
rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct
index into the LMT map table to read another function's LMTLINE
physical base address and copy it into the caller's own LMT map table
entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the
IRQ source, but req->base_pcifunc is a separate payload field and is
not sanitized.
Reject the request with -EPERM when the caller and base function do
not share a parent PF.
Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST regions")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
index d2163da28d18..0c27b4b669f1 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_cn10k.c
@@ -178,6 +178,13 @@ int rvu_mbox_handler_lmtst_tbl_setup(struct rvu *rvu,
* pcifunc (will be the one who is calling this mailbox).
*/
if (req->base_pcifunc) {
+ /* Only allow LMTLINE sharing within the same PF, so that a
+ * PCI function cannot hijack another PF's LMTLINE region.
+ */
+ if (rvu_get_pf(rvu->pdev, req->hdr.pcifunc) !=
+ rvu_get_pf(rvu->pdev, req->base_pcifunc))
+ return -EPERM;
+
/* Calculating the LMT table index equivalent to primary
* pcifunc.
*/
---
base-commit: c369299895a591d96745d6492d4888259b004a9e
change-id: 20260524-fixes-33bb6d8cccf8
Best regards,
--
Junrui Luo <moonafterrain@outlook.com>
^ permalink raw reply related
* Re: [PATCH] ARM: entry: use byte load for KASAN VMAP stack shadow
From: Karl Mehltretter @ 2026-05-24 7:49 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Russell King (Oracle), linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <CAD++jLnhONOMn=7hG-EC_uB80nxXfAnRMuZC2xoJjf2Xzcaiuw@mail.gmail.com>
On Sun, May 24, 2026 at 12:08:57AM +0100, Linus Walleij wrote:
> Please put this patch into Russell's patch tracker.
Done: https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9475/1
Thanks,
Karl
^ permalink raw reply
* Re: [PATCH] ARM: io: avoid KASAN instrumentation of raw halfword I/O
From: Karl Mehltretter @ 2026-05-24 8:09 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Abbott Liu, Ard Biesheuvel, Florian Fainelli,
linux-arm-kernel, linux-kernel, stable
In-Reply-To: <CAD++jL=jrk4EYo+5mhp1cpy2cfsA966MVmbohWhcZdx_SObD_w@mail.gmail.com>
On Sun, May 24, 2026 at 12:11:36AM +0100, Linus Walleij wrote:
> Please put this patch into Russell's patch tracker.
Done: https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9474/1
Thanks,
Karl
^ permalink raw reply
* [RFC/PROPOSAL] Shifting the x.y.z Stable Tree to a Continuous, Signed Patch-Stream Model
From: Artem S. Tashkinov @ 2026-05-24 9:38 UTC (permalink / raw)
To: Linux Kernel Mailing List, Greg Kroah-Hartman, Sasha Levin,
stable
Hi all,
The relentless cadence of critical vulnerability disclosures and public
exploits over the past month—including Copy Fail (CVE-2026-31431), Dirty
Frag (CVE-2026-43284/500), Fragnesia (CVE-2026-46300), and the ptrace
exit race (CVE-2026-46333)—has highlighted a severe structural
bottleneck in how we package and distribute stable backports.
When fatal logic flaws or memory corruptions strike core subsystems, our
current point-release model fractures. Spinning up whole new point
releases (7.0.4, 7.0.5, 7.0.7) in a matter of days just to address
incomplete fixes, subsystem regressions, or independent public
disclosures (such as the recent GRO managed-frag UAF exploit dropped
directly to GitHub gists by researchers) creates massive administrative
fatigue for maintainers and downstream teams alike.
Upstream has long maintained that the stable tree is effectively a
continuous stream of fixes, and that users should track the tip of the
stable branch rather than cherry-picking. It is time our release
infrastructure matches this reality.
### The Proposal
I propose transitioning the stable tree (`linux-x.y.y`) away from
manual,discrete point-release tarballs (`x.y.z`). Instead, we should
treat the stable sub-version purely as an append-only, continuous,
git-native patch stream.
Major releases (e.g., 7.0, 7.1) remain the foundational code boundaries,
but sub-versions are eliminated as monolithic manual artifacts.
### The Implementation: How It Works
To ensure downstream distributions, enterprise compliance engines, and
automated testing rings can still securely ingest code, we can replace
the manual tarball with a decoupled, automated asset pipeline:
1. **The Git-First Stream:** The stable branch (`linux-7.0.y`) remains
the single source of truth. Commits are pushed as soon as they pass
stable criteria and automated sanity testing.
2. **The Signed Patch-Stream Archive:** Instead of packaging the entire
30M+ line source code tree into a new tarball for every quick fix,
upstream infrastructure maintains a rolling, cumulative patch sequence
for the major cycle:
linux-7.0-stable.series = \sum (patch_1 + patch_2 + ... + patch_n)
Every time a fix is merged to the stable branch, the patch is appended
to a publicly accessible, cryptographically signed manifest file
(`linux-7.0-stable-patches.tar.bz2` or a standard `series` file)
alongside a detached signature.
3. **Automated Snapshot Tags:** If the industry strictly requires an
immutable archive for compliance, point-release numbers can be replaced
by automated, time-stamped git tags and machine-generated source
snapshots cut on a strict, automated interval (e.g., every 48 hours),
removing human maintainers entirely from the release timing.
### Why This Benefits the Ecosystem
* **Eliminates Churn and Latency:**
When a patch introduces an edge-case regression or requires an immediate
follow-up (a common reason for rapid point-release sequences),
maintainers do not need to coordinate a whole new release event. The
follow-up fix is simply patch $n+1$. Downstream CI pipelines ingest it
natively via standard git fetches.
* **Maintains Git-Native Debugging:**
Debugging stable regressions via `git bisect` has always been
patch-based, not release-based. Since point releases are meant strictly
for backported bug fixes, removing the arbitrary `x.y.z` release tags
changes nothing about a developer's ability to isolate a regression. If
anything, it prevents downstream vendors from pulling out-of-order
patches that complicate bisection across distros.
* **Eases Downstream Automation:**
Modern tracking distributions (Arch, Fedora snapshotting, etc.) can
switch to trunk-based intake, automatically building from the signed tip.
For enterprise distributions (RHEL, Ubuntu LTS) where constant kernel
packaging and reboots are untenable, a fluid patch stream allows vendor
security teams to more rapidly feed live-patching infrastructure
(`kpatch`, `kgraft`), applying critical CVE fixes directly to runtime
memory without changing the base package version.
* **Bridges the Compliance Gap:**
Embedded, automotive, or medical compliance pipelines
that legally require a static, verifiable code artifact can validate
their software against the base major release tarball ($7.0.0$) plus the
cryptographically signed, append-only stable patch series manifest.
The manual compilation, testing, and cutting of sub-version tarballs is
an administrative artifact of the late 1990s. Shifting to an explicit,
signed patch-stream architecture acknowledges the velocity of modern
vulnerability research, strips away artificial latency, and frees our
stable maintainers to focus on code quality rather than release
management overhead.
I would love to hear thoughts, architectural blockers, or feedback from
the stable maintainers and distribution teams on the feasibility of this
transition.
Best regards,
Artem S. Tashkinov
^ permalink raw reply
* [PATCH v3] accel/ethosu: fix arithmetic issues in dma_length()
From: Muhammad Bilal @ 2026-05-24 10:37 UTC (permalink / raw)
To: robh
Cc: tomeu, ogabbay, tzimmermann, Frank.Li, dri-devel, linux-kernel,
stable, Muhammad Bilal
In-Reply-To: <20260524060644.106635-1-meatuni001@gmail.com>
dma_length() derives DMA region usage from command stream values and
updates region_size[]:
len = ((len + stride[0]) * size0 + stride[1]) * size1
region_size[region] = max(..., len + dma->offset)
Several arithmetic issues can corrupt the derived region size:
- signed stride values may underflow when added to len
- intermediate multiplications may overflow
- len + dma->offset may overflow during region_size updates
- dma_length() error returns were not validated by the caller
region_size[] is later used by ethosu_job.c to validate command stream
accesses against GEM buffer sizes. Arithmetic wraparound can therefore
under-report region usage and bypass the bounds validation.
Fix by validating signed additions, using overflow helpers for
multiplications and offset updates, and propagating dma_length()
failures to the caller.
Fixes: 5a5e9c0228e6 ("accel: Add Arm Ethos-U NPU driver")
Cc: stable@vger.kernel.org
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
---
v3:
- add check_add_overflow() for len + dma->offset
- validate dma_length() return value in caller
- rework commit message to avoid unproven claims
v2:
- add negative stride underflow checks before each addition
- replace unchecked multiplications with check_mul_overflow()
drivers/accel/ethosu/ethosu_gem.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/accel/ethosu/ethosu_gem.c b/drivers/accel/ethosu/ethosu_gem.c
index 5a02285a4986..8e95539da98f 100644
--- a/drivers/accel/ethosu/ethosu_gem.c
+++ b/drivers/accel/ethosu/ethosu_gem.c
@@ -2,6 +2,7 @@
/* Copyright 2025 Arm, Ltd. */
#include <linux/err.h>
+#include <linux/overflow.h>
#include <linux/slab.h>
#include <drm/ethosu_accel.h>
@@ -164,16 +165,26 @@ static u64 dma_length(struct ethosu_validated_cmdstream_info *info,
u64 len = dma->len;
if (mode >= 1) {
+ if (dma->stride[0] < 0 && (u64)(-dma->stride[0]) > len)
+ return U64_MAX;
len += dma->stride[0];
- len *= dma_st->size0;
+ if (check_mul_overflow(len, (u64)dma_st->size0, &len))
+ return U64_MAX;
}
if (mode == 2) {
+ if (dma->stride[1] < 0 && (u64)(-dma->stride[1]) > len)
+ return U64_MAX;
len += dma->stride[1];
- len *= dma_st->size1;
+ if (check_mul_overflow(len, (u64)dma_st->size1, &len))
+ return U64_MAX;
+ }
+ if (dma->region >= 0) {
+ u64 end;
+
+ if (check_add_overflow(len, dma->offset, &end))
+ return U64_MAX;
+ info->region_size[dma->region] = max(info->region_size[dma->region], end);
}
- if (dma->region >= 0)
- info->region_size[dma->region] = max(info->region_size[dma->region],
- len + dma->offset);
return len;
}
@@ -397,6 +408,8 @@ static int ethosu_gem_cmdstream_copy_and_validate(struct drm_device *ddev,
case NPU_OP_DMA_START:
srclen = dma_length(info, &st.dma, &st.dma.src);
dstlen = dma_length(info, &st.dma, &st.dma.dst);
+ if (srclen == U64_MAX || dstlen == U64_MAX)
+ return -EINVAL;
if (st.dma.dst.region >= 0)
info->output_region[st.dma.dst.region] = true;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 6.18 346/957] fuse: new work queue to periodically invalidate expired dentries
From: Luis Henriques @ 2026-05-24 10:53 UTC (permalink / raw)
To: Sasha Levin; +Cc: Greg Kroah-Hartman, stable, patches, Miklos Szeredi
In-Reply-To: <20260522123641.rc-drop-ab84ad597386@kernel.org>
On Fri, May 22 2026, Sasha Levin wrote:
> On Wed, May 20, 2026 at 08:45:09PM +0200, Miklos Szeredi wrote:
>> This is not stable material, and I don't think the dependency is real.
>>
>> Just need to resolve the trivial conflict when applying 5a6baf204610
>> ("fuse: fix uninit-value in fuse_dentry_revalidate()")
>
> Dropped from the 6.18 queue along with the following Stable-dep-of /
> Fixes-of patches that no longer apply without it:
>
> - dcache: export shrink_dentry_list() and add new helper d_dispose_if_unused()
> - fuse: fix uninit-value in fuse_dentry_revalidate()
> - fuse: fix race when disposing stale dentries
> - fuse: make sure dentry is evicted if stale
>
> If anyone wants to send a backport of 5a6baf204610, we can apply it.
Below is a attempt at the backporting. I had to enable ->d_init/d_release
operations unconditionally, so that dentries d_time could be initialised.
(Maybe d_release could be left out.) It doesn't look pretty, but I guess
it's the solution closer to upstream.
Cheers,
--
Luís
From 3000e3b879f66afb47d22f360567c546ca9214ad Mon Sep 17 00:00:00 2001
From: Luis Henriques <luis@igalia.com>
Date: Mon, 16 Feb 2026 14:48:30 +0000
Subject: [PATCH] fuse: fix uninit-value in fuse_dentry_revalidate()
commit 5a6baf204610589f8a5b5a1cd69d1fe661d9d3cd upstream.
fuse_dentry_revalidate() may be called with a dentry that didn't had
->d_time initialised. The issue was found with KMSAN, where lookup_open()
calls __d_alloc(), followed by d_revalidate(), as shown below:
=====================================================
BUG: KMSAN: uninit-value in fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394
fuse_dentry_revalidate+0x150/0x13d0 fs/fuse/dir.c:394
d_revalidate fs/namei.c:1030 [inline]
lookup_open fs/namei.c:4405 [inline]
open_last_lookups fs/namei.c:4583 [inline]
path_openat+0x1614/0x64c0 fs/namei.c:4827
do_file_open+0x2aa/0x680 fs/namei.c:4859
[...]
Uninit was created at:
slab_post_alloc_hook mm/slub.c:4466 [inline]
slab_alloc_node mm/slub.c:4788 [inline]
kmem_cache_alloc_lru_noprof+0x382/0x1280 mm/slub.c:4807
__d_alloc+0x55/0xa00 fs/dcache.c:1740
d_alloc_parallel+0x99/0x2740 fs/dcache.c:2604
lookup_open fs/namei.c:4398 [inline]
open_last_lookups fs/namei.c:4583 [inline]
path_openat+0x135f/0x64c0 fs/namei.c:4827
do_file_open+0x2aa/0x680 fs/namei.c:4859
[...]
=====================================================
Reported-by: syzbot+fdebb2dc960aa56c600a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/69917e0d.050a0220.340abe.02e2.GAE@google.com
Fixes: 2396356a945b ("fuse: add more control over cache invalidation behaviour")
Signed-off-by: Luis Henriques <luis@igalia.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
---
fs/fuse/dir.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index ecaec0fea3a1..1bc6982b5d6a 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -283,21 +283,33 @@ static int fuse_dentry_revalidate(struct inode *dir, const struct qstr *name,
goto out;
}
-#if BITS_PER_LONG < 64
static int fuse_dentry_init(struct dentry *dentry)
{
+ int ret = 0;
+
+ /*
+ * Initialising d_time (epoch) to '0' ensures the dentry is invalid
+ * if compared to fc->epoch, which is initialized to '1'.
+ */
+ dentry->d_time = 0;
+
+#if BITS_PER_LONG < 64
dentry->d_fsdata = kzalloc(sizeof(union fuse_dentry),
GFP_KERNEL_ACCOUNT | __GFP_RECLAIMABLE);
- return dentry->d_fsdata ? 0 : -ENOMEM;
+ ret = dentry->d_fsdata ? 0 : -ENOMEM;
+#endif
+
+ return ret;
}
static void fuse_dentry_release(struct dentry *dentry)
{
+#if BITS_PER_LONG < 64
union fuse_dentry *fd = dentry->d_fsdata;
kfree_rcu(fd, rcu);
-}
#endif
+}
static int fuse_dentry_delete(const struct dentry *dentry)
{
@@ -331,10 +343,8 @@ static struct vfsmount *fuse_dentry_automount(struct path *path)
const struct dentry_operations fuse_dentry_operations = {
.d_revalidate = fuse_dentry_revalidate,
.d_delete = fuse_dentry_delete,
-#if BITS_PER_LONG < 64
.d_init = fuse_dentry_init,
.d_release = fuse_dentry_release,
-#endif
.d_automount = fuse_dentry_automount,
};
^ permalink raw reply related
* Re: [RFC/PROPOSAL] Shifting the x.y.z Stable Tree to a Continuous, Signed Patch-Stream Model
From: Greg Kroah-Hartman @ 2026-05-24 10:56 UTC (permalink / raw)
To: Artem S. Tashkinov; +Cc: Linux Kernel Mailing List, Sasha Levin, stable
In-Reply-To: <cdb0dd2f-f331-46ed-8439-1609173f083a@gmx.com>
On Sun, May 24, 2026 at 01:38:55PM +0400, Artem S. Tashkinov wrote:
> Hi all,
>
> The relentless cadence of critical vulnerability disclosures and public
> exploits over the past month—including Copy Fail (CVE-2026-31431), Dirty
> Frag (CVE-2026-43284/500), Fragnesia (CVE-2026-46300), and the ptrace exit
> race (CVE-2026-46333)—has highlighted a severe structural bottleneck in how
> we package and distribute stable backports.
Who is "we"?
And there's nothing really "new" here, these issues are all normal,
remember, we resolve, on average, 13 CVEs a day, most much more severe
than the ones that happened to get marketing names that you list here
(and how many systems have untrusted users?)
> When fatal logic flaws or memory corruptions strike core subsystems, our
> current point-release model fractures. Spinning up whole new point releases
> (7.0.4, 7.0.5, 7.0.7) in a matter of days just to address incomplete fixes,
> subsystem regressions, or independent public disclosures (such as the recent
> GRO managed-frag UAF exploit dropped directly to GitHub gists by
> researchers) creates massive administrative fatigue for maintainers and
> downstream teams alike.
it takes just a minute to "spin up" a point release, what is difficult
about that? If needed, just let us know and we can easily do so.
> Upstream has long maintained that the stable tree is effectively a
> continuous stream of fixes, and that users should track the tip of the
> stable branch rather than cherry-picking. It is time our release
> infrastructure matches this reality.
>
> ### The Proposal
>
> I propose transitioning the stable tree (`linux-x.y.y`) away from
> manual,discrete point-release tarballs (`x.y.z`). Instead, we should treat
> the stable sub-version purely as an append-only, continuous, git-native
> patch stream.
That's what we do today, we just happen go "jump" on a weekly basis.
> Major releases (e.g., 7.0, 7.1) remain the foundational code boundaries, but
> sub-versions are eliminated as monolithic manual artifacts.
>
> ### The Implementation: How It Works
>
> To ensure downstream distributions, enterprise compliance engines, and
> automated testing rings can still securely ingest code, we can replace the
> manual tarball with a decoupled, automated asset pipeline:
>
> 1. **The Git-First Stream:** The stable branch (`linux-7.0.y`) remains the
> single source of truth. Commits are pushed as soon as they pass stable
> criteria and automated sanity testing.
Again, that's what we do today.
> 2. **The Signed Patch-Stream Archive:** Instead of packaging the entire 30M+
> line source code tree into a new tarball for every quick fix, upstream
> infrastructure maintains a rolling, cumulative patch sequence for the major
> cycle:
>
> linux-7.0-stable.series = \sum (patch_1 + patch_2 + ... + patch_n)
>
> Every time a fix is merged to the stable branch, the patch is appended to a
> publicly accessible, cryptographically signed manifest file
> (`linux-7.0-stable-patches.tar.bz2` or a standard `series` file) alongside a
> detached signature.
Who would use/need such a thing? What's wrong with the 2 systems we
have today that this would somehow help out with?
> 3. **Automated Snapshot Tags:** If the industry strictly requires an
> immutable archive for compliance,
What "compliance"?
> point-release numbers can be replaced by
> automated, time-stamped git tags and machine-generated source snapshots cut
> on a strict, automated interval (e.g., every 48 hours), removing human
> maintainers entirely from the release timing.
That's probably not a good idea anyway. Are you doing continous testing
of the stable queue? If so, great, just take from there today.
Everyone adds patches on top of releases anyway, what's a few more if it
happens to resolve specific issues for a day or so before a .y release
can be cut?
> ### Why This Benefits the Ecosystem
>
> * **Eliminates Churn and Latency:**
>
> When a patch introduces an edge-case regression or requires an immediate
> follow-up (a common reason for rapid point-release sequences), maintainers
> do not need to coordinate a whole new release event.
No real "coordination" happens here.
> The follow-up fix is simply patch $n+1$. Downstream CI pipelines
> ingest it natively via standard git fetches.
Again, we do that today.
> * **Maintains Git-Native Debugging:**
>
> Debugging stable regressions via `git bisect` has always been patch-based,
> not release-based. Since point releases are meant strictly for backported
> bug fixes, removing the arbitrary `x.y.z` release tags changes nothing about
> a developer's ability to isolate a regression. If anything, it prevents
> downstream vendors from pulling out-of-order patches that complicate
> bisection across distros.
Who bisects across distros?
> * **Eases Downstream Automation:**
>
> Modern tracking distributions (Arch, Fedora snapshotting, etc.) can switch
> to trunk-based intake, automatically building from the signed tip.
Have you asked them if they need/want this?
> For enterprise distributions (RHEL, Ubuntu LTS) where constant kernel
> packaging and reboots are untenable,
Why are reboots for these systems untenable? Why not fix that root
problem instead?
> a fluid patch stream allows vendor
> security teams to more rapidly feed live-patching infrastructure (`kpatch`,
> `kgraft`), applying critical CVE fixes directly to runtime memory without
> changing the base package version.
They can do that today, and do do that today. So again, what distro
needs this?
> * **Bridges the Compliance Gap:**
>
> Embedded, automotive, or medical compliance pipelines
> that legally require a static, verifiable code artifact can validate their
> software against the base major release tarball ($7.0.0$) plus the
> cryptographically signed, append-only stable patch series manifest.
Do they really need that? Again, they can have that today, nothing new
here.
> The manual compilation, testing, and cutting of sub-version tarballs is an
> administrative artifact of the late 1990s.
Weekly releases is not an artivact of the 1990s :)
> Shifting to an explicit, signed
> patch-stream architecture acknowledges the velocity of modern vulnerability
> research, strips away artificial latency, and frees our stable maintainers
> to focus on code quality rather than release management overhead.
Again, we have that today, on a weekly basis.
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox