Skip to content

[rocky9_8] History Rebuild through kernel-5.14.0-687.42.1.el9_8 - #1557

Open
PlaidCat wants to merge 17 commits into
rocky9_8from
rocky9_8_rebuild
Open

[rocky9_8] History Rebuild through kernel-5.14.0-687.42.1.el9_8#1557
PlaidCat wants to merge 17 commits into
rocky9_8from
rocky9_8_rebuild

Conversation

@PlaidCat

@PlaidCat PlaidCat commented Aug 27, 2026

Copy link
Copy Markdown
Collaborator

This is an automated kernel history rebuild using cron and internal tooling. It follows the same process used for previous history rebuilds:

  • Download all unprocessed src.rpm packages
  • For each src.rpm:
    • Identify all commits in the changelog up to the last known tag (5.14.0-687)
    • Replay commits in chronological order (oldest to newest in the changelog) using git cherry-pick
    • Replace the code in the branch with the output of rpmbuild -bp for the corresponding src.rpm
    • Tag the rebuild branch

JIRA Tickets

Rebuild Splat Inspection

kernel-5.14.0-687.42.1.el9_8

$ cat ciq/ciq_backports/kernel-5.14.0-687.42.1.el9_8/rebuild.details.txt
Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v5.14~1..kernel-mainline: 394115
Number of commits in rpm: 25
Number of commits matched with upstream: 16 (64.00%)
Number of commits in upstream but not in rpm: 394099
Number of commits NOT found in upstream: 9 (36.00%)

Rebuilding Kernel on Branch rocky9_8_rebuild_kernel-5.14.0-687.42.1.el9_8 for kernel-5.14.0-687.42.1.el9_8
Clean Cherry Picks: 12 (75.00%)
Empty Cherry Picks: 4 (25.00%)
_______________________________

__EMPTY COMMITS__________________________
f5548c318d6520d4fa3c5ed6003eeb710763cbc5 ksm: use range-walk function to jump over holes in scan_get_next_rmap_item
d38a87d7c0643db61e7a3bfc3ebeea2dc2568f7e s390/ap: Support driver_override for AP queue devices
8babcc2b6a75d1eced723a78cb67b3ff6abac8b0 s390/ap: Rename mutex ap_perms_mutex to ap_attr_mutex
46030379f13c3f07c699dcaf034a50f023f77925 s390/ap: Restrict driver_override versus apmask and aqmask use

__CHANGES NOT IN UPSTREAM________________
Replace sbat with Rocky Linux sbat
Change bug tracker URL
Ensure appended release in sbat is removed'
net: ipv6: clear suppressed fib6 rule result
Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count
Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count
netfilter: ipset: fix race between dump and ip_set_list resize
crypto: qat - cancel work on re-enable SR-IOV timeout
sctp: hold socket lock when dumping endpoints in sctp_diag

BUILD

$ grep -E -B 5 -A 5 "\[TIMER\]|^Starting Build" $(ls -t kbuild* | head -n1)
/mnt/code/kernel-src-tree-build
Running make mrproper...
  CLEAN   scripts/basic
  CLEAN   scripts/kconfig
  CLEAN   include/config include/generated
[TIMER]{MRPROPER}: 6s
x86_64 architecture detected, copying config
'configs/kernel-x86_64-rhel.config' -> '.config'
Setting Local Version for build
CONFIG_LOCALVERSION="-rocky9_8_rebuild-617ebf5ada6f"
Making olddefconfig
--
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
Starting Build
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
  SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
  SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
  SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
--
  LD [M]  sound/x86/snd-hdmi-lpe-audio.ko
  LD [M]  sound/xen/snd_xen_front.ko
  BTF [M] sound/virtio/virtio_snd.ko
  BTF [M] sound/x86/snd-hdmi-lpe-audio.ko
  BTF [M] sound/xen/snd_xen_front.ko
[TIMER]{BUILD}: 1635s
Making Modules
  INSTALL /lib/modules/5.14.0-rocky9_8_rebuild-617ebf5ada6f/kernel/arch/x86/crypto/blake2s-x86_64.ko
  INSTALL /lib/modules/5.14.0-rocky9_8_rebuild-617ebf5ada6f/kernel/arch/x86/crypto/blowfish-x86_64.ko
  INSTALL /lib/modules/5.14.0-rocky9_8_rebuild-617ebf5ada6f/kernel/arch/x86/crypto/camellia-aesni-avx-x86_64.ko
  INSTALL /lib/modules/5.14.0-rocky9_8_rebuild-617ebf5ada6f/kernel/arch/x86/crypto/camellia-aesni-avx2.ko
--
  SIGN    /lib/modules/5.14.0-rocky9_8_rebuild-617ebf5ada6f/kernel/sound/usb/usx2y/snd-usb-usx2y.ko
  SIGN    /lib/modules/5.14.0-rocky9_8_rebuild-617ebf5ada6f/kernel/sound/x86/snd-hdmi-lpe-audio.ko
  SIGN    /lib/modules/5.14.0-rocky9_8_rebuild-617ebf5ada6f/kernel/sound/xen/snd_xen_front.ko
  SIGN    /lib/modules/5.14.0-rocky9_8_rebuild-617ebf5ada6f/kernel/sound/usb/snd-usb-audio.ko
  DEPMOD  /lib/modules/5.14.0-rocky9_8_rebuild-617ebf5ada6f
[TIMER]{MODULES}: 10s
Making Install
sh ./arch/x86/boot/install.sh 5.14.0-rocky9_8_rebuild-617ebf5ada6f \
	arch/x86/boot/bzImage System.map "/boot"
[TIMER]{INSTALL}: 24s
Checking kABI
kABI check passed
Setting Default Kernel to /boot/vmlinuz-5.14.0-rocky9_8_rebuild-617ebf5ada6f and Index to 0
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 6s
[TIMER]{BUILD}: 1635s
[TIMER]{MODULES}: 10s
[TIMER]{INSTALL}: 24s
[TIMER]{TOTAL} 1680s
Rebooting in 10 seconds

KSelfTests

$ get_kselftest_diff.sh
kselftest.5.14.0-rocky9_8_rebuild-eb7eb89235d2.log
311
kselftest.5.14.0-rocky9_8_rebuild-ad60ad494aae.log
311
kselftest.5.14.0-rocky9_8_rebuild-c1e475b760c7.log
311
kselftest.5.14.0-rocky9_8_rebuild-617ebf5ada6f.log
311
Before: kselftest.5.14.0-rocky9_8_rebuild-c1e475b760c7.log
After: kselftest.5.14.0-rocky9_8_rebuild-617ebf5ada6f.log
Diff:
No differences found.

jira KERNEL-1530
cve CVE-2026-52924
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Xin Long <lucien.xin@gmail.com>
commit e374b22

sctp_stream_update() is only invoked when the association is moved into
COOKIE_WAIT during association setup/reconfiguration. In this path, the
outbound stream scheduler state (stream->out_curr) is expected to be
clean, since no user data should have been transmitted yet unless the
state machine has already partially progressed.

However, a corner case exists in sctp_sf_do_5_2_6_stale(): when a
Stale Cookie ERROR is received, the association is rolled back from
COOKIE_ECHOED to COOKIE_WAIT. In this scenario, user data may already
have been queued and even bundled with the COOKIE-ECHO chunk.

During the rollback, sctp_stream_update() frees the old stream table
and installs a new one, but it does not invalidate stream->out_curr.
As a result, out_curr may still point to a freed sctp_stream_out
entry from the previous stream state.

Later, SCTP scheduler dequeue paths (FCFS, RR, PRIO, etc.) rely on
stream->out_curr->ext, which can lead to use-after-free once the old
stream state has been released via sctp_stream_free().

This results in crashes such as (reported by Yuqi):

  BUG: KASAN: slab-use-after-free in sctp_sched_fcfs_dequeue+0x13a/0x140
  Read of size 8 at addr ff1100004d4d3208 by task mini_poc/9312
  CPU: 1 UID: 1001 PID: 9312 Comm: mini_poc Not tainted
     7.1.0-rc1-00305-gbd3a4795d574 #5 PREEMPT(full)
   sctp_sched_fcfs_dequeue+0x13a/0x140
   sctp_outq_flush+0x1603/0x33e0
   sctp_do_sm+0x31c9/0x5d30
   sctp_assoc_bh_rcv+0x392/0x6f0
   sctp_inq_push+0x1db/0x270
   sctp_rcv+0x138d/0x3c10

Fix this by fully purging the association outqueue when handling the
Stale Cookie case. This ensures all pending transmit and retransmit
state is dropped, and any scheduler cached pointers are invalidated,
making it safe to rebuild stream state during COOKIE_WAIT restart.

Updating only stream->out_curr would be insufficient, since queued
and retransmittable data would still reference the old stream state and
trigger later use-after-free in dequeue paths.

Fixes: 5bbbbe3 ("sctp: introduce stream scheduler foundations")
	Reported-by: Yuan Tan <yuantan098@gmail.com>
	Reported-by: Yifan Wu <yifanwucs@gmail.com>
	Reported-by: Juefei Pu <tomapufckgml@gmail.com>
	Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
	Reported-by: Xin Liu <bird@lzu.edu.cn>
	Reported-by: Yuqi Xu <xuyq21@lenovo.com>
	Reported-by: Ren Wei <n05ec@lzu.edu.cn>
	Signed-off-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/94318159b9052907a6cbb7256aee8b5f8dfbfccb.1780510304.git.lucien.xin@gmail.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit e374b22)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…piry

jira KERNEL-1530
cve CVE-2026-43114
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Florian Westphal <fw@strlen.de>
commit d3c0037

New test case fails unexpectedly when avx2 matching functions are used.

The test first loads a ranomly generated pipapo set
with 'ipv4 . port' key, i.e.  nft -f foo.

This works.  Then, it reloads the set after a flush:
(echo flush set t s; cat foo) | nft -f -

This is expected to work, because its the same set after all and it was
already loaded once.

But with avx2, this fails: nft reports a clashing element.

The reported clash is of following form:

    We successfully re-inserted
      a . b
      c . d

Then we try to insert a . d

avx2 finds the already existing a . d, which (due to 'flush set') is marked
as invalid in the new generation.  It skips the element and moves to next.

Due to incorrect masking, the skip-step finds the next matching
element *only considering the first field*,

i.e. we return the already reinserted "a . b", even though the
last field is different and the entry should not have been matched.

No such error is reported for the generic c implementation (no avx2) or when
the last field has to use the 'nft_pipapo_avx2_lookup_slow' fallback.

Bisection points to
7711f4b ("netfilter: nft_set_pipapo: fix range overlap detection")
but that fix merely uncovers this bug.

Before this commit, the wrong element is returned, but erronously
reported as a full, identical duplicate.

The root-cause is too early return in the avx2 match functions.
When we process the last field, we should continue to process data
until the entire input size has been consumed to make sure no stale
bits remain in the map.

Link: https://lore.kernel.org/netfilter-devel/20260321152506.037f68c0@elisabeth/
	Signed-off-by: Florian Westphal <fw@strlen.de>
	Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
	Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit d3c0037)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1530
cve CVE-2026-23003
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Eric Dumazet <edumazet@google.com>
commit 81c734d

Blamed commit did not take care of VLAN encapsulations
as spotted by syzbot [1].

Use skb_vlan_inet_prepare() instead of pskb_inet_may_pull().

[1]
 BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
 BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
 BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321
  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
  IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321
  ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729
  __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860
  ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903
 gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1
  ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438
  ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489
  NF_HOOK include/linux/netfilter.h:318 [inline]
  ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500
  ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590
  dst_input include/net/dst.h:474 [inline]
  ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79
  NF_HOOK include/linux/netfilter.h:318 [inline]
  ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311
  __netif_receive_skb_one_core net/core/dev.c:6139 [inline]
  __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252
  netif_receive_skb_internal net/core/dev.c:6338 [inline]
  netif_receive_skb+0x57/0x630 net/core/dev.c:6397
  tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485
  tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953
  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999
  new_sync_write fs/read_write.c:593 [inline]
  vfs_write+0xbe2/0x15d0 fs/read_write.c:686
  ksys_write fs/read_write.c:738 [inline]
  __do_sys_write fs/read_write.c:749 [inline]
  __se_sys_write fs/read_write.c:746 [inline]
  __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746
  x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Uninit was created at:
  slab_post_alloc_hook mm/slub.c:4960 [inline]
  slab_alloc_node mm/slub.c:5263 [inline]
  kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315
  kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586
  __alloc_skb+0x805/0x1040 net/core/skbuff.c:690
  alloc_skb include/linux/skbuff.h:1383 [inline]
  alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712
  sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995
  tun_alloc_skb drivers/net/tun.c:1461 [inline]
  tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794
  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999
  new_sync_write fs/read_write.c:593 [inline]
  vfs_write+0xbe2/0x15d0 fs/read_write.c:686
  ksys_write fs/read_write.c:738 [inline]
  __do_sys_write fs/read_write.c:749 [inline]
  __se_sys_write fs/read_write.c:746 [inline]
  __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746
  x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2
  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
  do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025

Fixes: 8d975c1 ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")
	Reported-by: syzbot+d4dda070f833dc5dc89a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/695e88b2.050a0220.1c677c.036d.GAE@google.com/T/#u
	Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260107163109.4188620-1-edumazet@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 81c734d)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1530
cve CVE-2026-53185
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Cunlong Li <shenxiaogll@gmail.com>
commit 732fd9f

zram_read_page() picks the sync or async backing device read path based on
whether the parent bio is NULL.  zram_bvec_write_partial() passes its
parent bio down, so for ZRAM_WB slots the read is dispatched
asynchronously and zram_read_page() returns 0 while the bio is still in
flight.  The caller then runs memcpy_from_bvec(), zram_write_page() and
__free_page() on the buffer, leaving the async read to write into a freed
page.

zram_bvec_read_partial() was switched to NULL in commit 4e3c87b
("zram: fix synchronous reads") for the same reason; the write_partial
counterpart was missed.

Link: https://lore.kernel.org/20260528-zram-v3-1-cab86eef8764@gmail.com
Fixes: 8e654f8 ("zram: read page from backing device")
	Reviewed-by: Christoph Hellwig <hch@lst.de>
	Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
	Signed-off-by: Cunlong Li <shenxiaogll@gmail.com>
	Cc: Jens Axboe <axboe@kernel.dk>
	Cc: Minchan Kim <minchan@kernel.org>
	Cc: Yisheng Xie <xieyisheng1@huawei.com>
	Cc: <stable@vger.kernel.org>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 732fd9f)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1530
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Stefan Wiehler <stefan.wiehler@nokia.com>
commit 38f5024

With CONFIG_PROVE_RCU_LIST=y and by executing

  $ netcat -l --sctp &
  $ netcat --sctp localhost &
  $ ss --sctp

one can trigger the following Lockdep-RCU splat(s):

  WARNING: suspicious RCU usage
  6.18.0-rc1-00093-g7f864458e9a6 #5 Not tainted
  -----------------------------
  net/sctp/diag.c:76 RCU-list traversed in non-reader section!!

  other info that might help us debug this:

  rcu_scheduler_active = 2, debug_locks = 1
  2 locks held by ss/215:
   #0: ffff9c740828bec0 (nlk_cb_mutex-SOCK_DIAG){+.+.}-{4:4}, at: __netlink_dump_start+0x84/0x2b0
   #1: ffff9c7401d72cd0 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_sock_dump+0x38/0x200

  stack backtrace:
  CPU: 0 UID: 0 PID: 215 Comm: ss Not tainted 6.18.0-rc1-00093-g7f864458e9a6 #5 PREEMPT(voluntary)
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
  Call Trace:
   <TASK>
   dump_stack_lvl+0x5d/0x90
   lockdep_rcu_suspicious.cold+0x4e/0xa3
   inet_sctp_diag_fill.isra.0+0x4b1/0x5d0
   sctp_sock_dump+0x131/0x200
   sctp_transport_traverse_process+0x170/0x1b0
   ? __pfx_sctp_sock_filter+0x10/0x10
   ? __pfx_sctp_sock_dump+0x10/0x10
   sctp_diag_dump+0x103/0x140
   __inet_diag_dump+0x70/0xb0
   netlink_dump+0x148/0x490
   __netlink_dump_start+0x1f3/0x2b0
   inet_diag_handler_cmd+0xcd/0x100
   ? __pfx_inet_diag_dump_start+0x10/0x10
   ? __pfx_inet_diag_dump+0x10/0x10
   ? __pfx_inet_diag_dump_done+0x10/0x10
   sock_diag_rcv_msg+0x18e/0x320
   ? __pfx_sock_diag_rcv_msg+0x10/0x10
   netlink_rcv_skb+0x4d/0x100
   netlink_unicast+0x1d7/0x2b0
   netlink_sendmsg+0x203/0x450
   ____sys_sendmsg+0x30c/0x340
   ___sys_sendmsg+0x94/0xf0
   __sys_sendmsg+0x83/0xf0
   do_syscall_64+0xbb/0x390
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
   ...
   </TASK>

Fixes: 8f840e4 ("sctp: add the sctp_diag.c file")
	Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
	Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
	Acked-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/20251028161506.3294376-2-stefan.wiehler@nokia.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 38f5024)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1530
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Stefan Wiehler <stefan.wiehler@nokia.com>
commit 95aef86

For the following path not holding the sock lock,

  sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()

make sure not to exceed bounds in case the address list has grown
between buffer allocation (time-of-check) and write (time-of-use).

	Suggested-by: Kuniyuki Iwashima <kuniyu@google.com>
Fixes: 8f840e4 ("sctp: add the sctp_diag.c file")
	Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
	Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
	Acked-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/20251028161506.3294376-3-stefan.wiehler@nokia.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 95aef86)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1530
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Stefan Wiehler <stefan.wiehler@nokia.com>
commit f1fc201

Move address list traversal in inet_assoc_attr_size() under the sock
lock to avoid holding the RCU read lock.

	Suggested-by: Xin Long <lucien.xin@gmail.com>
Fixes: 8f840e4 ("sctp: add the sctp_diag.c file")
	Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
	Acked-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/20251028161506.3294376-4-stefan.wiehler@nokia.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit f1fc201)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…_item

jira KERNEL-1530
cve CVE-2025-68211
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Pedro Demarchi Gomes <pedrodemargomes@gmail.com>
commit f5548c3
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-5.14.0-687.42.1.el9_8/f5548c31.failed

Currently, scan_get_next_rmap_item() walks every page address in a VMA to
locate mergeable pages.  This becomes highly inefficient when scanning
large virtual memory areas that contain mostly unmapped regions, causing
ksmd to use large amount of cpu without deduplicating much pages.

This patch replaces the per-address lookup with a range walk using
walk_page_range().  The range walker allows KSM to skip over entire
unmapped holes in a VMA, avoiding unnecessary lookups.  This problem was
previously discussed in [1].

Consider the following test program which creates a 32 TiB mapping in the
virtual address space but only populates a single page:

#include <unistd.h>
#include <stdio.h>
#include <sys/mman.h>

/* 32 TiB */
const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;

int main() {
        char *area = mmap(NULL, size, PROT_READ | PROT_WRITE,
                          MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0);

        if (area == MAP_FAILED) {
                perror("mmap() failed\n");
                return -1;
        }

        /* Populate a single page such that we get an anon_vma. */
        *area = 0;

        /* Enable KSM. */
        madvise(area, size, MADV_MERGEABLE);
        pause();
        return 0;
}

$ ./ksm-sparse  &
$ echo 1 > /sys/kernel/mm/ksm/run

Without this patch ksmd uses 100% of the cpu for a long time (more then 1
hour in my test machine) scanning all the 32 TiB virtual address space
that contain only one mapped page.  This makes ksmd essentially deadlocked
not able to deduplicate anything of value.  With this patch ksmd walks
only the one mapped page and skips the rest of the 32 TiB virtual address
space, making the scan fast using little cpu.

Link: https://lkml.kernel.org/r/20251023035841.41406-1-pedrodemargomes@gmail.com
Link: https://lkml.kernel.org/r/20251022153059.22763-1-pedrodemargomes@gmail.com
Link: https://lore.kernel.org/linux-mm/423de7a3-1c62-4e72-8e79-19a6413e420c@redhat.com/ [1]
Fixes: 31dbd01 ("ksm: Kernel SamePage Merging")
	Signed-off-by: Pedro Demarchi Gomes <pedrodemargomes@gmail.com>
Co-developed-by: David Hildenbrand <david@redhat.com>
	Signed-off-by: David Hildenbrand <david@redhat.com>
	Reported-by: craftfever <craftfever@airmail.cc>
Closes: https://lkml.kernel.org/r/020cf8de6e773bb78ba7614ef250129f11a63781@murena.io
	Suggested-by: David Hildenbrand <david@redhat.com>
	Acked-by: David Hildenbrand <david@redhat.com>
	Cc: Chengming Zhou <chengming.zhou@linux.dev>
	Cc: xu xin <xu.xin16@zte.com.cn>
	Cc: <stable@vger.kernel.org>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit f5548c3)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	mm/ksm.c
jira KERNEL-1530
cve CVE-2026-53268
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Florian Westphal <fw@strlen.de>
commit 66eba0f

When parsing fails after we've matched the command string we
should bail out instead of trying to match a different command.

This helper should be deprecated, given prevalence of TLS I doubt it has
any relevance in 2026.

Fixes: 869f37d ("[NETFILTER]: nf_conntrack/nf_nat: add IRC helper port")
Closes: https://sashiko.dev/#/patchset/20260525182924.28456-1-fw%40strlen.de
	Signed-off-by: Florian Westphal <fw@strlen.de>
	Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
	Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit 66eba0f)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1530
cve CVE-2026-52920
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Jiexun Wang <wangjiexun2025@gmail.com>
commit 4b2b4d7

match_policy_in() walks sec_path entries from the last transform to the
first one, but strict policy matching needs to consume info->pol[] in
the same forward order as the rule layout.

Derive the strict-match policy position from the number of transforms
already consumed so that multi-element inbound rules are matched
consistently.

Fixes: c4b8851 ("[NETFILTER]: x_tables: replace IPv4/IPv6 policy match by address family independant version")
	Reported-by: Yuan Tan <yuantan098@gmail.com>
	Reported-by: Yifan Wu <yifanwucs@gmail.com>
	Reported-by: Juefei Pu <tomapufckgml@gmail.com>
	Reported-by: Xin Liu <bird@lzu.edu.cn>
	Signed-off-by: Jiexun Wang <wangjiexun2025@gmail.com>
	Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
	Acked-by: Florian Westphal <fw@strlen.de>
	Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
(cherry picked from commit 4b2b4d7)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1530
cve CVE-2026-53131
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Zhengchuan Liang <zcliangcn@gmail.com>
commit 62443dc

`ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and
`hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)`
after either assuming that the skb is associated with an Ethernet
device or checking only that the `ETH_HLEN` bytes at
`skb_mac_header(skb)` lie between `skb->head` and `skb->data`.

Make these paths first verify that the skb is associated with an
Ethernet device, that the MAC header was set, and that it spans at
least a full Ethernet header before accessing `eth_hdr(skb)`.

	Suggested-by: Florian Westphal <fw@strlen.de>
	Tested-by: Ren Wei <enjou1224z@gmail.com>
	Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
	Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
	Signed-off-by: Florian Westphal <fw@strlen.de>
(cherry picked from commit 62443dc)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1530
cve CVE-2026-64191
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Weiming Shi <bestswngs@gmail.com>
commit 6036b50

The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0]
as the transfer length. The existing check only clamps it to avoid
overrunning the chip->words[256] register array, but does not validate
it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union
i2c_smbus_data.block buffer (34 bytes total). The driver is a
development/test tool (CONFIG_I2C_STUB=m, not built by default)
that must be loaded with a chip_addr= parameter.

A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl
with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing
stub_xfer() to read or write past the end of the union
i2c_smbus_data.block buffer:

 BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)
 Read of size 1 at addr ffff88800abcfd92 by task exploit/81
 Call Trace:
  <TASK>
  stub_xfer (drivers/i2c/i2c-stub.c:223)
  __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)
  i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)
  i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)
  i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)
  __x64_sys_ioctl (fs/ioctl.c:583)
  do_syscall_64 (arch/x86/entry/syscall_64.c:94)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
  </TASK>

The bug exists because i2c-stub implements .smbus_xfer directly,
bypassing the I2C_SMBUS_BLOCK_MAX validation in
i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same
function correctly validates against I2C_SMBUS_BLOCK_MAX, but the
I2C_SMBUS_I2C_BLOCK_DATA case does not.

Fix by rejecting transfers with data->block[0] == 0 or
data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with
both the I2C_SMBUS_BLOCK_DATA case in the same function and the
I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().

Fixes: 4710317 ("i2c-stub: Implement I2C block support")
	Reported-by: Xiang Mei <xmei5@asu.edu>
	Signed-off-by: Weiming Shi <bestswngs@gmail.com>
	Reviewed-by: Jean Delvare <jdelvare@suse.de>
	Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
(cherry picked from commit 6036b50)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1530
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Harald Freudenberger <freude@linux.ibm.com>
commit 6917f43

For the in_use() check of an updated apmask the host's aqmask
was provided to the vfio function. Similar on an update of the
aqmask the host's apmask was provided to the vfio in_use()
function. This led to false results on the check for apmask or
aqmask updates. For example with only one APQN when exactly
this card is tried to be re-assigned back to the host, the
in_use() check did not complain.

The correct behavior is achieved with providing a full mask
for aqmask when an adapter is to be checked and similar a full
mask for aqmask when a domain is to be checked for usage.

	Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
	Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
	Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
(cherry picked from commit 6917f43)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1530
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Harald Freudenberger <freude@linux.ibm.com>
commit d38a87d
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-5.14.0-687.42.1.el9_8/d38a87d7.failed

Add a new sysfs attribute driver_override the AP queue's
directory. Writing in a string overrides the default driver
determination and the drivers are matched against this string
instead. This overrules the driver binding determined by the
apmask/aqmask bitmask fields.

According to the common understanding of how the driver_override
behavior shall work, there is no further checking done. Neither about
the string which is given as override driver nor if this device is
currently in use by an mdev device. Another patch may limit this
behavior to refuse a mixed usage of the driver_override and
apmask/aqmask feature.

As there exists some tooling for this kind of driver_override
(see package driverctl) the AP bus behavior for re-binding
should be compatible to this. The steps for a driver_override are:
 1) unbind the current driver from the device. For example
    echo "17.0005" > /sys/devices/ap/card17/17.0005/driver/unbind
 2) set the new driver for this device in the sysfs
    driver_override attribute. For example
    echo "vfio_ap" > /sys//devices/ap/card17/17.0005/driver_override
 3) trigger a bus reprobe of this device. For example
    echo "17.0005" > /sys/bus/ap/drivers_probe
With the driverctl package this is more comfortable and
the settings get persisted:
  driverctl -b ap set-override 17.0005 vfio_ap
and unset with
  driverctl -b ap unset-override 17.0005

	Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
	Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
	Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
(cherry picked from commit d38a87d)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	drivers/s390/crypto/ap_bus.c
jira KERNEL-1530
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Harald Freudenberger <freude@linux.ibm.com>
commit 8babcc2
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-5.14.0-687.42.1.el9_8/8babcc2b.failed

The mutex ap_perms_mutex was already used not only for protection
of the struct ap_perms ap_perms variable but also for an consistent
update of the AP bus sysfs attributes apmask and aqmask.

So rename this mutex to ap_attr_mutex which better reflects the
current use. This is also a preparation for an upcoming patch which
will use this mutex to lock updates on a new sysfs attribute.

	Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
	Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
	Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
(cherry picked from commit 8babcc2)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	drivers/s390/crypto/ap_bus.c
jira KERNEL-1530
Rebuild_History Non-Buildable kernel-5.14.0-687.42.1.el9_8
commit-author Harald Freudenberger <freude@linux.ibm.com>
commit 4603037
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-5.14.0-687.42.1.el9_8/46030379.failed

Introduce a restriction for the driver_override feature versus apmask
and aqmask:
- driver_override is only allowed when the apmask and aqmask values
  both are default (=0xffff..ffff).
- apmask and aqmask modifications are only allowed when there is no
  driver_override on any AP device active.
So in the end the user is restricted to choose to either use
apmask/apmask to divide the AP devices into host owned and vfio owned
or use the driver_override feature but not mix these two approaches.

	Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
	Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
	Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
(cherry picked from commit 4603037)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	drivers/s390/crypto/ap_bus.c
#	drivers/s390/crypto/ap_bus.h
#	drivers/s390/crypto/ap_queue.c
Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v5.14~1..kernel-mainline: 394115
Number of commits in rpm: 25
Number of commits matched with upstream: 16 (64.00%)
Number of commits in upstream but not in rpm: 394099
Number of commits NOT found in upstream: 9 (36.00%)

Rebuilding Kernel on Branch rocky9_8_rebuild_kernel-5.14.0-687.42.1.el9_8 for kernel-5.14.0-687.42.1.el9_8
Clean Cherry Picks: 12 (75.00%)
Empty Cherry Picks: 4 (25.00%)
_______________________________

Full Details Located here:
ciq/ciq_backports/kernel-5.14.0-687.42.1.el9_8/rebuild.details.txt

Includes:
* git commit header above
* Empty Commits with upstream SHA
* RPM ChangeLog Entries that could not be matched

Individual Empty Commit failures contained in the same containing directory.
The git message for empty commits will have the path for the failed commit.
File names are the first 8 characters of the upstream SHA
@PlaidCat PlaidCat self-assigned this Aug 27, 2026
@PlaidCat
PlaidCat requested review from a team August 27, 2026 04:49

@bmastbergen bmastbergen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants