Skip to content

[rocky10_2] History Rebuild through kernel-6.12.0-211.53.1.el10_2 - #1578

Open
PlaidCat wants to merge 71 commits into
rocky10_2from
rocky10_2_rebuild
Open

[rocky10_2] History Rebuild through kernel-6.12.0-211.53.1.el10_2#1578
PlaidCat wants to merge 71 commits into
rocky10_2from
rocky10_2_rebuild

Conversation

@PlaidCat

@PlaidCat PlaidCat commented Sep 6, 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 (6.12.0-211)
    • 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-6.12.0-211.51.1.el10_2

$ cat ciq/ciq_backports/kernel-6.12.0-211.51.1.el10_2/rebuild.details.txt
Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v6.12~1..kernel-mainline: 138299
Number of commits in rpm: 8
Number of commits matched with upstream: 4 (50.00%)
Number of commits in upstream but not in rpm: 138295
Number of commits NOT found in upstream: 4 (50.00%)

Rebuilding Kernel on Branch rocky10_2_rebuild_kernel-6.12.0-211.51.1.el10_2 for kernel-6.12.0-211.51.1.el10_2
Clean Cherry Picks: 4 (100.00%)
Empty Cherry Picks: 0 (0.00%)
_______________________________

__EMPTY COMMITS__________________________

__CHANGES NOT IN UPSTREAM________________
Add partial riscv64 support for build root'
Provide basic VisionFive 2 support'
net: ipv6: clear suppressed fib6 rule result
iomap: fix out-of-bounds bitmap_set() with zero-length range

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="-rocky10_2_rebuild-c99817d1264f"
Making olddefconfig
--
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
Starting Build
  GEN     arch/x86/include/generated/asm/orc_hash.h
  WRAP    arch/x86/include/generated/uapi/asm/bpf_perf_event.h
  WRAP    arch/x86/include/generated/uapi/asm/errno.h
  WRAP    arch/x86/include/generated/uapi/asm/fcntl.h
  UPD     include/generated/uapi/linux/version.h
--
  BTF [M] net/qrtr/qrtr.ko
  LD [M]  net/qrtr/qrtr-mhi.ko
  LD [M]  virt/lib/irqbypass.ko
  BTF [M] virt/lib/irqbypass.ko
  BTF [M] net/qrtr/qrtr-mhi.ko
[TIMER]{BUILD}: 2272s
Making Modules
  SYMLINK /lib/modules/6.12.0-rocky10_2_rebuild-c99817d1264f+/build
  INSTALL /lib/modules/6.12.0-rocky10_2_rebuild-c99817d1264f+/modules.order
  INSTALL /lib/modules/6.12.0-rocky10_2_rebuild-c99817d1264f+/modules.builtin
  INSTALL /lib/modules/6.12.0-rocky10_2_rebuild-c99817d1264f+/modules.builtin.modinfo
--
  SIGN    /lib/modules/6.12.0-rocky10_2_rebuild-c99817d1264f+/kernel/net/qrtr/qrtr.ko
  STRIP   /lib/modules/6.12.0-rocky10_2_rebuild-c99817d1264f+/kernel/virt/lib/irqbypass.ko
  SIGN    /lib/modules/6.12.0-rocky10_2_rebuild-c99817d1264f+/kernel/net/qrtr/qrtr-mhi.ko
  SIGN    /lib/modules/6.12.0-rocky10_2_rebuild-c99817d1264f+/kernel/virt/lib/irqbypass.ko
  DEPMOD  /lib/modules/6.12.0-rocky10_2_rebuild-c99817d1264f+
[TIMER]{MODULES}: 14s
Making Install
  INSTALL /boot
[TIMER]{INSTALL}: 18s
Checking kABI
kABI check passed
Setting Default Kernel to /boot/vmlinuz-6.12.0-rocky10_2_rebuild-c99817d1264f+ and Index to 2
Hopefully Grub2.0 took everything ... rebooting after time metrices
[TIMER]{MRPROPER}: 6s
[TIMER]{BUILD}: 2272s
[TIMER]{MODULES}: 14s
[TIMER]{INSTALL}: 18s
[TIMER]{TOTAL} 2315s
Rebooting in 10 seconds

KSelfTests

$ get_kselftest_diff.sh
kselftest.6.12.0-rocky10_2_rebuild-b02922d66aea+.log
492
kselftest.6.12.0-rocky10_2_rebuild-929a9f478bab+.log
491
kselftest.6.12.0-rocky10_2_rebuild-0243d38a7f8b+.log
492
kselftest.6.12.0-rocky10_2_rebuild-c99817d1264f+.log
492
Before: kselftest.6.12.0-rocky10_2_rebuild-0243d38a7f8b+.log
After: kselftest.6.12.0-rocky10_2_rebuild-c99817d1264f+.log
Diff:
No differences found.

jira KERNEL-1558
cve CVE-2026-64387
Rebuild_History Non-Buildable kernel-6.12.0-211.51.1.el10_2
commit-author Henrique Carvalho <henrique.carvalho@suse.com>
commit 9647492

A response-bearing attempt can return a replayable error and free its
response buffer. If SMB2_query_directory_init() fails before the next send,
cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.

Fixes: 4f1fffa ("cifs: commands that are retried should have replay flag set")
	Cc: stable@vger.kernel.org
	Signed-off-by: Henrique Carvalho <henrique.carvalho@suse.com>
	Signed-off-by: Steve French <stfrench@microsoft.com>
(cherry picked from commit 9647492)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1558
cve CVE-2026-53073
Rebuild_History Non-Buildable kernel-6.12.0-211.51.1.el10_2
commit-author Jonathan Rissanen <jonathan.rissanen@axis.com>
commit 68d39ea

When hci_register_dev() fails in hci_uart_register_dev()
HCI_UART_PROTO_INIT is not cleared before calling hu->proto->close(hu)
and setting hu->hdev to NULL. This means incoming UART data will reach
the protocol-specific recv handler in hci_uart_tty_receive() after
resources are freed.

Clear HCI_UART_PROTO_INIT with a write lock before calling
hu->proto->close() and setting hu->hdev to NULL. The write lock ensures
all active readers have completed and no new reader can enter the
protocol recv path before resources are freed.

This allows the protocol-specific recv functions to remove the
"HCI_UART_REGISTERED" guard without risking a null pointer dereference
if hci_register_dev() fails.

Fixes: 5df5daf ("Bluetooth: hci_uart: Fix another race during initialization")
	Signed-off-by: Jonathan Rissanen <jonathan.rissanen@axis.com>
	Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit 68d39ea)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1558
cve CVE-2026-63824
Rebuild_History Non-Buildable kernel-6.12.0-211.51.1.el10_2
commit-author Jarkko Sakkinen <jarkko@kernel.org>
commit cb481e5

The length for the internal output buffer is calculated incorrectly, which
can result overflow when a too small buffer is provided.

Fix the bug by allocating internal output with the size of the maximum
length of the cryptographic primitive instead of caller provided size.

Link: https://lore.kernel.org/keyrings/20260531024914.3712130-1-jarkko@kernel.org/
	Cc: stable@vger.kernel.org # v4.20+
Fixes: 00d60fd ("KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]")
	Reported-by: Alessandro Groppo <ale.grpp@gmail.com>
	Tested-by: Alessandro Groppo <ale.grpp@gmail.com>
	Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
(cherry picked from commit cb481e5)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1558
cve CVE-2026-63808
Rebuild_History Non-Buildable kernel-6.12.0-211.51.1.el10_2
commit-author Michael Bommarito <michael.bommarito@gmail.com>
commit 3f5f8ee

In exfat_find_dir_entry(), the buffer_head obtained from
exfat_get_dentry() is released with brelse(bh) before the fall-through
TYPE_EXTEND branch reads the directory entry through ep (which points
into bh->b_data):

	brelse(bh);
	if (entry_type == TYPE_EXTEND) {
		...
		len = exfat_extract_uni_name(ep, entry_uniname);
		...
	}

After brelse() drops our reference, nothing guarantees that the
underlying page backing bh->b_data remains valid for the subsequent
exfat_extract_uni_name() read. This is the same pattern fixed in
commit fc96152 ("exfat: Fix potential use after free in
exfat_load_upcase_table()").

Move brelse(bh) so it runs after ep is no longer dereferenced on
each branch.

Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y
+ CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image
(long filename with same-hash collisions forcing the TYPE_EXTEND path).
With a debug-only invalidate_bdev() inserted between brelse(bh) and
the ep read to make the stale-deref window deterministic, the
unpatched kernel faults:

  BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0
  BUG: unable to handle page fault for address: ffff88801a5fa0c2
  Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI
  RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0

With this patch applied, the same instrumented harness completes
cleanly under the same sanitizer stack. I have not reproduced a
crash on an uninstrumented kernel under ordinary reclaim; the
instrumented A/B establishes the lifetime violation and that the
patch closes it, not an unaided triggerability claim.

Fixes: ca06197 ("exfat: add directory operations")
	Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
	Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
	Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
(cherry picked from commit 3f5f8ee)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v6.12~1..kernel-mainline: 138299
Number of commits in rpm: 8
Number of commits matched with upstream: 4 (50.00%)
Number of commits in upstream but not in rpm: 138295
Number of commits NOT found in upstream: 4 (50.00%)

Rebuilding Kernel on Branch rocky10_2_rebuild_kernel-6.12.0-211.51.1.el10_2 for kernel-6.12.0-211.51.1.el10_2
Clean Cherry Picks: 4 (100.00%)
Empty Cherry Picks: 0 (0.00%)
_______________________________

Full Details Located here:
ciq/ciq_backports/kernel-6.12.0-211.51.1.el10_2/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 Sep 6, 2026
@PlaidCat
PlaidCat requested review from a team September 6, 2026 08:14
bmastbergen
bmastbergen previously approved these changes Sep 8, 2026

@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.

🥌

@bmastbergen
bmastbergen requested a review from a team September 8, 2026 18:59
kerneltoast
kerneltoast previously approved these changes Sep 9, 2026

@kerneltoast kerneltoast 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.

:shipit:

jira KERNEL-1569
cve CVE-2026-52933
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Longxuan Yu <ylong030@ucr.edu>
commit 326941b

io_poll_get_ownership() uses a signed comparison to check whether
poll_refs has reached the threshold for the slowpath:

    if (unlikely(atomic_read(&req->poll_refs) >= IO_POLL_REF_BIAS))

atomic_read() returns int (signed). When IO_POLL_CANCEL_FLAG
(BIT(31)) is set in poll_refs, the value becomes negative in
signed arithmetic, so the >= 128 comparison always evaluates to
false and the slowpath is never taken.

Fix this by casting the atomic_read() result to unsigned int
before the comparison, so that the cancel flag is treated as a
large positive value and correctly triggers the slowpath.

Fixes: a26a35e ("io_uring: make poll refs more robust")
	Cc: stable@vger.kernel.org
	Reported-by: Yifan Wu <yifanwucs@gmail.com>
	Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
	Signed-off-by: Yuan Tan <yuantan098@gmail.com>
	Suggested-by: Xin Liu <bird@lzu.edu.cn>
	Tested-by: Zhengchuan Liang <zcliangcn@gmail.com>
	Signed-off-by: Longxuan Yu <ylong030@ucr.edu>
	Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
	Reviewed-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://patch.msgid.link/3a3508b08bcd7f1bc3beff848ae6e1d73d355043.1775965597.git.ylong030@ucr.edu
	Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit 326941b)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…_sysctl_table()

jira KERNEL-1569
cve CVE-2026-64002
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Eric Dumazet <edumazet@google.com>
commit 87a1e0f

ipv4_sysctl_exit_net() is currently freeing net->ipv4.sysctl_local_reserved_ports
too soon.

Only after unregister_net_sysctl_table() we can be sure no threads can possibly
use the sysctls, including /proc/sys/net/ipv4/ip_local_reserved_ports.

Fixes: 122ff24 ("ipv4: make ip_local_reserved_ports per netns")
	Reported-by: Ji'an Zhou <eilaimemedsnaimel@gmail.com>
	Signed-off-by: Eric Dumazet <edumazet@google.com>
	Cc: Cong Wang <xiyou.wangcong@gmail.com>
	Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
	Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20260521122147.3584624-1-edumazet@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 87a1e0f)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…n and AT emulation

jira KERNEL-1569
cve CVE-2026-53277
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Hyunwoo Kim <imv4bel@gmail.com>
commit f2ca45b

walk_s1() and kvm_walk_nested_s2() expect to be called while holding
kvm->srcu to guard against memslot changes. While this is generally
the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the
respective walkers without taking kvm->srcu.

Fix by acquiring kvm->srcu prior to the table walk in both instances.

	Cc: stable@vger.kernel.org
Fixes: 50f77dc ("KVM: arm64: Populate level on S1PTW SEA injection")
Fixes: be04ceb ("KVM: arm64: nv: Add emulation of AT S12E{0,1}{R,W}")
	Suggested-by: Oliver Upton <oupton@kernel.org>
	Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
	Reviewed-by: Oliver Upton <oupton@kernel.org>
Link: https://patch.msgid.link/aiAZfdeyanIvP8SD@v4bel
	Signed-off-by: Marc Zyngier <maz@kernel.org>
(cherry picked from commit f2ca45b)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-64287
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Hyunwoo Kim <imv4bel@gmail.com>
commit 8cc8bbb
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-6.12.0-211.52.1.el10_2/8cc8bbbf.failed

flush_hyp_vcpu() copies the host vGIC state into the hyp's private vCPU
on every run. The vGIC list register save and restore use used_lrs as
their loop bound and expect it to stay within the number of implemented
list registers. While this is generally the case, flush_hyp_vcpu()
copies vgic_v3 verbatim and does not enforce this, so a value provided
by the host is used at EL2 to index vgic_lr[] and access ICH_LR<n>_EL2
(host -> EL2).

Fix by clamping used_lrs to the number of implemented list registers
after the copy, as the trusted path already does in
vgic_flush_lr_state(). The number of implemented list registers is
constant after init, so it is replicated once from
kvm_vgic_global_state.nr_lr into hyp_gicv3_nr_lr rather than read on
every entry.

	Cc: stable@vger.kernel.org
Fixes: be66e67 ("KVM: arm64: Use the pKVM hyp vCPU structure in handle___kvm_vcpu_run()")
	Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
	Reviewed-by: Fuad Tabba <tabba@google.com>
	Tested-by: Fuad Tabba <tabba@google.com>
Link: https://patch.msgid.link/20260606175614.83273-3-imv4bel@gmail.com
	Signed-off-by: Marc Zyngier <maz@kernel.org>
(cherry picked from commit 8cc8bbb)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	arch/arm64/include/asm/kvm_hyp.h
#	arch/arm64/kvm/hyp/nvhe/hyp-main.c
…ngth

jira KERNEL-1569
cve CVE-2026-64319
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Tianchu Chen <flynnnchen@tencent.com>
commit 3a413ec

nvmet_auth_reply() accesses the variable-length rval[] array using
attacker-controlled hl (hash length) and dhvlen (DH value length) fields
without verifying they fit within the allocated buffer of tl bytes.

A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a
small transfer length but large hl/dhvlen values, causing out-of-bounds
heap reads when the target processes the DH public key (rval + 2*hl) or
performs the host response memcmp.

With DH authentication configured, the OOB pointer is passed directly to
sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching
up to 526 bytes past the buffer. This is exploitable pre-authentication.

Add bounds validation ensuring sizeof(*data) + 2*hl + dhvlen <= tl before
any access to the variable-length fields.

Discovered by Atuin - Automated Vulnerability Discovery Engine.

Fixes: db1312d ("nvmet: implement basic In-Band Authentication")
	Cc: stable@vger.kernel.org
	Reviewed-by: Hannes Reinecke <hare@kernel.org>
	Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
	Signed-off-by: Keith Busch <kbusch@kernel.org>
(cherry picked from commit 3a413ec)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-23442
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Minhong He <heminhong@kylinos.cn>
commit 0641379

__in6_dev_get() can return NULL when the device has no IPv6 configuration
(e.g. MTU < IPV6_MIN_MTU or after NETDEV_UNREGISTER).

Add NULL checks for idev returned by __in6_dev_get() in both
seg6_hmac_validate_skb() and ipv6_srh_rcv() to prevent potential NULL
pointer dereferences.

Fixes: 1ababeb ("ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)")
Fixes: bf355b8 ("ipv6: sr: add core files for SR HMAC support")
	Signed-off-by: Minhong He <heminhong@kylinos.cn>
	Reviewed-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Link: https://patch.msgid.link/20260316073301.106643-1-heminhong@kylinos.cn
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 0641379)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-53228
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Kyle Zeng <kylebot@openai.com>
commit f0e42f0

ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function
entry and continues using it after iptunnel_handle_offloads().

For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone().
When the skb header is cloned, skb_header_unclone() can call
pskb_expand_head(), which may move the skb head. The pskb_expand_head()
contract requires pointers into the skb header to be reloaded after the
call.

If the later skb_realloc_headroom() branch is not taken, SIT uses the
stale iph6 pointer to read the inner hop limit and DS field. That can
read from a freed skb head after the old head's remaining clone is
released.

Reload iph6 after the offload helper succeeds and before subsequent
reads from the inner IPv6 header. Keep the existing reload after
skb_realloc_headroom(), since that branch can also replace the skb.

Fixes: 1490966 ("sit: Setup and TX path for sit/UDP foo-over-udp encapsulation")
	Signed-off-by: Kyle Zeng <kylebot@openai.com>
	Reviewed-by: Eric Dumazet <edumazet@google.com>
	Reported-by: syzbot+6eb9ca986d80f6f88cf9@syzkaller.appspotmail.com
Link: https://patch.msgid.link/20260605073448.6524-1-kylebot@openai.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit f0e42f0)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-63993
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Eric Dumazet <edumazet@google.com>
commit 7d9ef0c

skb_tunnel_check_pmtu() can change skb->head.

Reusing old_iph afer skb_tunnel_check_pmtu() can cause an UAF.

Use instead ip_hdr(skb) as done in drivers/net/bareudp.c
and drivers/net/geneve.c.

Found by Sashiko.

Fixes: 4cb47a8 ("tunnels: PMTU discovery support for directly bridged IP packets")
	Signed-off-by: Eric Dumazet <edumazet@google.com>
	Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
Link: https://patch.msgid.link/20260525203642.2389723-1-edumazet@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 7d9ef0c)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-53075
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Taegu Ha <hataegu0826@gmail.com>
commit 2bb6379

/dev/ppp open is currently authorized against file->f_cred->user_ns,
while unattached administrative ioctls operate on current->nsproxy->net_ns.

As a result, a local unprivileged user can create a new user namespace
with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace,
and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against
an inherited network namespace.

Require CAP_NET_ADMIN in the user namespace that owns the target network
namespace before handling unattached PPP administrative ioctls.

This preserves normal pppd operation in the network namespace it is
actually privileged in, while rejecting the userns-only inherited-netns
case.

Fixes: 273ec51 ("net: ppp_generic - introduce net-namespace functionality v2")
	Signed-off-by: Taegu Ha <hataegu0826@gmail.com>
Link: https://patch.msgid.link/20260409071117.4354-1-hataegu0826@gmail.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 2bb6379)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…CCOUNT allocation

jira KERNEL-1569
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Scott Mitchell <scott.k.mitch1@gmail.com>
commit a4400a5

Currently, instance_create() uses GFP_ATOMIC because it's called while
holding instances_lock spinlock. This makes allocation more likely to
fail under memory pressure.

Refactor nfqnl_recv_config() to drop RCU lock after instance_lookup()
and peer_portid verification. A socket cannot simultaneously send a
message and close, so the queue owned by the sending socket cannot be
destroyed while processing its CONFIG message. This allows
instance_create() to allocate with GFP_KERNEL_ACCOUNT before taking
the spinlock.

	Suggested-by: Florian Westphal <fw@strlen.de>
	Signed-off-by: Scott Mitchell <scott.k.mitch1@gmail.com>
	Signed-off-by: Florian Westphal <fw@strlen.de>
(cherry picked from commit a4400a5)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Scott Mitchell <scott.k.mitch1@gmail.com>
commit e19079a

The current implementation uses a linear list to find queued packets by
ID when processing verdicts from userspace. With large queue depths and
out-of-order verdicting, this O(n) lookup becomes a significant
bottleneck, causing userspace verdict processing to dominate CPU time.

Replace the linear search with a hash table for O(1) average-case
packet lookup by ID. A global rhashtable spanning all network
namespaces attributes hash bucket memory to kernel but is subject to
fixed upper bound.

	Signed-off-by: Scott Mitchell <scott.k.mitch1@gmail.com>
	Signed-off-by: Florian Westphal <fw@strlen.de>
(cherry picked from commit e19079a)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-43084
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Florian Westphal <fw@strlen.de>
commit 936206e

Sharing a global hash table among all queues is tempting, but
it can cause crash:

BUG: KASAN: slab-use-after-free in nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue]
[..]
 nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue]
 nfnetlink_rcv_msg+0x46a/0x930
 kmem_cache_alloc_node_noprof+0x11e/0x450

struct nf_queue_entry is freed via kfree, but parallel cpu can still
encounter such an nf_queue_entry when walking the list.

Alternative fix is to free the nf_queue_entry via kfree_rcu() instead,
but as we have to alloc/free for each skb this will cause more mem
pressure.

	Cc: Scott Mitchell <scott.k.mitch1@gmail.com>
Fixes: e19079a ("netfilter: nfnetlink_queue: optimize verdict lookup with hash table")
	Signed-off-by: Florian Westphal <fw@strlen.de>
(cherry picked from commit 936206e)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Florian Westphal <fw@strlen.de>
commit ba14798
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-6.12.0-211.52.1.el10_2/ba147986.failed

Jakub reports test flakes on debug kernels:
 FAIL: test_udp_gro_ct: Expected software segmentation to occur, had 23 and 17

This test assumes that the kernels nfnetlink_queue module sees N GSO
packets, segments them into M skbs and queues them to userspace for
reinjection.

Hence, if M >= N, no segmentation occurred.

However, its possible that this happens:
- nfnetlink_queue gets GSO packet
- segments that into n skbs
- userspace buffer is full, kernel drops the segmented skbs

-> "toqueue" counter incremented by 1, "fromqueue" is unchanged.

If this happens often enough in a single run, M >= N check triggers
incorrectly.

To solve this, allow the nf_queue.c test program to set the FAIL_OPEN
flag so that the segmented skbs bypass the queueing step in the kernel
if the receive buffer is full.

Also, reduce number of sending socat instances, decrease their priority
and increase nice value for the nf_queue program itself to reduce the
probability of overruns happening in the first place.

Fixes: 59ecffa ("selftests: netfilter: nft_queue.sh: add udp fraglist gro test case")
	Reported-by: Jakub Kicinski <kuba@kernel.org>
Closes: https://lore.kernel.org/netdev/20260218184114.0b405b72@kernel.org/
	Signed-off-by: Florian Westphal <fw@strlen.de>
Link: https://patch.msgid.link/20260226161920.1205-1-fw@strlen.de
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit ba14798)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	tools/testing/selftests/net/netfilter/nft_queue.sh
jira KERNEL-1569
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Fernando Fernandez Mancera <fmancera@suse.de>
commit dde1a60
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-6.12.0-211.52.1.el10_2/dde1a608.failed

Introduce a new stress test to check for race conditions in the
nfnetlink_queue subsystem, where an entry is freed while another CPU is
concurrently walking the global rhashtable.

To trigger this, `nf_queue.c` is extended with two new flags:
  * -O (out-of-order): Buffers packet IDs and flushes them in reverse.
  * -b (bogus verdicts): Floods the kernel with non-existent packet IDs.

The bogus verdict loop forces the kernel's lookup function to perform
full rhashtable bucket traversals (-ENOENT). Combined with reverse-order
flushing and heavy parallel UDP/ping flooding across 8 queues, this puts
the nfnetlink_queue code under pressure.

Joint work with Florian Westphal.

	Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
	Signed-off-by: Florian Westphal <fw@strlen.de>
(cherry picked from commit dde1a60)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	tools/testing/selftests/net/netfilter/nf_queue.c
#	tools/testing/selftests/net/netfilter/nft_queue.sh
jira KERNEL-1569
cve CVE-2026-64597
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Henrique Carvalho <henrique.carvalho@suse.com>
commit f96e1cd

A response-bearing attempt can return a replayable error and free its
response buffer. If SMB2_close_init() fails before the next send, cleanup
retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.

Fixes: 4f1fffa ("cifs: commands that are retried should have replay flag set")
	Cc: stable@vger.kernel.org
	Signed-off-by: Henrique Carvalho <henrique.carvalho@suse.com>
	Signed-off-by: Steve French <stfrench@microsoft.com>
(cherry picked from commit f96e1cd)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2025-38004
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Oliver Hartkopp <socketcan@hartkopp.net>
commit c2aba69

The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via
hrtimer. The content and also the length of the sequence can be changed
resp reduced at runtime where the 'currframe' counter is then set to zero.

Although this appeared to be a safe operation the updates of 'currframe'
can be triggered from user space and hrtimer context in bcm_can_tx().
Anderson Nascimento created a proof of concept that triggered a KASAN
slab-out-of-bounds read access which can be prevented with a spin_lock_bh.

At the rework of bcm_can_tx() the 'count' variable has been moved into
the protected section as this variable can be modified from both contexts
too.

Fixes: ffd980f ("[CAN]: Add broadcast manager (bcm) protocol")
	Reported-by: Anderson Nascimento <anderson@allelesecurity.com>
	Tested-by: Anderson Nascimento <anderson@allelesecurity.com>
	Reviewed-by: Marc Kleine-Budde <mkl@pengutronix.de>
	Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Link: https://patch.msgid.link/20250519125027.11900-1-socketcan@hartkopp.net
	Cc: stable@vger.kernel.org
	Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
(cherry picked from commit c2aba69)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2025-38004
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Oliver Hartkopp <socketcan@hartkopp.net>
commit c35636e

Commit c2aba69 ("can: bcm: add locking for bcm_op runtime updates")
added a locking for some variables that can be modified at runtime when
updating the sending bcm_op with a new TX_SETUP command in bcm_tx_setup().

Usually the RX_SETUP only handles and filters incoming traffic with one
exception: When the RX_RTR_FRAME flag is set a predefined CAN frame is
sent when a specific RTR frame is received. Therefore the rx bcm_op uses
bcm_can_tx() which uses the bcm_tx_lock that was only initialized in
bcm_tx_setup(). Add the missing spin_lock_init() when allocating the
bcm_op in bcm_rx_setup() to handle the RTR case properly.

Fixes: c2aba69 ("can: bcm: add locking for bcm_op runtime updates")
	Reported-by: syzbot+5b11eccc403dd1cea9f8@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-can/699466e4.a70a0220.2c38d7.00ff.GAE@google.com/
	Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Link: https://patch.msgid.link/20260218-bcm_spin_lock_init-v1-1-592634c8a5b5@hartkopp.net
	Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
(cherry picked from commit c35636e)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-53235
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author HanQuan <eilaimemedsnaimel@gmail.com>
commit f2bb343

skb_gro_receive_list() calls skb_pull(skb, skb_gro_offset(skb)) without
first ensuring the data is in the linear area via pskb_may_pull(). When
the skb arrives via napi_gro_frags(), skb_headlen can be 0 (all data in
page fragments) while skb_gro_offset is non-zero (after IP+TCP header
parsing). The skb_pull() then decrements skb->len by skb_gro_offset
but skb->data_len stays unchanged, hitting BUG_ON(skb->len < skb->data_len)
in __skb_pull().

The UDP fraglist GRO path already contains this guard at
udp_offload.c:749. Adding it to skb_gro_receive_list() itself provides
centralized protection for all callers (TCP, UDP, and any future
protocols), and ensures the precondition of skb_pull() is satisfied
before it is called.

On pskb_may_pull() failure, set NAPI_GRO_CB(skb)->flush = 1 so the
skb is not held as a new GRO head and is instead delivered through the
normal receive path, matching the UDP handling.

Fixes: 8d95dc4 ("net: add code for TCP fraglist GRO")
	Reported-by: HanQuan <eilaimemedsnaimel@gmail.com>
	Reported-by: MingXuan <bwnie0730@outlook.com>
	Signed-off-by: HanQuan <eilaimemedsnaimel@gmail.com>
	Reviewed-by: Eric Dumazet <edumazet@google.com>
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit f2bb343)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-53223
Rebuild_History Non-Buildable kernel-6.12.0-211.52.1.el10_2
commit-author Kyle Zeng <kylebot@openai.com>
commit 1ee90b7

skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb
from sk_error_queue. That assumption is not true for AF_PACKET sockets:
outgoing packet taps are also delivered to packet sockets with
skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET
instead of struct sock_exterr_skb.

If such an skb is received with timestamping enabled, the generic
timestamp cmsg path can read AF_PACKET control-buffer state as
sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop
counter overlaps opt_stats. An odd drop count makes the path emit
SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear
skbs this copies past the linear head and can trigger hardened usercopy or
disclose adjacent heap contents.

Keep skb_is_err_queue() local to net/socket.c, but make it verify that
the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor
installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal
receive ownership and no longer pass as error-queue skbs, while legitimate
sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free
ownership.

Fixes: 8605330 ("tcp: fix SCM_TIMESTAMPING_OPT_STATS for normal skbs")
	Signed-off-by: Kyle Zeng <kylebot@openai.com>
	Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
	Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260607021819.49698-1-kylebot@openai.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 1ee90b7)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-64113
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Michael Bommarito <michael.bommarito@gmail.com>
commit 5d49b56

ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF's
own address (VEPA multicast workaround) by freeing the skb and
continuing to the next descriptor:

    dev_kfree_skb_irq(skb);
    continue;

The skb pointer is declared outside the while loop and persists across
iterations.  Because the continue skips the "skb = NULL" reset at the
bottom of the loop, the next iteration enters the "else if (skb)" path
and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing
skb_shinfo(skb)->nr_frags - a use-after-free in NAPI softirq context.

The sibling driver iavf already handles this correctly by nulling the
pointer before continuing.  Apply the same pattern here.

I do not have ixgbevf hardware; the bug was found by static analysis
(scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool
corroboration with the highest score in the scan).  The UAF was confirmed
under KASAN by loading a test module that reproduces the exact code
pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)->nr_frags):

  BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000
  Read of size 8 at addr 000000006163ae78 by task insmod/30
  freed 208-byte region [000000006163adc0, 000000006163ae90)

QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF
driver does not include the VEPA source pruning path, so a full
end-to-end reproduction with emulated hardware was not possible.

Fixes: bad1723 ("ixgbevf: Change receive model to use double buffered page based receives")
	Cc: stable@vger.kernel.org
	Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
	Reviewed-by: Simon Horman <horms@kernel.org>
	Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
	Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20260515182419.1597859-8-anthony.l.nguyen@intel.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 5d49b56)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-63946
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Muhammad Bilal <meatuni001@gmail.com>
commit 47f23a2

iso_recv_frame reads conn->sk under iso_conn_lock but releases the lock
before using sk, with no reference held. A concurrent iso_sock_kill()
can free sk in that window, causing use-after-free on sk->sk_state and
sock_queue_rcv_skb().

Fix by replacing the bare pointer read with iso_sock_hold(conn), which
calls sock_hold() while the spinlock is held, atomically elevating the
refcount before the lock drops. Add a drop_put label so sock_put() is
called on all exit paths where the hold succeeded.

Fixes: ccf74f2 ("Bluetooth: Add BTPROTO_ISO socket type")
	Cc: stable@vger.kernel.org
	Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
	Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit 47f23a2)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-63946
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Muhammad Bilal <meatuni001@gmail.com>
commit 4b5f8e6

iso_sock_close() calls iso_sock_clear_timer() before acquiring
lock_sock(sk).

iso_sock_clear_timer() reads iso_pi(sk)->conn twice without the
socket lock held:

    if (!iso_pi(sk)->conn)
        return;
    cancel_delayed_work(&iso_pi(sk)->conn->timeout_work);

Concurrently, iso_conn_del() executes under lock_sock(sk) and calls
iso_chan_del(), which sets iso_pi(sk)->conn to NULL and may result in
the final reference to the connection being dropped:

    CPU0                         CPU1
    ----                         ----
    iso_sock_clear_timer()
      if (conn != NULL) ...      lock_sock(sk)
                                   iso_chan_del()
                                   iso_pi(sk)->conn = NULL
      cancel_delayed_work(conn)  /* NULL deref or UAF */

iso_pi(sk)->conn is not stable across the unlock window, causing a
NULL pointer dereference or use-after-free.

Serialize iso_sock_clear_timer() with the socket lock by moving it
inside lock_sock()/release_sock(), matching the pattern used in
iso_conn_del() and all other call sites.

Fixes: ccf74f2 ("Bluetooth: Add BTPROTO_ISO socket type")
	Cc: stable@vger.kernel.org
	Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
	Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit 4b5f8e6)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-63975
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
commit 41c2713

If dcid is received for an already-assigned destination CID the spec
requires that both channels to be discarded, but calling l2cap_chan_del
may invalidate the tmp cursor created by list_for_each_entry_safe and
in fact it is the wrong procedure as the chan->dcid may be assigned
previously it really needs to be disconnected.

Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so
instead schedule l2cap_chan_timeout with delay 0 to close the channel
asynchronously.

Fixes: 15f02b9 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode")
	Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit 41c2713)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-63944
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Doruk Tan Ozturk <doruk@0sec.ai>
commit bfea609

hci_le_create_cis_sync() dereferences conn->conn_timeout after releasing
both rcu_read_lock() and hci_dev_lock(hdev).  The conn pointer was
obtained from an RCU-protected iteration over hdev->conn_hash.list and
is not valid once these locks are dropped.  A concurrent disconnect can
free the hci_conn between the unlock and the dereference, causing a
use-after-free read.

The cancellation mechanism in hci_conn_del() cannot prevent this because
hci_le_create_cis_pending() queues hci_create_cis_sync with data=NULL:

    hci_cmd_sync_queue(hdev, hci_create_cis_sync, NULL, NULL);

While hci_conn_del() dequeues with data=conn:

    hci_cmd_sync_dequeue(hdev, NULL, conn, NULL);

Since NULL != conn, the lookup in _hci_cmd_sync_lookup_entry() never
matches, and the pending work item is not cancelled.

Fix this by saving conn->conn_timeout into a local variable while the
locks are still held, so the stale conn pointer is never dereferenced
after unlock.

This is the same class of bug as the one fixed by commit 035c250
("Bluetooth: hci_sync: Fix UAF on le_read_features_complete") which
addressed the identical pattern in a different function.

This vulnerability was identified using 0sec.ai, an open-source
automated security auditing platform (https://github.com/0sec-labs).

Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED")
	Cc: stable@vger.kernel.org
	Reported-by: Doruk Tan Ozturk <doruk@0sec.ai>
	Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
	Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit bfea609)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-53209
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Yuqi Xu <xuyq21@lenovo.com>
commit 5c65b96

Existing advertising instances can already hold the maximum extended
advertising payload. When hci_adv_bcast_annoucement() prepends the
Broadcast Announcement service data to that payload, the combined data
may no longer fit in the temporary buffer used to rebuild the
advertising data.

Reject that case before copying the existing payload and report the
failure through the device log. This keeps the existing advertising
data intact and avoids overrunning the temporary buffer.

Fixes: 5725bc6 ("Bluetooth: hci_sync: Fix broadcast/PA when using an existing instance")
	Cc: stable@kernel.org
	Reported-by: Yuan Tan <yuantan098@gmail.com>
	Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
	Reported-by: Xin Liu <bird@lzu.edu.cn>
Assisted-by: Codex:GPT-5.4
	Signed-off-by: Yuqi Xu <xuyq21@lenovo.com>
	Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
	Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit 5c65b96)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-46123
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Michael Bommarito <michael.bommarito@gmail.com>
commit 21bd244

virtbt_rx_work() calls skb_put(skb, len) where len comes directly
from virtqueue_get_buf() with no validation against the buffer we
posted to the device. The RX skb is allocated in virtbt_add_inbuf()
and exposed to virtio as exactly 1000 bytes via sg_init_one().

Checking len against skb_tailroom(skb) is not sufficient because
alloc_skb() can leave more tailroom than the 1000 bytes actually
handed to the device. A malicious or buggy backend can therefore
report used.len between 1001 and skb_tailroom(skb), causing skb_put()
to include uninitialized kernel heap bytes that were never written by
the device.

The same path also accepts len == 0, in which case skb_put(skb, 0)
leaves the skb empty but virtbt_rx_handle() still reads the pkt_type
byte from skb->data, consuming uninitialized memory.

Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and
sg_init_one(), and gate virtbt_rx_work() on that same constant so
the bound checked matches the buffer actually exposed to the device.
Reject used.len == 0 in the same gate so an empty completion can
no longer reach virtbt_rx_handle().

Use bt_dev_err_ratelimited() because the length value comes from an
untrusted backend that can otherwise flood the kernel log.

Same class of bug as commit c04db81 ("net/9p: Fix buffer
overflow in USB transport layer"), which hardened the USB 9p
transport against unchecked device-reported length.

Fixes: 160fbcf ("Bluetooth: virtio_bt: Use skb_put to set length")
	Cc: stable@vger.kernel.org
	Cc: Soenke Huster <soenke.huster@eknoes.de>
	Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Assisted-by: Claude:claude-opus-4-7
	Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit 21bd244)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-46123
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Michael Bommarito <michael.bommarito@gmail.com>
commit daf2301

virtbt_rx_handle() reads the leading pkt_type byte from the RX skb
and forwards the remainder to hci_recv_frame() for every
event/ACL/SCO/ISO type, without checking that the remaining payload
is at least the fixed HCI header for that type.

After the preceding patch bounds the backend-supplied used.len to
[1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches
hci_recv_frame() with skb->len already pulled to 0. If the byte
happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification
fast-path in hci_dev_classify_pkt_type() dereferences
hci_acl_hdr(skb)->handle whenever the HCI device has an active
CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of
uninitialized RX-buffer data. The same hazard exists for every
packet type the driver accepts because none of the switch cases in
virtbt_rx_handle() check skb->len against the per-type minimum HCI
header size before handing the frame to the core.

After stripping pkt_type, require skb->len to cover the fixed
header size for the selected type (event 2, ACL 4, SCO 3, ISO 4)
before calling hci_recv_frame(); drop ratelimited otherwise.
Unknown pkt_type values still take the original kfree_skb() default
path.

Use bt_dev_err_ratelimited() because both the length and pkt_type
values come from an untrusted backend that can otherwise flood the
kernel log.

Fixes: 160fbcf ("Bluetooth: virtio_bt: Use skb_put to set length")
	Cc: stable@vger.kernel.org
	Cc: Soenke Huster <soenke.huster@eknoes.de>
	Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Assisted-by: Claude:claude-opus-4-7
	Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit daf2301)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-63947
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Muhammad Bilal <meatuni001@gmail.com>
commit 2a3ac9e

hidp_input_report() reads keyboard and mouse payload data from an skb
without first verifying that skb->len contains enough data.

hidp_recv_intr_frame() pulls the 1-byte HIDP header before dispatching
to hidp_input_report(). If a paired device sends a truncated packet,
the handler reads beyond the valid skb data, resulting in an
out-of-bounds read of skb data. The OOB bytes may be interpreted as
phantom key presses or spurious mouse movement.

Replace the open-coded length tracking and pointer arithmetic with
skb_pull_data() calls. skb_pull_data() returns NULL if the requested
bytes are not present, eliminating the need for a manual size variable
and the separate skb->len guard.

Fixes: 1da177e ("Linux-2.6.12-rc2")
	Cc: stable@vger.kernel.org
	Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
	Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit 2a3ac9e)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-64051
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Zack McKevitt <zachary.mckevitt@oss.qualcomm.com>
commit aa16b2b

The call to remap_pfn_range in qaic_gem_object_mmap is susceptible to
(re)mapping beyond the VMA if the BO is too large. This can cause use
after free issues when munmap() unmaps only the VMA region and not the
additional mappings. To prevent this, check the remaining size of the
VMA before remapping and truncate the remapped length if sg->length is
too large.

	Reported-by: Lukas Maar <lukas.maar@tugraz.at>
Fixes: ff13be8 ("accel/qaic: Add datapath")
	Reviewed-by: Karol Wachowski <karol.wachowski@linux.intel.com>
	Signed-off-by: Zack McKevitt <zachary.mckevitt@oss.qualcomm.com>
	Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
[jhugo: fix braces from checkpatch --strict]
	Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260430193858.1178641-1-zachary.mckevitt@oss.qualcomm.com
(cherry picked from commit aa16b2b)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-53072
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Pauli Virtanen <pav@iki.fi>
commit 5c7209a

When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls
hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm()
assumes it is held, and if conn is deleted concurrently -> UAF.

Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen,
and HCI_EV_CONN_REQUEST is not generated for ISO.  In the non-deferred
listening socket code paths, hci_connect_cfm(conn) is called with
hdev->lock held.

Fix by holding the lock.

Fixes: 70c4642 ("Bluetooth: Refactor connection request handling")
	Signed-off-by: Pauli Virtanen <pav@iki.fi>
	Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
(cherry picked from commit 5c7209a)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-64515
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Johannes Berg <johannes.berg@intel.com>
commit a74e893

If either reconf or EPCS multi-link element (MLE) is contained in
a non-transmitted profile, the defragmentation routine is called
with a pointer to the defragmented copy, but the original elements.

This is incorrect for two reasons:
 - if the original defragmentation was needed, it will not find the
   correct data
 - if the original frame is at a higher address, the parsing will
   potentially overrun the heap data (though given the layout of
   the buffers, only into the new defragmentation buffer, and then
   it has to stop and fail once that's filled with copied data.

Fix it by tracking the container along with the pointer and in
doing so also unify the two almost identical defragmentation
routines.

Fixes: 4d70e9c ("wifi: mac80211: defragment reconfiguration MLE when parsing")
	Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
	Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20260508091031.8a6c34613178.I4de16ebbce2d27f2f8f98fc49949c7a376c2fe8d@changeid
	Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit a74e893)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-64515
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Johannes Berg <johannes.berg@intel.com>
commit fe2d61a

When parsing a beacon, mac80211 erroneously inherits any
reconfiguration or EPCS multi-link elements from the outer
elements into the multi-BSSID profile that's requested, if
connected to a non-transmitted BSS, unless that profile
has a non-inheritance element.

This also happens if parsing a multi-BSSID profile that
doesn't have a non-inheritance element.

Fix this by having an empty non-inheritance element so
cfg80211_is_element_inherited() is invoked in these cases
and causes the parser to skip the elements that should
never be inherited.

Fixes: cf36cde ("wifi: mac80211: Add support for parsing Reconfiguration Multi Link element")
Fixes: 24711d6 ("wifi: mac80211: Support parsing EPCS ML element")
	Reviewed-by: Ilan Peer <ilan.peer@intel.com>
	Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20260508091032.92184c0a3f08.I3c43b0b63d2cef8a4ddddaef1c2faaeb1de711ad@changeid
	Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit fe2d61a)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-52947
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Mingyu Wang <25181214217@stu.xidian.edu.cn>
commit a217113

In qrtr_port_remove(), the socket reference count is decremented via
__sock_put() before the port is removed from the qrtr_ports XArray and
before the RCU grace period elapses.

This breaks the fundamental RCU update paradigm. It exposes a race
window where a concurrent RCU reader (such as qrtr_reset_ports() or
qrtr_port_lookup()) can obtain a pointer to the socket from the XArray,
and attempt to call sock_hold() on a socket whose reference count has
already dropped to zero.

This exact race condition was hit during syzkaller fuzzing, leading to
the following refcount saturation warning and a potential Use-After-Free:

  refcount_t: saturated; leaking memory.
  WARNING: CPU: 3 PID: 1273 at lib/refcount.c:22 refcount_warn_saturate+0xae/0x1d0
  Modules linked in: qrtr(+) bochs drm_shmem_helper ...
  Call Trace:
   <TASK>
   qrtr_reset_ports net/qrtr/af_qrtr.c:768 [inline] [qrtr]
   __qrtr_bind.isra.0+0x48b/0x570 net/qrtr/af_qrtr.c:805 [qrtr]
   qrtr_bind+0x17d/0x210 net/qrtr/af_qrtr.c:901 [qrtr]
   kernel_bind+0xe4/0x120 net/socket.c:3592
   qrtr_ns_init+0x1a6/0x380 net/qrtr/ns.c:715 [qrtr]
   qrtr_proto_init+0x3b/0xff0 net/qrtr/af_qrtr.c:169 [qrtr]
   do_one_initcall+0xf5/0x5e0 init/main.c:1283
   ...
   </TASK>

Fix this by deferring the reference count decrement until after the
xa_erase() and the synchronize_rcu() complete.

(Note: The v1 of this patch incorrectly replaced __sock_put() with
sock_put(). As Simon Horman pointed out, the callers of qrtr_port_remove()
still hold a reference to the socket, so freeing the socket memory here
would lead to a subsequent UAF in the caller. Thus, the __sock_put() is
kept, but only repositioned to close the RCU race.)

Fixes: bdabad3 ("net: Add Qualcomm IPC router")
	Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
	Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260604064801.1180388-1-w15303746062@163.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit a217113)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-53182
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Yuqi Xu <xuyuqiabc@gmail.com>
commit 4cd9295

nl80211_parse_rnr_elems() stores the parsed element count in a
u8-backed cfg80211_rnr_elems::cnt field and uses that count to size
the flexible array allocation.

Reject nested NL80211_ATTR_EMA_RNR_ELEMS input once the count reaches
255, before incrementing it again. This keeps the parser aligned with
the data structure it fills and matches the existing bound check used
by nl80211_parse_mbssid_elems().

Fixes: dbbb27e ("cfg80211: support RNR for EMA AP")
	Cc: stable@kernel.org
	Reported-by: Yuan Tan <yuantan098@gmail.com>
	Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
	Reported-by: Xin Liu <bird@lzu.edu.cn>
Assisted-by: Codex:gpt-5.4
	Signed-off-by: Yuqi Xu <xuyuqiabc@gmail.com>
	Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Link: https://patch.msgid.link/20260529152542.1412734-1-n05ec@lzu.edu.cn
	Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit 4cd9295)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…bled

jira KERNEL-1569
cve CVE-2026-64037
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Cole Leavitt <cole@unwrap.rs>
commit 92cee08

When the TLC notification disables AMSDU for a TID, the MLD driver sets
max_tid_amsdu_len to the sentinel value 1. The TSO segmentation path in
iwl_mld_tx_tso_segment() checks for zero but not for this sentinel,
allowing it to reach the num_subframes calculation:

  num_subframes = (max_tid_amsdu_len + pad) / (subf_len + pad)
                = (1 + 2) / (1534 + 2) = 0

This zero propagates to iwl_tx_tso_segment() which sets:

  gso_size = num_subframes * mss = 0

Calling skb_gso_segment() with gso_size=0 creates over 32000 tiny
segments from a single GSO skb. This floods the TX ring with ~1024
micro-frames (the rest are purged), creating a massive burst of TX
completion events that can lead to memory corruption and a subsequent
use-after-free in TCP's retransmit queue (refcount underflow in
tcp_shifted_skb, NULL deref in tcp_rack_detect_loss).

The MVM driver is immune because it checks mvmsta->amsdu_enabled before
reaching the num_subframes calculation. The MLD driver has no equivalent
bitmap check and relies solely on max_tid_amsdu_len, which does not
catch the sentinel value.

Fix this by detecting the sentinel value (max_tid_amsdu_len == 1) at the
existing check and falling back to non-AMSDU TSO segmentation. Also add
a WARN_ON_ONCE guard after the num_subframes division as defense-in-depth
to catch any future code paths that produce zero through a different
mechanism.

	Suggested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Fixes: d1e879e ("wifi: iwlwifi: add iwlmld sub-driver")
	Signed-off-by: Cole Leavitt <cole@unwrap.rs>
Link: https://patch.msgid.link/20260405054145.1064152-3-cole@unwrap.rs
	Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
(cherry picked from commit 92cee08)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-64117
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Sarika Sharma <sarika.sharma@oss.qualcomm.com>
commit cc18fff

Currently, RX bitrate statistics are not updated for packets received
on the mesh forwarding path during fast RX processing. This results in
incomplete RX rate tracking in station dump outputs for mesh scenarios.

Update ieee80211_invoke_fast_rx() to record the RX rate using
sta_stats_encode_rate() and store it in the last_rate field of
ieee80211_sta_rx_stats when RX_QUEUED is returned from
ieee80211_rx_mesh_data(). This ensures that RX bitrate is properly
accounted for in both RSS and non-RSS paths.

	Signed-off-by: Sarika Sharma <sarika.sharma@oss.qualcomm.com>
Link: https://patch.msgid.link/20251024043627.1640447-1-sarika.sharma@oss.qualcomm.com
	Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit cc18fff)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
cve CVE-2026-64117
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Zhao Li <enderaoelyther@gmail.com>
commit d71c841

ieee80211_invoke_fast_rx() reads RX status through
IEEE80211_SKB_RXCB(skb), which aliases the same skb->cb storage
that ieee80211_rx_mesh_data() reuses as IEEE80211_TX_INFO.  In the
unicast forward path, mesh_data does:

	info = IEEE80211_SKB_CB(fwd_skb);
	memset(info, 0, sizeof(*info));

on the same skb the caller still names via rx->skb, then either
queues the skb for TX (success) or kfree_skb()'s it (no-route)
before returning RX_QUEUED.  The caller's RX_QUEUED arm then
calls sta_stats_encode_rate(status) on memory that is either
zeroed (success path) or freed (no-route path).  The latter is
KASAN slab-use-after-free in ieee80211_prepare_and_rx_handle.

Fix by encoding the rate from status before invoking
ieee80211_rx_mesh_data(), so the RX_QUEUED arm consumes a value
captured while status was still backed by valid memory.

Fixes: 3468e1e ("wifi: mac80211: add mesh fast-rx support")
	Cc: stable@vger.kernel.org
	Signed-off-by: Zhao Li <enderaoelyther@gmail.com>
Link: https://patch.msgid.link/20260509043427.60322-2-enderaoelyther@gmail.com
	Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit d71c841)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
…lers

jira KERNEL-1569
cve CVE-2026-64255
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Junrui Luo <moonafterrain@outlook.com>
commit f056fc2

Three BA session handlers use ffs(ba_data->sta_mask) - 1 to derive a
station ID without checking that sta_mask is non-zero. When sta_mask is
zero, ffs() returns 0 and the subtraction wraps to 0xFFFFFFFF, causing
an out-of-bounds access on fw_id_to_link_sta[].

Add WARN_ON_ONCE(!ba_data->sta_mask) guards before each ffs() call,
consistent with the existing check in iwl_mld_ampdu_rx_start().

	Reported-by: Yuhao Jiang <danisjiang@gmail.com>
	Cc: stable@vger.kernel.org
	Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Link: https://patch.msgid.link/SYBPR01MB788115C6CE873271A9A15A25AF51A@SYBPR01MB7881.ausprd01.prod.outlook.com
	Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
(cherry picked from commit f056fc2)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1569
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Crystal Wood <crwood@redhat.com>
commit 3138df6
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-6.12.0-211.53.1.el10_2/3138df6f.failed

Comparing to exactly 1 will fail if more than one ring buffer
event was seen since the last call to timerlat_bpf_wait(), which
can happen in some race scenarios.

	Signed-off-by: Crystal Wood <crwood@redhat.com>
Link: https://lore.kernel.org/r/20251112152529.956778-5-crwood@redhat.com
	Signed-off-by: Tomas Glozar <tglozar@redhat.com>
(cherry picked from commit 3138df6)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	tools/tracing/rtla/src/timerlat_top.c
jira KERNEL-1569
cve CVE-2026-72129
Rebuild_History Non-Buildable kernel-6.12.0-211.53.1.el10_2
commit-author Bryam Vargas <hexlabsecurity@proton.me>
commit 48c0162

nvmet_rdma_use_inline_sg() maps the host-controlled inline data offset
into the per-command inline scatterlist.  The bounds check admits any
offset with off + len <= inline_data_size, but the mapping still assumes
the data begins in the first inline page:

	sg->offset = off;
	sg->length = min_t(int, len, PAGE_SIZE - off);

When a port is configured with inline_data_size > PAGE_SIZE (settable up
to max(SZ_16K, PAGE_SIZE)), an offset in (PAGE_SIZE, inline_data_size]
makes "PAGE_SIZE - off" underflow, so sg->length is set to ~4 GiB and
the block backend reads far past the first inline page.  num_pages(len)
also ignores the offset, so an in-bounds offset whose [off, off+len)
span crosses a page boundary under-counts the scatterlist.

Map the offset properly: split it into a page index and an in-page
offset, start the scatterlist at that page, and size the page count from
page_off + len.  Because the request scatterlist may now start at
inline_sg[page_idx] rather than inline_sg[0], generalize the inline-SGL
identity test in nvmet_rdma_release_rsp() to a range test; otherwise the
persistent inline scatterlist is mistaken for an allocated one and
nvmet_req_free_sgls() frees an inline page (and warns in
free_large_kmalloc()).

Fixes: 0d5ee2b ("nvmet-rdma: support max(16KB, PAGE_SIZE) inline data")
	Cc: stable@vger.kernel.org
	Suggested-by: Keith Busch <kbusch@kernel.org>
	Reported-by: Bryam Vargas <hexlabsecurity@proton.me>
	Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
	Signed-off-by: Keith Busch <kbusch@kernel.org>
(cherry picked from commit 48c0162)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>
Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v6.12~1..kernel-mainline: 138299
Number of commits in rpm: 43
Number of commits matched with upstream: 36 (83.72%)
Number of commits in upstream but not in rpm: 138263
Number of commits NOT found in upstream: 7 (16.28%)

Rebuilding Kernel on Branch rocky10_2_rebuild_kernel-6.12.0-211.53.1.el10_2 for kernel-6.12.0-211.53.1.el10_2
Clean Cherry Picks: 35 (97.22%)
Empty Cherry Picks: 1 (2.78%)
_______________________________

Full Details Located here:
ciq/ciq_backports/kernel-6.12.0-211.53.1.el10_2/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

@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.

🥌

@bmastbergen
bmastbergen requested a review from a team September 10, 2026 12:41
@PlaidCat PlaidCat changed the title [rocky10_2] History Rebuild through kernel-6.12.0-211.51.1.el10_2 [rocky10_2] History Rebuild through kernel-6.12.0-211.53.1.el10_2 Sep 10, 2026
@PlaidCat
PlaidCat requested a review from a team September 10, 2026 17:08
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