Skip to content

Conversation

@github-actions
Copy link

Summary

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

Commit Message(s)

vsock: fix lock inversion in vsock_assign_transport()

jira VULN-80680
cve-bf CVE-2025-38461
commit-author Stefano Garzarella <sgarzare@redhat.com>
commit f7c877e7535260cc7a21484c994e8ce7e8cb6780

Syzbot reported a potential lock inversion deadlock between
vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.

The issue was introduced by commit 687aa0c5581b ("vsock: Fix
transport_* TOCTOU") which added vsock_register_mutex locking in
vsock_assign_transport() around the transport->release() call, that can
call vsock_linger(). vsock_assign_transport() can be called with sk_lock
held. vsock_linger() calls sk_wait_event() that temporarily releases and
re-acquires sk_lock. During this window, if another thread hold
vsock_register_mutex while trying to acquire sk_lock, a circular
dependency is created.

Fix this by releasing vsock_register_mutex before calling
transport->release() and vsock_deassign_transport(). This is safe
because we don't need to hold vsock_register_mutex while releasing the
old transport, and we ensure the new transport won't disappear by
obtaining a module reference first via try_module_get().

	Reported-by: syzbot+10e35716f8e4929681fa@syzkaller.appspotmail.com
	Tested-by: syzbot+10e35716f8e4929681fa@syzkaller.appspotmail.com
Fixes: 687aa0c5581b ("vsock: Fix transport_* TOCTOU")
	Cc: mhal@rbox.co
	Cc: stable@vger.kernel.org
	Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20251021121718.137668-1-sgarzare@redhat.com
	Signed-off-by: Paolo Abeni <pabeni@redhat.com>

(cherry picked from commit f7c877e7535260cc7a21484c994e8ce7e8cb6780)
	Signed-off-by: Roxana Nicolescu <rnicolescu@ciq.com>

Test Results

✅ Build Stage

✅ Boot Verification

✅ Kernel Selftests

⚠️ Test Comparison

  • Status: Skipped
  • Reason: No baseline test results available from bmastbergen_ciqlts9_2/many-vulns-2025-11-04
  • Note: Manual review recommended to ensure no regressions

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

shreeya-patel98 and others added 5 commits November 12, 2025 15:06
Script to generate detailed PR descriptions with kselftest results.

Signed-off-by: Shreeya Patel <spatel@ciq.com>
Implements a 5-stage GitHub Actions pipeline for automated kernel testing and PR creation.
Uses kernel-container-build automated-testing-v1 branch for build/test tooling.

Stage 1: Build (15-30 min)
- Checkout kernel source + kernel-container-build repo (automated-testing-v1)
- Build kernel in CIQ builder container with kABI checking
- Convert built container to QCOW2 VM image
- Upload: kernel-build.log, QCOW2 image

Stage 2: Boot Verification (2-5 min)
- Download QCOW2 image
- Boot kernel in QEMU (KVM or TCG) and validate login prompt appears
- Upload: boot logs

Stage 3: Kernel Selftests (40-60 min)
- Download QCOW2 image
- Execute comprehensive kselftests in QEMU with dual serial consoles
- Upload: kselftest TAP logs, dmesg output

Stage 4: Compare Results (1-2 min)
Purpose: Detect test regressions by comparing against base branch

Steps:
1. Checkout with full history (fetch-depth: 0) for git merge-base ops
2. Download current kselftest logs
3. Smart base branch detection:
   - For PRs: Uses PR's target branch
   - For pushes: Sorts branches by commit date, checks 30 most recent,
     finds closest common ancestor via git merge-base
   - For force-pushes: Doesn't do the detection again, instead uses the
     same base branch as detected during the first PR creation and also
     compares the result against that base branch only
   - Outputs: base_branch (reused by PR stage)
4. Download baseline logs from base branch (searches last 5 successful runs)
5. Compare results:
   - Counts passing/failing tests (before/after)
   - Fails if >±3 tests changed
   - Outputs: comparison_status, comparison_message

Stage 5: Create Pull Request (1-2 min)
Purpose: Auto-create/update PR after all tests pass

Prerequisites: Only runs if build + boot + kselftest passed, no regressions detected

Steps:
1. Check all stages passed and comparison_status != failed
2. Checkout (shallow: fetch-depth: 50) for commit messages
3. Download all artifacts (build/boot/test logs)
4. Extract statistics (pass/fail counts, build times)
5. Get commit info:
   - Single commit: Use commit message
   - Multiple commits: Create summary
6. Create/Update PR:
   - Reuses base_branch from compare-results (no duplication!)
   - Generate PR body with test results via create-pr-body.sh
   - Creates new PR or updates existing one in case of force pushes

Note :-
To skip this github action workflow, add [ci skip] or [skip ci]
into the head commit when pushing the patches.

Signed-off-by: Shreeya Patel <spatel@ciq.com>
- Created .container_build_image with lts-9.2-kernel-builder
- Updated workflow to remove -c option from build_kernel.sh call
- Build script will now automatically use the image specified in .container_build_image

Signed-off-by: Shreeya Patel <spatel@ciq.com>
jira VULN-80680
cve-bf CVE-2025-38461
commit-author Stefano Garzarella <sgarzare@redhat.com>
commit a24009b

Transport's release() and destruct() are called when de-assigning the
vsock transport. These callbacks can touch some socket state like
sock flags, sk_state, and peer_shutdown.

Since we are reassigning the socket to a new transport during
vsock_connect(), let's reset these fields to have a clean state with
the new transport.

Fixes: c0cfa2d ("vsock: add multi-transports support")
	Cc: stable@vger.kernel.org
	Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
	Reviewed-by: Luigi Leonardi <leonardi@redhat.com>
	Signed-off-by: Paolo Abeni <pabeni@redhat.com>

(cherry picked from commit a24009b)
	Signed-off-by: Roxana Nicolescu <rnicolescu@ciq.com>
jira VULN-80680
cve-bf CVE-2025-38461
commit-author Stefano Garzarella <sgarzare@redhat.com>
commit f7c877e

Syzbot reported a potential lock inversion deadlock between
vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.

The issue was introduced by commit 687aa0c ("vsock: Fix
transport_* TOCTOU") which added vsock_register_mutex locking in
vsock_assign_transport() around the transport->release() call, that can
call vsock_linger(). vsock_assign_transport() can be called with sk_lock
held. vsock_linger() calls sk_wait_event() that temporarily releases and
re-acquires sk_lock. During this window, if another thread hold
vsock_register_mutex while trying to acquire sk_lock, a circular
dependency is created.

Fix this by releasing vsock_register_mutex before calling
transport->release() and vsock_deassign_transport(). This is safe
because we don't need to hold vsock_register_mutex while releasing the
old transport, and we ensure the new transport won't disappear by
obtaining a module reference first via try_module_get().

	Reported-by: syzbot+10e35716f8e4929681fa@syzkaller.appspotmail.com
	Tested-by: syzbot+10e35716f8e4929681fa@syzkaller.appspotmail.com
Fixes: 687aa0c ("vsock: Fix transport_* TOCTOU")
	Cc: mhal@rbox.co
	Cc: stable@vger.kernel.org
	Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20251021121718.137668-1-sgarzare@redhat.com
	Signed-off-by: Paolo Abeni <pabeni@redhat.com>

(cherry picked from commit f7c877e)
	Signed-off-by: Roxana Nicolescu <rnicolescu@ciq.com>
@roxanan1996 roxanan1996 added the invalid This doesn't seem right label Nov 12, 2025
@bmastbergen bmastbergen force-pushed the bmastbergen_ciqlts9_2/many-vulns-2025-11-04 branch from e56b0d0 to 047c191 Compare November 12, 2025 20:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

invalid This doesn't seem right

Development

Successfully merging this pull request may close these issues.

3 participants