Conversation
jira KERNEL-1683
cve {CVE-2026-68156
cve [RHEL-237472]
cve Bot)
cve Backport
cve (CKI
cve update
cve authorizer
cve after
cve ,_len
Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10
commit-author Shuangpeng Bai <shuangpeng.kernel@gmail.com>
commit 937d61f
ceph_x_create_authorizer() caches au->buf->vec.iov_base and
au->buf->vec.iov_len in struct ceph_auth_handshake. These
cached values are then used by the messenger connect code when
sending the authorizer.
ceph_x_update_authorizer() can rebuild the authorizer when a newer
service ticket is available. If the rebuilt authorizer no longer
fits in the existing buffer, ceph_x_build_authorizer() drops its
reference to au->buf and allocates a new one. If this is the final
reference, ceph_buffer_put() frees the old ceph_buffer and its
vec.iov_base, but auth->authorizer_buf still points at that freed
memory.
A subsequent msgr1 reconnect can therefore queue the stale pointer
and trigger a KASAN slab-use-after-free in _copy_from_iter() while
tcp_sendmsg() copies the authorizer.
Refresh auth->authorizer_buf and auth->authorizer_buf_len after a
successful authorizer rebuild so the messenger sends the current
buffer.
Cc: stable@vger.kernel.org
Fixes: 0bed9b5 ("libceph: add update_authorizer auth method")
Closes: https://lore.kernel.org/all/E378850E-106C-427B-A241-970EB2D054D7@gmail.com/
Signed-off-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 937d61f)
Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 cve CVE-2026-68155 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Raphael Zimmer <raphael.zimmer@tu-ilmenau.de> commit 40480ee A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the "BUG_ON(monc->monmap->num_mon < 1)" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop "log output for unusual values of num_mon" part ] Cc: stable@vger.kernel.org Signed-off-by: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> (cherry picked from commit 40480ee) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 cve CVE-2026-45942 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Yongjian Sun <sunyongjian1@huawei.com> commit bdc56a9 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-4.18.0-553.169.1.el8_10/bdc56a9c.failed A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like: ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice: folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window. Additionally, this change addresses the following issues: When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered: corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report: ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock. Signed-off-by: Yongjian Sun <sunyongjian1@huawei.com> Reviewed-by: Zhang Yi <yi.zhang@huawei.com> Reviewed-by: Baokun Li <libaokun1@huawei.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20260106090820.836242-1-sunyongjian@huaweicloud.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org (cherry picked from commit bdc56a9) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # fs/ext4/mballoc.c
jira KERNEL-1683 cve CVE-2026-68159 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Andy Shevchenko <andriy.shevchenko@linux.intel.com> commit 04d8712 In a few cases the code compares 32-bit value to a SIZE_MAX derived constant which is much higher than that value on 64-bit platforms, Clang, in particular, is not happy about this net/ceph/osdmap.c:1441:10: error: result of comparison of constant 4611686018427387891 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 1441 | if (len > (SIZE_MAX - sizeof(*pg)) / sizeof(u32)) | ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/ceph/osdmap.c:1624:10: error: result of comparison of constant 2305843009213693945 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 1624 | if (len > (SIZE_MAX - sizeof(*pg)) / (2 * sizeof(u32))) | ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix this by casting to size_t. Note, that possible replacement of SIZE_MAX by U32_MAX may lead to the behaviour changes on the corner cases. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> (cherry picked from commit 04d8712) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683
cve {CVE-2026-68159
cve [RHEL-237150]
cve Bot)
cve Backport
cve (CKI
cve CEPH_PG_MAX_SIZE
cve to
cve length
cve temp,upmap,upmap_items
Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10
commit-author Xiang Mei <xmei5@asu.edu>
commit 9f00f9c
__decode_pg_temp() decodes an user-controlled length but only rejects
values large enough to overflow the allocation; it does not bound it to
CEPH_PG_MAX_SIZE. The helper backs both pg_temp and pg_upmap decoding, and
apply_upmap()/get_temp_osds() later copy the decoded list into the fixed-size
on-stack array struct ceph_osds.osds[CEPH_PG_MAX_SIZE]. A monitor that sends
an OSDMap with a pg_temp/pg_upmap entry longer than 32 thus causes a stack
out-of-bounds write.
An OSD set for a single PG can never exceed CEPH_PG_MAX_SIZE, so reject longer
entries at decode time. The bound is well below the old overflow threshold, so
it also covers the allocation-size overflow the previous check guarded against.
BUG: KASAN: stack-out-of-bounds in ceph_pg_to_up_acting_osds
Write of size 4 ... by task exploit
kasan_report (mm/kasan/report.c:595)
ceph_pg_to_up_acting_osds (net/ceph/osdmap.c:2617 net/ceph/osdmap.c:2833)
calc_target (net/ceph/osd_client.c:1638)
__submit_request (net/ceph/osd_client.c:2394)
ceph_osdc_start_request (net/ceph/osd_client.c:2490)
ceph_osdc_call (net/ceph/osd_client.c:5164)
rbd_dev_image_probe (drivers/block/rbd.c:6899)
do_rbd_add (drivers/block/rbd.c:7138)
...
kernel BUG at net/ceph/osdmap.c:2670!
[ idryomov: do the same in __decode_pg_upmap_items() ]
Cc: stable@vger.kernel.org
Fixes: a303bb0 ("libceph: introduce and switch to decode_pg_mapping()")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Reviewed-by: Alex Markuze <amarkuze@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 9f00f9c)
Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 cve CVE-2025-40323 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Quanmin Yan <yanquanmin1@huawei.com> commit a1f3058 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-4.18.0-553.169.1.el8_10/a1f30589.failed Recently, we discovered the following issue through syzkaller: BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0 Read of size 4 at addr ff11000001b3c69c by task syz.xxx ... Call Trace: <TASK> dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Based on experimentation and analysis, during framebuffer unregistration, only the memory of fb_info->modelist is freed, without setting the corresponding fb_display[i]->mode to NULL for the freed modes. This leads to UAF issues during subsequent accesses. Here's an example of reproduction steps: 1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1; 2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP); 3. Switch console from fb to VGA (to allow normal rmmod of the ko); 4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[]; 5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0. Add a check in do_unregister_framebuffer(): if the mode to be freed exists in fb_display[], set the corresponding mode pointer to NULL. Signed-off-by: Quanmin Yan <yanquanmin1@huawei.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org (cherry picked from commit a1f3058) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # drivers/video/fbdev/core/fbmem.c
jira KERNEL-1683 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author David Rosca <david.rosca@amd.com> commit dc8f9f0 There can be multiple engine info packages in one IB and the first one may be common engine, not decode/encode. We need to parse the entire IB instead of stopping after finding first engine info. Signed-off-by: David Rosca <david.rosca@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit dc8f9f0) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 cve CVE-2026-46204 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Benjamin Cheng <benjamin.cheng@amd.com> commit 2444eb0 Rewrite the IB parsing to use amdgpu_ib_get_value() which handles the bounds checks. Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Ruijing Dong <ruijing.dong@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org (cherry picked from commit 2444eb0) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 cve CVE-2026-46199 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Benjamin Cheng <benjamin.cheng@amd.com> commit 0a78f2b Check bounds against the end of the BO whenever we access the msg. Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Ruijing Dong <ruijing.dong@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org (cherry picked from commit 0a78f2b) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Benjamin Cheng <benjamin.cheng@amd.com> commit 3c5367d As pointed out by SDL, the previous condition may be vulnerable to overflow. Fixes: 0a78f2b ("drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg") Cc: SDL <sdl@nppct.ru> Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com> Reviewed-by: Ruijing Dong <ruijing.dong@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3c5367d) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 cve CVE-2026-46230 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Benjamin Cheng <benjamin.cheng@amd.com> commit b193019 Check bounds against the end of the BO whenever we access the msg. Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Ruijing Dong <ruijing.dong@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org (cherry picked from commit b193019) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Benjamin Cheng <benjamin.cheng@amd.com> commit db00257 As pointed out by SDL, the previous condition may be vulnerable to overflow. Fixes: b193019 ("drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg") Cc: SDL <sdl@nppct.ru> Signed-off-by: Benjamin Cheng <benjamin.cheng@amd.com> Reviewed-by: Ruijing Dong <ruijing.dong@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit db00257) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author David (Ming Qiang) Wu <David.Wu3@amd.com> commit 4d73905 If the supplied msg[2] (num_buffers) is 0x3FFFFFFF, the expression 6 + num_buffers * 4 wraps to 2 and the bounds check passes, letting the parser loop far past the end of the message BO. Triggering it additionally requires a ~4GiB mapping so that msg[1] survives the earlier "header does not fit in BO" check. Rewrite the test in division form, which is overflow-free by construction. Also update the message to reflect that msg is invalid. Fixes: b193019 ("drm/amdgpu/vcn3: Prevent OOB reads when parsing dec msg") Fixes: 0a78f2b ("drm/amdgpu/vcn4: Prevent OOB reads when parsing dec msg") Cc: stable@vger.kernel.org Signed-off-by: David (Ming Qiang) Wu <David.Wu3@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 4d73905) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author James Zhu <James.Zhu@amd.com> commit c30e326 Keep amdgpu_ctx_mgr in ctx structure to track fpriv. v2: add missing fpriv declaration lost in rebase Signed-off-by: James Zhu <James.Zhu@amd.com> Acked-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c30e326) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 cve CVE-2026-68273 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Tvrtko Ursulin <tvrtko.ursulin@igalia.com> commit 1b5e413 There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 79610d3 ("drm/amdgpu: fix pstate setting issue") Cc: Chengming Gui <Jack.Gui@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 1b5e413) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1683 cve CVE-2026-64556 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Taeyang Lee <0wn@theori.io> commit 037a3c4 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-4.18.0-553.169.1.el8_10/037a3c43.failed perf_event_remove_on_exec() removes events by calling perf_event_exit_event(). For top-level events, this removes the event from the context with DETACH_EXIT only. This can leave inconsistent group state when a removed event is a group leader and the group contains siblings without remove_on_exec. If the group was active, the surviving siblings can remain active and attached to the removed leader's sibling list, but are no longer represented by a valid group leader on the PMU context active lists. A later close of the removed leader uses DETACH_GROUP and can promote the still-active siblings from this stale group state. The next schedule-in can then add an already-linked active_list entry again, corrupting the PMU context active list. With DEBUG_LIST enabled, this is caught as a list_add double-add in merge_sched_in(). Fix this by detaching group relationships when remove_on_exec removes an event. This preserves the existing task-exit and revoke behavior, while ensuring surviving siblings are ungrouped before the removed event leaves the context. Fixes: 2e498d0 ("perf: Add support for event removal on exec") Signed-off-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/ai65GgZcC0LAlWLG@Taeyangs-MacBook-Pro.local (cherry picked from commit 037a3c4) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # kernel/events/core.c
jira KERNEL-1683 cve CVE-2026-74753 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Kyle Zeng <kylebot@openai.com> commit fa091f4 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-4.18.0-553.169.1.el8_10/fa091f46.failed perf_event_remove_on_exec() sets remove-on-exec events to the EXIT state and detaches their group relationships. The event's file descriptor can remain open, however, and perf_event_open() currently accepts that event as a group leader because its early validation rejects only REVOKED and DEAD events. A new sibling can consequently be linked to the detached leader. When the leader is closed, perf_group_detach() observes that its PERF_ATTACH_GROUP bit is already clear and skips the new sibling. The sibling then retains a group_leader pointer to the freed event. Reject group leaders in the EXIT state. Perform the check while holding the shared context mutex so that an exec in the target task cannot detach the leader between validation and group attachment. [peterz: make the earlier test fully consistent] Fixes: 037a3c4 ("perf/core: Detach event groups during remove_on_exec") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Kyle Zeng <kylebot@openai.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260806205655.75722-1-kylebot@openai.com (cherry picked from commit fa091f4) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # kernel/events/core.c
jira KERNEL-1683 cve CVE-2026-63875 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Zeng Heng <zengheng4@huawei.com> commit c2ff476 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-4.18.0-553.169.1.el8_10/c2ff4764.failed When huge_pmd_unshare() is called to unshare a PMD table, the tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true but the aarch64 tlb_flush() only checked tlb->freed_tables to determine whether to use TLBF_NONE (vae1is, invalidates walk cache) or TLBF_NOWALKCACHE (vale1is, leaf-only). This caused the stale PMD page table entry to remain in the walk cache after unshare, potentially leading to incorrect page table walks. Fix by including unshared_tables in the check, so that when unsharing tables, TLBF_NONE is used and the walk cache is properly invalidated. Here is the detailed distinction between vae1is and vale1is: | Instruction Combination | Actual Invalidation Scope | | ------------------------ | --------------------------------------------------| | `VAE1IS` + TTL=`0` | All entries at all levels (full invalidation) | | `VAE1IS` + TTL=`2` (L2) | Non-leaf at Level 0/1 + leaf at Level 2 | | `VALE1IS` + TTL=`0` | Leaf entries at all levels (non-leaf not cleared) | | `VALE1IS` + TTL=`2` (L2) | Leaf entry at Level 2 only | Signed-off-by: Zeng Heng <zengheng4@huawei.com> Fixes: 8ce720d ("mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using mmu_gather") Cc: <stable@vger.kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit c2ff476) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # arch/arm64/include/asm/tlb.h
jira KERNEL-1683 cve CVE-2026-64034 Rebuild_History Non-Buildable kernel-4.18.0-553.169.1.el8_10 commit-author Erni Sri Satya Vennela <ernis@linux.microsoft.com> commit 35f0f0a 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-4.18.0-553.169.1.el8_10/35f0f0a2.failed In mana_hwc_rx_event_handler(), resp->response.hwc_msg_id is read from DMA-coherent memory and bounds-checked, then mana_hwc_handle_resp() re-reads the same field from the same DMA buffer for test_bit() and pointer arithmetic. DMA-coherent memory is mapped uncacheable on x86 and is shared, unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes directly to host-visible memory. A H/W can modify the value between the check and the use, bypassing the bounds validation. Fix this by reading hwc_msg_id exactly once using READ_ONCE() into a stack-local variable in mana_hwc_rx_event_handler(), and passing the validated value as a parameter to mana_hwc_handle_resp(). Fixes: ca9c54d ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com> Link: https://patch.msgid.link/20260514194156.466823-1-ernis@linux.microsoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit 35f0f0a) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # drivers/net/ethernet/microsoft/mana/hw_channel.c
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v4.18~1..kernel-mainline: 660097 Number of commits in rpm: 25 Number of commits matched with upstream: 19 (76.00%) Number of commits in upstream but not in rpm: 660078 Number of commits NOT found in upstream: 6 (24.00%) Rebuilding Kernel on Branch rocky8_10_rebuild_kernel-4.18.0-553.169.1.el8_10 for kernel-4.18.0-553.169.1.el8_10 Clean Cherry Picks: 13 (68.42%) Empty Cherry Picks: 6 (31.58%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-4.18.0-553.169.1.el8_10/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
jira KERNEL-1700 cve CVE-2026-64102 Rebuild_History Non-Buildable kernel-4.18.0-553.170.1.el8_10 commit-author Michael Bommarito <michael.bommarito@gmail.com> commit 0ce1bc9 A malicious connected siw peer can send an iWARP FPDU whose MPA length field (c_hdr->mpa_len, 16 bit big-endian, peer-controlled) is smaller than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP parses the full header in siw_get_hdr() based on iwarp_pktinfo[opcode] .hdr_len, but never compares mpa_len against that header length. siw_tcp_rx_data() then derives srx->fpdu_part_rem = be16_to_cpu(mpa_len) - fpdu_part_rcvd + MPA_HDR_SIZE; where fpdu_part_rcvd equals iwarp_pktinfo[opcode].hdr_len at this point. For a tagged WRITE (hdr_len 16, MPA_HDR_SIZE 2) the smallest on-wire mpa_len of 0 yields fpdu_part_rem = -14, and any mpa_len below hdr_len - MPA_HDR_SIZE underflows to a negative int. The signed value then flows into siw_proc_write()/siw_proc_rresp() as bytes = min(srx->fpdu_part_rem, srx->skb_new); is handed to siw_check_mem() as an int len (whose interval check addr + len > mem->va + mem->len is satisfied for a valid base when len is negative), and reaches siw_rx_data() -> siw_rx_kva() / siw_rx_umem() -> skb_copy_bits() as a signed copy length. The header copy branch in skb_copy_bits() promotes that to size_t, producing a multi-gigabyte read. KASAN under a KUnit harness that drives the real kernel TCP receive path -- a loopback AF_INET socketpair, the malformed FPDU written via kernel_sendmsg, sk_data_ready firing in softirq, tcp_read_sock dispatching to siw_tcp_rx_data -- reports: BUG: KASAN: use-after-free in skb_copy_bits+0x284/0x480 Read of size 4294967295 at addr ffff888... Call Trace: skb_copy_bits siw_rx_kva siw_rx_data siw_check_mem siw_proc_write siw_tcp_rx_data __tcp_read_sock siw_qp_llp_data_ready tcp_data_ready tcp_data_queue Add the missing invariant at the earliest point where the peer header is fully assembled. iwarp_pktinfo[*].hdr_len - MPA_HDR_SIZE is exactly the value the siw transmitter uses as the minimum mpa_len for each opcode (drivers/infiniband/sw/siw/siw_qp.c:33), so this matches the protocol contract. Out-of-range FPDUs terminate the connection with TERM_ERROR_LAYER_LLP / LLP_ETYPE_MPA / LLP_ECODE_FPDU_START -- which is RFC 5044 Section 8 error code 3 ("Marker and ULPDU Length fields do not agree on the start of an FPDU"), the correct framing-error class for this inconsistency. Fixes: 8b6a361 ("rdma/siw: receive path") Link: https://patch.msgid.link/r/20260513175325.2042630-2-michael.bommarito@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Assisted-by: Claude:claude-opus-4-7 Acked-by: Bernard Metzler <bernard.metzler@linux.dev> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> (cherry picked from commit 0ce1bc9) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1700 cve CVE-2026-68299 Rebuild_History Non-Buildable kernel-4.18.0-553.170.1.el8_10 commit-author Harshaka Narayana <harshaka.narayana@broadcom.com> commit 34a71f5 vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively. Fixes: 45dac1d ("vmxnet3: Changes for vmxnet3 adapter version 2 (fwd)") Signed-off-by: Harshaka Narayana <harshaka.narayana@broadcom.com> Reviewed-by: Ronak Doshi <ronak.doshi@broadcom.com> Reviewed-by: Sankararaman Jayaraman <sankararaman.jayaraman@broadcom.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260713140915.3381715-1-harshaka.narayana@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> (cherry picked from commit 34a71f5) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1700 Rebuild_History Non-Buildable kernel-4.18.0-553.170.1.el8_10 commit-author Denis Efremov <efremov@linux.com> commit fcc32a2 octeon_mbox_process_cmd() directly writes the PCI_EXP_DEVCTL_BCR_FLR bit, which bypasses timing requirements imposed by the PCIe spec. This patch fixes the function to use the pcie_flr() interface instead. Signed-off-by: Denis Efremov <efremov@linux.com> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> (cherry picked from commit fcc32a2) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1700 cve CVE-2026-72329 Rebuild_History Non-Buildable kernel-4.18.0-553.170.1.el8_10 commit-author Yuho Choi <dbgh9129@gmail.com> commit 5c0e3ba The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST. Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup. Fixes: ca6139f ("liquidio CN23XX: sysfs VF config support") Fixes: 8c978d0 ("liquidio CN23XX: Mailbox support") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Link: https://patch.msgid.link/20260701040847.1897845-1-dbgh9129@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> (cherry picked from commit 5c0e3ba) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
jira KERNEL-1700 cve CVE-2026-72099 Rebuild_History Non-Buildable kernel-4.18.0-553.170.1.el8_10 commit-author Mikulas Patocka <mpatocka@redhat.com> commit edf025f 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-4.18.0-553.170.1.el8_10/edf025f0.failed hash_offset is already incremented in the loop "for (i = 0; i < to_copy; i++, ts--)". Do not increment it again. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Assisted-by: Claude:claude-opus-4.6 Fixes: 84597a4 ("dm-integrity: dm integrity: add optional discard support") Cc: stable@vger.kernel.org (cherry picked from commit edf025f) Signed-off-by: Jonathan Maple <jmaple@ciq.com> # Conflicts: # drivers/md/dm-integrity.c
Rebuild_History BUILDABLE Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50% Number of commits in upstream range v4.18~1..kernel-mainline: 660130 Number of commits in rpm: 13 Number of commits matched with upstream: 5 (38.46%) Number of commits in upstream but not in rpm: 660125 Number of commits NOT found in upstream: 8 (61.54%) Rebuilding Kernel on Branch rocky8_10_rebuild_kernel-4.18.0-553.170.1.el8_10 for kernel-4.18.0-553.170.1.el8_10 Clean Cherry Picks: 4 (80.00%) Empty Cherry Picks: 1 (20.00%) _______________________________ Full Details Located here: ciq/ciq_backports/kernel-4.18.0-553.170.1.el8_10/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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an automated kernel history rebuild using cron and internal tooling. It follows the same process used for previous history rebuilds:
src.rpmpackagessrc.rpm:4.18.0-553)git cherry-pickrpmbuild -bpfor the correspondingsrc.rpmJIRA Tickets
Rebuild Splat Inspection
kernel-4.18.0-553.170.1.el8_10
BUILD
KSelfTests