Skip to content

[ciqlts9_4] Multiple patches tested (8 commits)#1345

Closed
ciq-kernel-automation[bot] wants to merge 8 commits into
ciqlts9_4from
{ciq_kernel_automation}_ciqlts9_4
Closed

[ciqlts9_4] Multiple patches tested (8 commits)#1345
ciq-kernel-automation[bot] wants to merge 8 commits into
ciqlts9_4from
{ciq_kernel_automation}_ciqlts9_4

Conversation

@ciq-kernel-automation

Copy link
Copy Markdown

Summary

This PR has been automatically created after successful completion of all CI stages.

Commit Message(s)

efi: runtime: Fix potential overflow of soft-reserved region size

jira VULN-37032
cve CVE-2024-26843
commit-author Andrew Bresticker <abrestic@rivosinc.com>
commit de1034b38a346ef6be25fe8792f5d1e0684d5ff4
RDMA/srpt: Do not register event handler until srpt device is fully setup

jira VULN-37125
cve CVE-2024-26872
commit-author William Kucharski <william.kucharski@oracle.com>
commit c21a8870c98611e8f892511825c9607f1e2cd456
RDMA/srpt: Support specifying the srpt_service_guid parameter

jira VULN-36731
cve CVE-2024-26744
commit-author Bart Van Assche <bvanassche@acm.org>
commit fdfa083549de5d50ebf7f6811f33757781e838c0
quota: Fix potential NULL pointer dereference

jira VULN-37140
cve CVE-2024-26878
commit-author Wang Jianjian <wangjianjian3@huawei.com>
commit d0aa72604fbd80c8aabb46eda00535ed35570f1f
scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()

jira VULN-37953
cve CVE-2024-35930
commit-author Justin Tee <justin.tee@broadcom.com>
commit 2ae917d4bcab80ab304b774d492e2fcd6c52c06b
KVM: Always flush async #PF workqueue when vCPU is being destroyed

jira VULN-37505
cve CVE-2024-26976
commit-author Sean Christopherson <seanjc@google.com>
commit 3d75b8aa5c29058a512db29da7cbee8052724157
drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()'

jira VULN-37713
cve CVE-2024-27042
commit-author Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
commit cdb637d339572398821204a1142d8d615668f1e9
drm/amd/display: Implement bounds check for stream encoder creation in DCN301

jira VULN-42722
cve CVE-2024-26660
commit-author Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
commit 58fca355ad37dcb5f785d9095db5f748b79c5dc2

Test Results

✅ Build Stage

Architecture Build Time Total Time
x86_64 28m 55s 29m 46s
aarch64 15m 55s 16m 38s

✅ Boot Verification

✅ Kernel Selftests

Architecture Passed Failed Compared Against Status
x86_64 189 28 ciqlts9_4 ✅ No regressions
aarch64 145 30 ciqlts9_4 ✅ No regressions

✅ LTP Results

Architecture Passed Failed Compared Against Status
x86_64 1447 81 ciqlts9_4 ✅ No regressions
aarch64 1418 82 ciqlts9_4 ✅ No regressions

🤖 This PR was automatically generated by GitHub Actions
Run ID: 27532952488

CIQ Kernel Automation added 8 commits June 15, 2026 08:03
jira VULN-37032
cve CVE-2024-26843
commit-author Andrew Bresticker <abrestic@rivosinc.com>
commit de1034b

md_size will have been narrowed if we have >= 4GB worth of pages in a
soft-reserved region.

	Signed-off-by: Andrew Bresticker <abrestic@rivosinc.com>
	Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
(cherry picked from commit de1034b)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
…etup

jira VULN-37125
cve CVE-2024-26872
commit-author William Kucharski <william.kucharski@oracle.com>
commit c21a887

Upon rare occasions, KASAN reports a use-after-free Write
in srpt_refresh_port().

This seems to be because an event handler is registered before the
srpt device is fully setup and a race condition upon error may leave a
partially setup event handler in place.

Instead, only register the event handler after srpt device initialization
is complete.

Fixes: a42d985 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
	Signed-off-by: William Kucharski <william.kucharski@oracle.com>
Link: https://lore.kernel.org/r/20240202091549.991784-2-william.kucharski@oracle.com
	Reviewed-by: Bart Van Assche <bvanassche@acm.org>
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit c21a887)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
jira VULN-36731
cve CVE-2024-26744
commit-author Bart Van Assche <bvanassche@acm.org>
commit fdfa083

Make loading ib_srpt with this parameter set work. The current behavior is
that setting that parameter while loading the ib_srpt kernel module
triggers the following kernel crash:

BUG: kernel NULL pointer dereference, address: 0000000000000000
Call Trace:
 <TASK>
 parse_one+0x18c/0x1d0
 parse_args+0xe1/0x230
 load_module+0x8de/0xa60
 init_module_from_file+0x8b/0xd0
 idempotent_init_module+0x181/0x240
 __x64_sys_finit_module+0x5a/0xb0
 do_syscall_64+0x5f/0xe0
 entry_SYSCALL_64_after_hwframe+0x6e/0x76

	Cc: LiHonggang <honggangli@163.com>
	Reported-by: LiHonggang <honggangli@163.com>
Fixes: a42d985 ("ib_srpt: Initial SRP Target merge for v3.3-rc1")
	Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20240205004207.17031-1-bvanassche@acm.org
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit fdfa083)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
jira VULN-37140
cve CVE-2024-26878
commit-author Wang Jianjian <wangjianjian3@huawei.com>
commit d0aa726

Below race may cause NULL pointer dereference

P1					P2
dquot_free_inode			quota_off
					  drop_dquot_ref
					   remove_dquot_ref
					   dquots = i_dquot(inode)
  dquots = i_dquot(inode)
  srcu_read_lock
  dquots[cnt]) != NULL (1)
					     dquots[type] = NULL (2)
  spin_lock(&dquots[cnt]->dq_dqb_lock) (3)
   ....

If dquot_free_inode(or other routines) checks inode's quota pointers (1)
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
dereference will be triggered.

So let's fix it by using a temporary pointer to avoid this issue.

	Signed-off-by: Wang Jianjian <wangjianjian3@huawei.com>
	Signed-off-by: Jan Kara <jack@suse.cz>
Message-Id: <20240202081852.2514092-1-wangjianjian3@huawei.com>
(cherry picked from commit d0aa726)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
jira VULN-37953
cve CVE-2024-35930
commit-author Justin Tee <justin.tee@broadcom.com>
commit 2ae917d

The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an
unsuccessful status.  In such cases, the elsiocb is not issued, the
completion is not called, and thus the elsiocb resource is leaked.

Check return value after calling lpfc_sli4_resume_rpi() and conditionally
release the elsiocb resource.

	Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Link: https://lore.kernel.org/r/20240131185112.149731-3-justintee8345@gmail.com
	Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
	Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 2ae917d)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
jira VULN-37505
cve CVE-2024-26976
commit-author Sean Christopherson <seanjc@google.com>
commit 3d75b8a

Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its
completion queue, e.g. when a VM and all its vCPUs is being destroyed.
KVM must ensure that none of its workqueue callbacks is running when the
last reference to the KVM _module_ is put.  Gifting a reference to the
associated VM prevents the workqueue callback from dereferencing freed
vCPU/VM memory, but does not prevent the KVM module from being unloaded
before the callback completes.

Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from
async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will
result in deadlock.  async_pf_execute() can't return until kvm_put_kvm()
finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:

 WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]
 Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass
 CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
 Workqueue: events async_pf_execute [kvm]
 RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]
 Call Trace:
  <TASK>
  async_pf_execute+0x198/0x260 [kvm]
  process_one_work+0x145/0x2d0
  worker_thread+0x27e/0x3a0
  kthread+0xba/0xe0
  ret_from_fork+0x2d/0x50
  ret_from_fork_asm+0x11/0x20
  </TASK>
 ---[ end trace 0000000000000000 ]---
 INFO: task kworker/8:1:251 blocked for more than 120 seconds.
       Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
 task:kworker/8:1     state:D stack:0     pid:251   ppid:2      flags:0x00004000
 Workqueue: events async_pf_execute [kvm]
 Call Trace:
  <TASK>
  __schedule+0x33f/0xa40
  schedule+0x53/0xc0
  schedule_timeout+0x12a/0x140
  __wait_for_common+0x8d/0x1d0
  __flush_work.isra.0+0x19f/0x2c0
  kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]
  kvm_arch_destroy_vm+0x78/0x1b0 [kvm]
  kvm_put_kvm+0x1c1/0x320 [kvm]
  async_pf_execute+0x198/0x260 [kvm]
  process_one_work+0x145/0x2d0
  worker_thread+0x27e/0x3a0
  kthread+0xba/0xe0
  ret_from_fork+0x2d/0x50
  ret_from_fork_asm+0x11/0x20
  </TASK>

If kvm_clear_async_pf_completion_queue() actually flushes the workqueue,
then there's no need to gift async_pf_execute() a reference because all
invocations of async_pf_execute() will be forced to complete before the
vCPU and its VM are destroyed/freed.  And that in turn fixes the module
unloading bug as __fput() won't do module_put() on the last vCPU reference
until the vCPU has been freed, e.g. if closing the vCPU file also puts the
last reference to the KVM module.

Note that kvm_check_async_pf_completion() may also take the work item off
the completion queue and so also needs to flush the work queue, as the
work will not be seen by kvm_clear_async_pf_completion_queue().  Waiting
on the workqueue could theoretically delay a vCPU due to waiting for the
work to complete, but that's a very, very small chance, and likely a very
small delay.  kvm_arch_async_page_present_queued() unconditionally makes a
new request, i.e. will effectively delay entering the guest, so the
remaining work is really just:

        trace_kvm_async_pf_completed(addr, cr2_or_gpa);

        __kvm_vcpu_wake_up(vcpu);

        mmput(mm);

and mmput() can't drop the last reference to the page tables if the vCPU is
still alive, i.e. the vCPU won't get stuck tearing down page tables.

Add a helper to do the flushing, specifically to deal with "wakeup all"
work items, as they aren't actually work items, i.e. are never placed in a
workqueue.  Trying to flush a bogus workqueue entry rightly makes
__flush_work() complain (kudos to whoever added that sanity check).

Note, commit 5f6de5c ("KVM: Prevent module exit until all VMs are
freed") *tried* to fix the module refcounting issue by having VMs grab a
reference to the module, but that only made the bug slightly harder to hit
as it gave async_pf_execute() a bit more time to complete before the KVM
module could be unloaded.

Fixes: af585b9 ("KVM: Halt vcpu if page it tries to access is swapped out")
	Cc: stable@vger.kernel.org
	Cc: David Matlack <dmatlack@google.com>
	Reviewed-by: Xu Yilun <yilun.xu@intel.com>
	Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Link: https://lore.kernel.org/r/20240110011533.503302-2-seanjc@google.com
	Signed-off-by: Sean Christopherson <seanjc@google.com>
(cherry picked from commit 3d75b8a)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
…eg_base_init()'

jira VULN-37713
cve CVE-2024-27042
commit-author Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
commit cdb637d

The issue arises when the array 'adev->vcn.vcn_config' is accessed
before checking if the index 'adev->vcn.num_vcn_inst' is within the
bounds of the array.

The fix involves moving the bounds check before the array access. This
ensures that 'adev->vcn.num_vcn_inst' is within the bounds of the array
before it is used as an index.

Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1289 amdgpu_discovery_reg_base_init() error: testing array offset 'adev->vcn.num_vcn_inst' after use.

Fixes: a0ccc71 ("drm/amdgpu/discovery: validate VCN and SDMA instances")
	Cc: Christian König <christian.koenig@amd.com>
	Cc: Alex Deucher <alexander.deucher@amd.com>
	Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
	Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
	Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit cdb637d)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
…n DCN301

jira VULN-42722
cve CVE-2024-26660
commit-author Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
commit 58fca35

'stream_enc_regs' array is an array of dcn10_stream_enc_registers
structures. The array is initialized with four elements, corresponding
to the four calls to stream_enc_regs() in the array initializer. This
means that valid indices for this array are 0, 1, 2, and 3.

The error message 'stream_enc_regs' 4 <= 5 below, is indicating that
there is an attempt to access this array with an index of 5, which is
out of bounds. This could lead to undefined behavior

Here, eng_id is used as an index to access the stream_enc_regs array. If
eng_id is 5, this would result in an out-of-bounds access on the
stream_enc_regs array.

Thus fixing Buffer overflow error in dcn301_stream_encoder_create
reported by Smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5

Fixes: 3a83e4e ("drm/amd/display: Add dcn3.01 support to DC (v2)")
	Cc: Roman Li <Roman.Li@amd.com>
	Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
	Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
	Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
	Reviewed-by: Roman Li <roman.li@amd.com>
	Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 58fca35)
	Signed-off-by: CIQ Kernel Automation <ciq_kernel_automation@ciq.com>
@ciq-kernel-automation ciq-kernel-automation Bot added the created-by-kernelci Tag PRs that were automatically created when a user branch was pushed to the repo (kernelCI) label Jun 15, 2026
@github-actions

Copy link
Copy Markdown

🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/27544779983

@github-actions

Copy link
Copy Markdown

[NOTE]: CVE-2024-27042 is not published, it has been rejected

🔍 Upstream Linux Kernel Commit Check

  • ❌ PR commit a5eab4fed6f (drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()') references CVE-2024-27042 but
    upstream commit cdb637d33957 has no CVE assigned

This is an automated message from the kernel commit checker workflow.

@github-actions

Copy link
Copy Markdown

🔍 Interdiff Analysis

  • ⚠️ PR commit 9ce98a44e43 (quota: Fix potential NULL pointer dereference) → upstream d0aa72604fbd
    Differences found:
================================================================================
*    CONTEXT DIFFERENCES - surrounding code differences between the patches    *
================================================================================

--- b/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -1647,3 +1674,3 @@
 
-	if (!dquot_active(inode)) {
+	if (!inode_quota_active(inode)) {
 		if (reserve) {
@@ -1729,3 +1747,3 @@
 
-	if (!dquot_active(inode))
+	if (!inode_quota_active(inode))
 		return 0;
@@ -1765,6 +1783,6 @@
-int dquot_claim_space_nodirty(struct inode *inode, qsize_t number)
+void dquot_claim_space_nodirty(struct inode *inode, qsize_t number)
 {
 	struct dquot **dquots;
 	int cnt, index;
 
-	if (!dquot_active(inode)) {
+	if (!inode_quota_active(inode)) {
@@ -1812,4 +1830,4 @@
 	struct dquot **dquots;
 	int cnt, index;
 
-	if (!dquot_active(inode)) {
+	if (!inode_quota_active(inode)) {
@@ -1856,4 +1874,4 @@
 	struct dquot **dquots;
 	int reserve = flags & DQUOT_SPACE_RESERVE, index;
 
-	if (!dquot_active(inode)) {
+	if (!inode_quota_active(inode)) {
@@ -1911,4 +1929,4 @@
 	struct dquot * const *dquots;
 	int index;
 
-	if (!dquot_active(inode))
+	if (!inode_quota_active(inode))

This is an automated interdiff check for backported commits.

@github-actions

Copy link
Copy Markdown

Validation checks completed successfully View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/27544779983

@roxanan1996

Copy link
Copy Markdown
Contributor

This kernel has reached EOL. Closing this as we won't release a 9.4 kernel at this point.

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

Labels

created-by-kernelci Tag PRs that were automatically created when a user branch was pushed to the repo (kernelCI)

Development

Successfully merging this pull request may close these issues.

1 participant