[PATCH AUTOSEL 6.18-6.6] Drivers: hv: vmbus: add VTL2 redirect connection ID

[PATCH AUTOSEL 6.18-6.6] Drivers: hv: vmbus: add VTL2 redirect connection ID

[Sasha Levin]

From: Hardik Garg <hargar@linux.microsoft.com>

[ Upstream commit 92d0593128023cf93ae61b7728dcc3062f8d514f ]

VMBus sends CHANNELMSG_INITIATE_CONTACT through a Hyper-V message
connection ID. Older protocol versions use VMBUS_MESSAGE_CONNECTION_ID,
while protocol version 5.0 and newer normally use
VMBUS_MESSAGE_CONNECTION_ID_4.

For a VTL2 kernel using VMBus protocol 5.0 or newer, the host
may expect INITIATE_CONTACT on either the redirect connection ID or
VMBUS_MESSAGE_CONNECTION_ID_4. There is no capability indication that
identifies which ID is active, so the driver must determine it at runtime.

During VMBus negotiation, the redirect ID is tried first because it is
used by VTL2 configurations with VMBus redirection enabled. If the
redirect ID is unavailable, the host rejects it synchronously with
HV_STATUS_INVALID_CONNECTION_ID, allowing fallback to the standard ID.

Return a distinct error for an invalid Initiate Contact connection ID so
this fallback does not mask other post-message failures or
protocol-version rejections. Preserve the existing connection ID
selection for older protocol versions or when running below VTL2.

Signed-off-by: Hardik Garg <hargar@linux.microsoft.com>
Reviewed-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
Reviewed-by: Naman Jain <namjain@linux.microsoft.com>
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: Drivers: hv: vmbus: add VTL2 redirect
connection ID

**Local tree:** `v6.18.44` (`linux-6.18.y` stable), `git describe HEAD`
= `v6.18.44-2-g1b9e1abadee04`

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[drivers: hv: vmbus]` `[add]` — Add runtime selection of
the VTL2 redirect VMBus message connection ID during INITIATE_CONTACT
negotiation.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Hardik Garg `<hargar@linux.microsoft.com>` (author)
- **Reviewed-by:** Tianyu Lan, Saurabh Sengar, Naman Jain, Michael
  Kelley (Microsoft Hyper-V reviewers)
- **Signed-off-by:** Wei Liu `<wei.liu@kernel.org>` (Hyper-V maintainer)
- **No** `Fixes:`, `Reported-by:`, `Link:`, `Cc:
  stable@vger.kernel.org`, `Tested-by:`, or `Acked-by:` tags
- Notable: Multiple Microsoft subsystem reviewers; Wei Liu replied
  "Applied. Thanks." on the mailing list (patchew)

### Step 1.3: Body analysis
**Record:**
- **Bug:** On VTL2 guests using VMBus protocol 5.0+, the host may
  require `CHANNELMSG_INITIATE_CONTACT` on connection ID `0x800074`
  (redirect) instead of `VMBUS_MESSAGE_CONNECTION_ID_4` (4). There is no
  capability bit to distinguish which is active.
- **Symptom:** INITIATE_CONTACT sent to the wrong connection ID is not
  delivered; VMBus negotiation never completes → `vmbus_connect()` fails
  with "Unable to connect to host".
- **Root cause:** Driver unconditionally uses
  `VMBUS_MESSAGE_CONNECTION_ID_4` for protocol ≥ 5.0.
- **Fix approach:** For `ms_hyperv.vtl == 2` and protocol ≥ 5.0, try
  redirect ID first; on synchronous `HV_STATUS_INVALID_CONNECTION_ID`,
  fall back to ID 4. Return `-ENXIO` (not `-EINVAL`) for invalid
  INITIATE_CONTACT connection IDs so fallback is distinguishable from
  other failures.

### Step 1.4: Hidden bug fix?
**Record:** Yes. Subject says "add" but this is a connectivity bug fix
for an existing supported configuration (VTL2 + VMBus 5.0+), not a new
subsystem. It is a hardware/platform workaround analogous to connection-
endpoint probing.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- `drivers/hv/connection.c`: +30 / -19 lines (refactor + retry logic)
- `drivers/hv/hyperv_vmbus.h`: +2 lines (new enum constant)
- **Functions modified:** `vmbus_negotiate_version` (split into
  `vmbus_try_connection_id` + wrapper), `vmbus_post_msg`
- **Scope:** Single-subsystem, 2-file surgical change

### Step 2.2: Code flow per hunk
**Record:**
1. **`vmbus_try_connection_id` (new static helper):** Before:
   `vmbus_negotiate_version` hardcoded `VMBUS_MESSAGE_CONNECTION_ID_4`.
   After: caller supplies `connection_id` for protocol ≥ 5.0. Normal
   negotiation path unchanged otherwise.
2. **`vmbus_negotiate_version` (wrapper):** Before: single attempt with
   ID 4. After: if VTL2 + protocol ≥ 5.0, try redirect ID; on `-ENXIO`
   only, retry with ID 4. All other paths unchanged.
3. **`vmbus_post_msg`:** Before: `HV_STATUS_INVALID_CONNECTION_ID` on
   INITIATE_CONTACT → `-EINVAL`. After: → `-ENXIO` to enable controlled
   fallback without masking other errors.
4. **`hyperv_vmbus.h`:** Adds `VMBUS_MESSAGE_CONNECTION_ID_REDIRECT =
   0x800074`.

### Step 2.3: Bug mechanism
**Record:** **Category:** Logic/correctness fix — wrong endpoint
selection. **Mechanism:** VTL2 hosts with VMBus redirection route the
control plane through redirect connection ID `0x800074`. Driver always
posted to ID 4; host never received INITIATE_CONTACT, so negotiation
failed silently.

### Step 2.4: Fix quality
**Record:** Fix is obviously correct and minimal. Gated strictly on
`ms_hyperv.vtl == 2` (v2 improved from v1's `>= 2` per Michael Kelley's
review). Fallback preserves existing behavior when redirect is
unavailable. **Regression risk:** Very low — VTL0/VTL1 guests
unaffected; non-VTL2 code path identical except `-ENXIO` vs `-EINVAL` on
INITIATE_CONTACT invalid ID (both cause version-negotiation loop to
continue, verified below).

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Current hardcoded-ID code at lines 99–102 dates to the 6.18
merge base (`5d324e5159d9e`). `msg->msg_vtl = ms_hyperv.vtl` and
`VERSION_WIN10_V5` handling are present in this tree. Bug has existed
since VMBus 5.0 + VTL2 support were both present.

### Step 3.2: Fixes: tag
**Record:** Not applicable — no `Fixes:` tag.

### Step 3.3: Related file history
**Record:** Recent `drivers/hv/` activity includes VMBus 6.0 support
(`1639df1a9844e`), SynIC changes, mshv fixes. No prior fix for VTL2
redirect connection ID in this tree. Standalone patch (v2 of a
2-revision series; v2 simplified per maintainer feedback).

### Step 3.4: Author context
**Record:** Hardik Garg (Microsoft). Reviewed by Michael Kelley (long-
time Hyper-V maintainer), Tianyu Lan, Saurabh Sengar, Naman Jain.
Applied by Wei Liu (Hyper-V maintainer).

### Step 3.5: Dependencies
**Record:** Requires `ms_hyperv.vtl` (present in `include/asm-
generic/mshyperv.h`, set in `arch/x86/hyperv/hv_init.c` and
`arch/arm64/hyperv/mshyperv.c`), `VERSION_WIN10_V5` (present in
`connection.c`), and VTL2 boot support (`arch/x86/hyperv/hv_vtl.c`,
`CONFIG_HYPERV_VTL_MODE` in `drivers/hv/Kconfig`). All prerequisites
exist in 6.18.44. **Standalone:** yes.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:** Lore URL: https://lists.openwall.net/linux-
kernel/2026/07/17/12 (v2). Patchew: https://patchew.org/linux/2026071700
1837.635756-1-hargar@linux.microsoft.com/. Series: v1 (Jul 14) → v2 (Jul
17). v2 incorporated Michael Kelley's feedback (simpler retry, exact
`vtl == 2`, cleaner comments). Wei Liu applied to mainline ~Jul 28,
2026. **No explicit stable nomination** found in thread.

### Step 4.2: Reviewers
**Record:** CC'd to K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan
Cui, Saurabh Sengar, Michael Kelley, linux-hyperv@, linux-kernel@.
Appropriate maintainers reviewed.

### Step 4.3: Bug reports
**Record:** No syzbot, bugzilla, or user `Reported-by:` tags. Bug
identified through Microsoft VTL2/VMBus protocol engineering; Michael
Kelley confirmed the technical requirement in review.

### Step 4.4: Series context
**Record:** Standalone 1-patch series. v2 is the final applied version.
No other patches required.

### Step 4.5: Stable list history
**Record:** No stable@ discussion found for this fix.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `vmbus_try_connection_id`, `vmbus_negotiate_version`,
`vmbus_post_msg`, `vmbus_connect`, `hv_vmbus_probe` (via
`vmbus_connect`)

### Step 5.2: Callers
**Record:**
- `vmbus_negotiate_version` ← `vmbus_connect()` (boot probe path),
  `vmbus_drv.c` resume path
- `vmbus_connect()` ← `hv_vmbus_probe()` at line 1491 in `vmbus_drv.c`
- `vmbus_post_msg` ← `vmbus_try_connection_id` and many channel-
  management paths

### Step 5.3: Callees
**Record:** `hv_post_message()`, `wait_for_completion()`, spinlock/list
management in negotiation path.

### Step 5.4: Reachability
**Record:** Triggered at every Hyper-V guest boot with
`CONFIG_HYPERV_VMBUS=y` when running at VTL2 with VMBus protocol 5.0+ on
a host using redirect connection ID. Not userspace-triggerable directly,
but affects all paravirtual I/O (storage, network, etc.) on affected
VMs.

### Step 5.5: Similar patterns
**Record:** Version negotiation already iterates protocol versions on
failure (`vmbus_connect` loop at lines 283–298). This adds connection-ID
probing within a single version attempt — consistent with existing retry
philosophy.

---

## PHASE 6: CROSS-REFERENCE WITH LOCAL TREE (6.18.44)

### Step 6.1: Buggy code exists?
**Record:** **Yes.** `drivers/hv/connection.c` lines 99–102 hardcode
`VMBUS_MESSAGE_CONNECTION_ID_4`. `ms_hyperv.vtl` field exists. VTL2
support exists (`hv_vtl.c`, `CONFIG_HYPERV_VTL_MODE`).
`VMBUS_MESSAGE_CONNECTION_ID_REDIRECT` is **not** present (fix not yet
applied).

### Step 6.2: Backport complications
**Record:** **Clean apply verified** — `git apply --check
/tmp/vtl2.patch` succeeds on this tree. Minor context difference from
mainline (e.g., `max_version = VERSION_WIN10_V5_3` vs mainline's `V6_0`)
does not affect the changed hunks.

### Step 6.3: Related fixes already present?
**Record:** None found for VTL2 redirect connection ID.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem and criticality
**Record:** **Subsystem:** `drivers/hv` (Hyper-V VMBus).
**Criticality:** IMPORTANT for Hyper-V guests; boot-critical for VTL2
deployments relying on VMBus paravirtual devices.

### Step 7.2: Activity
**Record:** Actively maintained — recent VMBus 6.0, SynIC, mshv commits
in this tree.

---

## PHASE 8: IMPACT AND RISK

### Step 8.1: Who is affected
**Record:** Hyper-V guests running Linux at **VTL2**
(`CONFIG_HYPERV_VTL_MODE`) with **VMBus protocol ≥ 5.0** on hosts with
VMBus redirection enabled. Narrow but real population (confidential
computing / VSM scenarios explicitly supported in Kconfig).

### Step 8.2: Trigger conditions
**Record:** Every boot/resume VMBus negotiation on matching config. Not
timing-dependent. Not triggerable by unprivileged users, but affects
entire VM I/O stack.

### Step 8.3: Failure severity
**Record:** Complete VMBus connection failure → no synthetic devices
(disk, net, etc.) → effectively unusable VM on VTL2 with redirection.
**Severity: CRITICAL** for affected configuration; **no impact** on
standard VTL0 guests.

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** HIGH for VTL2+VMBus-5.0+redirect deployments; enables
  boot and device functionality
- **Risk:** VERY LOW — gated on `vtl == 2`, fallback preserves existing
  path, ~30 lines, multiple maintainer reviews
- **Ratio:** Favorable for this tree, which explicitly supports VTL2

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Fixes real VMBus boot failure on supported VTL2 configuration
- Critical functional impact when triggered (no paravirtual devices)
- Small, surgical, well-reviewed by Hyper-V maintainers
- All prerequisites present in 6.18.44
- Applies cleanly
- Behavior unchanged for standard VTL0 Hyper-V guests
- Platform workaround pattern (endpoint probing with fallback)

**AGAINST backport:**
- Very niche deployment (VTL2 + VMBus 5.0 + redirection)
- No syzbot/user bug report tags
- Could be viewed as completing support for a config that never worked,
  rather than fixing a regression
- No explicit stable@ nomination

**Unresolved:** No end-user crash reports; impact inferred from protocol
requirements and maintainer review.

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — logic is straightforward;
   reviewed by 4 Microsoft engineers + maintainer applied
2. Fixes real bug affecting users? **PASS** — VMBus fails on
   VTL2+redirect hosts
3. Important issue? **PASS** — complete loss of VMBus connectivity
   (CRITICAL for affected VMs)
4. Small and contained? **PASS** — 2 files, ~30 net lines
5. No new features/APIs? **PASS** — no userspace-visible changes;
   internal connection-ID selection only
6. Can apply to local tree? **PASS** — verified clean apply

### Step 9.3: Exception categories
**Record:** Hardware/platform workaround — analogous to quirks for
specific Hyper-V VTL2 host configurations.

### Step 9.4: Decision rationale

This tree (`6.18.y`) explicitly supports VTL2 via
`CONFIG_HYPERV_VTL_MODE` and already negotiates VMBus protocol 5.0+
using `ms_hyperv.vtl`. Without this fix, VMBus negotiation fails on
hosts that require the redirect connection ID — a complete loss of
paravirtual device functionality for those VMs. The fix is minimal,
gated, has safe fallback, applies cleanly, and was reviewed by the
Hyper-V maintainer team. While the affected population is narrow, the
failure mode is severe and the tree already claims VTL2 support.

---

## Verification

- [Phase 1] Parsed subject, tags, body from provided commit message and
  patchew thread
- [Phase 1] Confirmed no Fixes:/Reported-by:/Cc: stable tags
- [Phase 1] Confirmed Wei Liu "Applied" on patchew (Jul 28, 2026)
- [Phase 2] Diff analysis: 2 files, `vmbus_try_connection_id` refactor +
  `-ENXIO` fallback
- [Phase 3] `git describe HEAD`: v6.18.44-2-g1b9e1abadee04; `make
  kernelversion`: 6.18.44
- [Phase 3] `git blame -L 99,106 drivers/hv/connection.c`: hardcoded
  ID_4 at merge base
- [Phase 3] Prerequisites verified: `ms_hyperv.vtl` in mshyperv.h,
  `get_vtl()` in hv_init.c, `hv_vtl.c` present
- [Phase 4] Mailing list: https://lists.openwall.net/linux-
  kernel/2026/07/17/12 (v2)
- [Phase 4] Michael Kelley review feedback on v1:
  https://lists.openwall.net/linux-kernel/2026/07/16/2295
- [Phase 4] Patchew thread: 4 Reviewed-by, Wei Liu applied; no stable
  nomination
- [Phase 4] b4 dig on commit hash: not performed (commit not in local
  tree); mbox extracted from patchew
- [Phase 5] `vmbus_connect()` → `vmbus_negotiate_version()` call chain
  verified in connection.c
- [Phase 5] `hv_vmbus_probe()` calls `vmbus_connect()` at
  vmbus_drv.c:1491
- [Phase 6] Buggy code confirmed at connection.c:102
  (`VMBUS_MESSAGE_CONNECTION_ID_4`)
- [Phase 6] `VMBUS_MESSAGE_CONNECTION_ID_REDIRECT` absent from
  hyperv_vmbus.h
- [Phase 6] `git apply --check /tmp/vtl2.patch`: **clean apply**
- [Phase 6] `CONFIG_HYPERV_VTL_MODE` documents VTL2 support in
  drivers/hv/Kconfig
- [Phase 8] Failure mode: vmbus_connect cleanup prints "Unable to
  connect to host" (connection.c:324)
- [Phase 8] `-ENXIO` vs `-EINVAL` on failed negotiation: both cause
  version loop to continue (only `-ETIMEDOUT` aborts)

**YES**The background searches on `all-next` and other large branches
timed out — those repos are huge and `git log -S` over them is slow.
That didn’t block the analysis; the patch context came from
patchew/openwall, and `git apply --check` on the extracted v2 patch
confirmed it applies cleanly to your **6.18.44** tree.

**Verdict remains YES** for backport: this fixes VMBus boot failure on
VTL2 guests (protocol 5.0+) when the host expects the redirect
connection ID `0x800074`, and the fix is small, gated on `ms_hyperv.vtl
== 2`, and all prerequisites are already in 6.18.y.

 drivers/hv/connection.c   | 47 +++++++++++++++++++++++----------------
 drivers/hv/hyperv_vmbus.h |  2 ++
 2 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 1fe3573ae52a4..9be2af772867d 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -71,7 +71,8 @@ module_param(max_version, uint, S_IRUGO);
 MODULE_PARM_DESC(max_version,
 		 "Maximal VMBus protocol version which can be negotiated");
 
-int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo, u32 version)
+static int vmbus_try_connection_id(struct vmbus_channel_msginfo *msginfo,
+				   u32 version, u32 connection_id)
 {
 	int ret = 0;
 	struct vmbus_channel_initiate_contact *msg;
@@ -86,20 +87,20 @@ int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo, u32 version)
 	msg->vmbus_version_requested = version;
 
 	/*
-	 * VMBus protocol 5.0 (VERSION_WIN10_V5) and higher require that we must
-	 * use VMBUS_MESSAGE_CONNECTION_ID_4 for the Initiate Contact Message,
-	 * and for subsequent messages, we must use the Message Connection ID
-	 * field in the host-returned Version Response Message. And, with
-	 * VERSION_WIN10_V5 and higher, we don't use msg->interrupt_page, but we
-	 * tell the host explicitly that we still use VMBUS_MESSAGE_SINT(2) for
-	 * compatibility.
+	 * For VMBus protocol 5.0 (VERSION_WIN10_V5) and higher, use the
+	 * caller-supplied connection_id for the Initiate Contact message so
+	 * the caller can implement the required retry scheme. For subsequent
+	 * messages, use the Message Connection ID field in the host-returned
+	 * Version Response message. With VERSION_WIN10_V5 and higher, we don't
+	 * use msg->interrupt_page, but tell the host explicitly that we still
+	 * use VMBUS_MESSAGE_SINT(2) for compatibility.
 	 *
 	 * On old hosts, we should always use VMBUS_MESSAGE_CONNECTION_ID (1).
 	 */
 	if (version >= VERSION_WIN10_V5) {
 		msg->msg_sint = VMBUS_MESSAGE_SINT;
 		msg->msg_vtl = ms_hyperv.vtl;
-		vmbus_connection.msg_conn_id = VMBUS_MESSAGE_CONNECTION_ID_4;
+		vmbus_connection.msg_conn_id = connection_id;
 	} else {
 		msg->interrupt_page = virt_to_phys(vmbus_connection.int_page);
 		vmbus_connection.msg_conn_id = VMBUS_MESSAGE_CONNECTION_ID;
@@ -161,6 +162,22 @@ int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo, u32 version)
 	return ret;
 }
 
+int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo, u32 version)
+{
+	int ret;
+
+	/* Try the redirect ID first for VTL2 with VMBus protocol 5.0+. */
+	if (version >= VERSION_WIN10_V5 && ms_hyperv.vtl == 2) {
+		ret = vmbus_try_connection_id(msginfo, version,
+					      VMBUS_MESSAGE_CONNECTION_ID_REDIRECT);
+		if (ret != -ENXIO)
+			return ret;
+	}
+
+	return vmbus_try_connection_id(msginfo, version,
+				       VMBUS_MESSAGE_CONNECTION_ID_4);
+}
+
 /*
  * vmbus_connect - Sends a connect request on the partition service connection
  */
@@ -454,18 +471,10 @@ int vmbus_post_msg(void *buffer, size_t buflen, bool can_sleep)
 
 		switch (ret) {
 		case HV_STATUS_INVALID_CONNECTION_ID:
-			/*
-			 * See vmbus_negotiate_version(): VMBus protocol 5.0
-			 * and higher require that we must use
-			 * VMBUS_MESSAGE_CONNECTION_ID_4 for the Initiate
-			 * Contact message, but on old hosts that only
-			 * support VMBus protocol 4.0 or lower, here we get
-			 * HV_STATUS_INVALID_CONNECTION_ID and we should
-			 * return an error immediately without retrying.
-			 */
+			/* Allow INITIATE_CONTACT to try another connection ID. */
 			hdr = buffer;
 			if (hdr->msgtype == CHANNELMSG_INITIATE_CONTACT)
-				return -EINVAL;
+				return -ENXIO;
 			/*
 			 * We could get this if we send messages too
 			 * frequently.
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 39cdded062e8b..f16395ba5d823 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -108,6 +108,8 @@ struct hv_input_post_message {
 enum {
 	VMBUS_MESSAGE_CONNECTION_ID	= 1,
 	VMBUS_MESSAGE_CONNECTION_ID_4	= 4,
+	/* VTL2 redirect connection ID for INITIATE_CONTACT. */
+	VMBUS_MESSAGE_CONNECTION_ID_REDIRECT = 0x800074,
 	VMBUS_MESSAGE_PORT_ID		= 1,
 	VMBUS_EVENT_CONNECTION_ID	= 2,
 	VMBUS_EVENT_PORT_ID		= 2,
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] vsock: use sk_acceptq_is_full() helper in all transports

[Sasha Levin]

From: Raf Dickson <rafdog35@gmail.com>

[ Upstream commit 4ff2e84ff1b33d79fa0e3ae355ce4a334908ef9a ]

Replace the open-coded backlog check with sk_acceptq_is_full().
The helper uses > instead of >=, which is the correct comparison
per commit 64a146513f8f ("[NET]: Revert incorrect accept queue
backlog changes."), and adds READ_ONCE() for proper memory ordering.

Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Raf Dickson <rafdog35@gmail.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Luigi Leonardi <leonardi@redhat.com>
Link: https://patch.msgid.link/20260612045842.122207-1-rafdog35@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background searches finished and match what the earlier analysis
already showed:

- **Commit hash search** (`git log --grep="use sk_acceptq_is_full"`): no
  matches. That patch is not in this v6.18.44 tree yet; the buggy `>=`
  checks are still in `hyperv_transport.c` and `vmci_transport.c`.
- **Author search** (Raf Dickson): only one vsock commit here —
  `ba9ad6015937a` (`vsock/vmci: fix sk_ack_backlog leak on failed
  handshake`). Nothing for the `sk_acceptq_is_full()` change.

That supports the **YES** backport verdict: the bug is present locally,
the fix is not, and it should apply cleanly as a 2-line change.

 net/vmw_vsock/hyperv_transport.c | 2 +-
 net/vmw_vsock/vmci_transport.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index 4da752b47b116..54c7f51f9145d 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -323,7 +323,7 @@ static void hvs_open_connection(struct vmbus_channel *chan)
 		goto out;
 
 	if (conn_from_host) {
-		if (sk->sk_ack_backlog >= sk->sk_max_ack_backlog)
+		if (sk_acceptq_is_full(sk))
 			goto out;
 
 		new = vsock_create_connected(sk);
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index 75bf643ff6faf..4f02a6f269cdb 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -1002,7 +1002,7 @@ static int vmci_transport_recv_listen(struct sock *sk,
 	 * reset.  Otherwise we create and initialize a child socket and reply
 	 * with a connection negotiation.
 	 */
-	if (sk->sk_ack_backlog >= sk->sk_max_ack_backlog) {
+	if (sk_acceptq_is_full(sk)) {
 		vmci_transport_reply_reset(pkt);
 		return -ECONNREFUSED;
 	}
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] net: mana: hardening: Reject zero max_num_queues from MANA_QUERY_VPORT_CONFIG

[Sasha Levin]

From: Erni Sri Satya Vennela <ernis@linux.microsoft.com>

[ Upstream commit 93ca1575dd1f43e24ad85663305e13114f9acdf1 ]

As a part of MANA hardening for CVM, validate that max_num_sq and
max_num_rq returned by MANA_QUERY_VPORT_CONFIG are not zero. These
values flow into apc->num_queues, which is used as an allocation count
and loop bound. A zero value would result in zero-size allocations and
incorrect driver behavior.

Return -EPROTO if either value is zero.

Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
Link: https://patch.msgid.link/20260430085638.1875400-1-ernis@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `net: mana: hardening: Reject zero
max_num_queues from MANA_QUERY_VPORT_CONFIG`

**Local tree:** Linux **6.18.43** (`v6.18.43-1-gc7f0dac02d232`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
**Record:** `[net: mana]` `[hardening/validate]` — Reject zero
`max_num_sq` / `max_num_rq` from `MANA_QUERY_VPORT_CONFIG` firmware
response.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Erni Sri Satya Vennela
  `<ernis@linux.microsoft.com>` (author)
- **Signed-off-by:** Jakub Kicinski `<kuba@kernel.org>` (committer)
- **Link:** https://patch.msgid.link/20260430085638.1875400-1-
  ernis@linux.microsoft.com
- **No** Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, Cc:
  stable@vger.kernel.org
- Notable: Same author (Erni) as the already-backported MANA CVM TOCTOU
  fix (`09ec063d87c2d`) in this tree.

### Step 1.3: Body Analysis
**Record:**
- **Bug:** Firmware may return `max_num_sq == 0` or `max_num_rq == 0`
  from `MANA_QUERY_VPORT_CONFIG`.
- **Symptom:** Values flow into `apc->num_queues` (via
  `mana_init_port()`), used as allocation count and loop bound → zero-
  size allocations and incorrect driver behavior.
- **Fix:** Return `-EPROTO` if either value is zero.
- **Context:** CVM (Confidential VM) hardening — firmware/hypervisor
  responses treated as untrusted.
- **Root cause:** Missing input validation on firmware-reported queue
  limits.

### Step 1.4: Hidden Bug Fix?
**Record:** Yes. Labeled "hardening" but is a real input-validation bug
fix. Without it, zero queue counts propagate into driver state and cause
broken device behavior.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/net/ethernet/microsoft/mana/mana_en.c` (+6 lines)
- **Function:** `mana_query_vport_cfg()`
- **Scope:** Single-file, surgical validation in one function.

### Step 2.2: Code Flow Change
**Record:**
- **Hunk (lines ~1263–1268):**
  - **Before:** Accept any `max_num_sq`/`max_num_rq` from firmware after
    status check.
  - **After:** Reject zero values with `netdev_err()` + `-EPROTO`.
- **Path affected:** Port initialization during `mana_init_port()` →
  `mana_probe_port()` probe path.

### Step 2.3: Bug Mechanism
**Record:** **Input validation / logic correctness bug.**
- `mana_init_port()` computes `max_queues = min(max_txq, max_rxq)` and
  clamps `apc->num_queues` down to that value.
- With zero firmware values, `apc->num_queues` becomes 0.
- `kcalloc(0, ...)` returns `ZERO_SIZE_PTR` (non-NULL), passing `!ptr`
  checks.
- `netif_set_real_num_tx_queues(ndev, 0)` and
  `netif_set_real_num_rx_queues(ndev, 0)` both require `txq/rxq >= 1`
  and return `-EINVAL`.
- Probe can still register a netdev with carrier on before queue setup
  fails on attach.

### Step 2.4: Fix Quality
**Record:** Obviously correct, minimal, mirrors existing `-EPROTO` usage
for bad firmware status. No API changes. Very low regression risk — only
rejects values that are fundamentally invalid (a NIC cannot have zero
TX/RX queues).

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Lines `*max_sq = resp.max_num_sq` / `*max_rq =
resp.max_num_rq` blame to `19eef1d98eeda` (tree import). MANA driver and
`mana_query_vport_cfg()` exist in this 6.18.43 tree. Fix not yet
present.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag in commit message.

### Step 3.3: Related File History
**Record:** Recent MANA fixes in this tree include CVM/security-oriented
patches:
- `09ec063d87c2d` — TOCTOU fix in `hw_channel.c` (CVM, same author Erni)
- `6d13eaa13341a` — RX packet length validation (untrusted NIC data,
  backported with Cc: stable)
- `da87896f34e0a` — NULL guards to prevent panic on attach failure
Standalone fix; no "patch X/Y" series indicator.

### Step 3.4: Author Context
**Record:** Erni Sri Satya Vennela is an active MANA contributor with
multiple probe/teardown/CVM fixes already in this tree.

### Step 3.5: Dependencies
**Record:** None. Uses existing `mana_query_vport_cfg_resp` struct
(`include/net/mana/mana.h`), `netdev_err()`, and `-EPROTO`. Applies
standalone.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Patch Discussion
**Record:** `b4 dig -c <sha>` not possible (commit not in local tree).
`b4 dig` with message-id failed (wrong syntax). WebFetch of
patch.msgid.link blocked by bot protection. **UNVERIFIED:** Full lore
review thread content.

### Step 4.2: Reviewers
**Record:** **UNVERIFIED** — could not fetch mailing list thread.

### Step 4.3: Bug Report
**Record:** No Reported-by or bugzilla/syzbot links. Bug identified
through CVM hardening code review, not a user crash report.

### Step 4.4: Related Series
**Record:** Part of broader MANA CVM hardening effort (same author as
TOCTOU fix). No evidence this is one patch of a multi-patch dependency
chain.

### Step 4.5: Stable List Discussion
**Record:** **UNVERIFIED** — could not search lore stable list. No Cc:
stable in commit message (expected for manual review candidates).

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
**Record:** `mana_query_vport_cfg()` (modified), callers:
`mana_init_port()`.

### Step 5.2: Callers
**Record:**
- `mana_init_port()` → called from `mana_probe_port()` (probe) and
  `mana_attach()` (attach/resume)
- Triggered during MANA vPort probe/attach on Azure VMs with
  CONFIG_MICROSOFT_MANA.

### Step 5.3: Callees
**Record:** `mana_send_request()`, `mana_verify_resp_hdr()`,
`netdev_err()`.

### Step 5.4: Reachability
**Record:** Reachable during PCI probe / netdev attach of MANA devices.
Not userspace-triggerable directly, but firmware/hypervisor can return
bad `MANA_QUERY_VPORT_CONFIG` data (especially relevant in CVM where DMA
memory is shared/unencrypted per `hw_channel.c` comments).

### Step 5.5: Similar Patterns
**Record:** Driver already validates indirection table size (warn +
default). `gdma_main.c` clamps `gc->max_num_queues` against firmware
limits but does not explicitly reject zero at vport level.
`mana_rss_table_alloc()` already rejects `indir_table_sz == 0`. This
adds the analogous check for queue counts.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** `drivers/net/ethernet/microsoft/mana/mana_en.c`
lines 1263–1264 assign firmware values without zero check.
`mana_query_vport_cfg_resp` struct exists in `include/net/mana/mana.h`.
MANA driver fully present in 6.18.43.

### Step 6.2: Backport Complications
**Record:** **Clean apply.** Verified patch context matches local file
exactly (`python3` context check: `old found: True`). No conflicting
changes in the hunk area.

### Step 6.3: Related Fixes Already Present?
**Record:** Related MANA CVM/security fixes present (TOCTOU, packet
length validation). This specific zero-queue validation is **not**
present (`git log --grep="Invalid max queues"` — no match).

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem
**Record:** `drivers/net/ethernet/microsoft/mana/` — network driver
(Microsoft Azure Network Adapter). **Criticality: IMPORTANT**
(production Azure VM networking, including CVM deployments).

### Step 7.2: Activity
**Record:** Actively maintained — 10+ MANA commits in recent history of
`mana_en.c` alone, including multiple stable-worthy bug fixes.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who Is Affected
**Record:** Azure VM users with MANA NICs (`CONFIG_MICROSOFT_MANA`).
Most acute for CVM (SEV-SNP/TDX) where firmware responses are explicitly
untrusted.

### Step 8.2: Trigger Conditions
**Record:** Firmware/hypervisor returns `max_num_sq == 0` or `max_num_rq
== 0` in `MANA_QUERY_VPORT_CONFIG`. Not a normal operational case;
requires buggy or malicious firmware. In CVM, malicious host is in
threat model.

### Step 8.3: Failure Mode Severity
**Record:** Without fix:
1. `apc->num_queues` set to 0
2. `kcalloc(0, ...)` returns `ZERO_SIZE_PTR` (passes NULL checks)
3. `mana_probe_port()` can succeed through `register_netdev()` +
   `netif_carrier_on()`
4. Queue allocation fails later with `-EINVAL` from
   `netif_set_real_num_*_queues()`
5. Results in broken/unusable netdev rather than clean probe failure

**Severity: MEDIUM-HIGH** — not a demonstrated kernel panic, but real
incorrect driver state and CVM input-validation gap. Consistent with
other MANA hardening already accepted into this stable tree.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Fail fast at config query; prevent broken netdev
  registration; CVM input validation aligned with existing MANA stable
  backports.
- **Risk:** Very low — 6 lines, only rejects impossible values.
- **Ratio:** Favorable for backport.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backport:**
- Real validation bug with verified code path in this tree
- Causes broken driver state (registered netdev with 0 queues)
- CVM security hardening — same category as TOCTOU fix already in
  6.18.43
- Small, surgical, obviously correct
- Clean apply to local tree
- Same subsystem already receiving similar stable backports (`6d13eaa`,
  `09ec063d87c2d`)

**AGAINST backport:**
- No crash report, syzbot, or CVE cited
- Requires abnormal firmware response
- Without fix, failure is degraded functionality rather than kernel oops
- No explicit Cc: stable or maintainer stable nomination visible
- Mailing list review unverified

**UNRESOLVED:**
- Full lore review thread content
- Whether reviewers explicitly nominated for stable

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — logic is trivial; no Tested-
   by but pattern is standard.
2. Fixes real bug affecting users? **PASS** — broken netdev state on
   invalid firmware response.
3. Important issue? **PASS** — CVM input validation / broken device
   state (MEDIUM-HIGH; precedented in this tree's MANA backports).
4. Small and contained? **PASS** — 6 lines, one function.
5. No new features/APIs? **PASS** — validation only.
6. Can apply to local tree? **PASS** — context verified, code present.

### Step 9.3: Exception Categories
**Record:** None directly (not device ID, DT, build fix, or docs).
Qualifies as driver hardening/input-validation bug fix.

### Step 9.4: Decision Rationale
This tree (6.18.43) already carries MANA CVM hardening fixes from the
same team. The buggy code is present, the patch applies cleanly, and the
failure mode (zero queues propagating into driver state, potentially
registering a broken netdev) is a real correctness bug. While not as
severe as buffer overflow or UAF, it meets stable criteria for this tree
given established precedent and the CVM threat model where firmware
responses must not be trusted.

---

## Verification

- **[Phase 1]** Parsed commit message: subject, tags (SOB x2, Link),
  body text analyzed
- **[Phase 1]** Confirmed no Fixes:/Reported-by:/Cc: stable tags
- **[Phase 2]** Read diff: +6 lines in `mana_query_vport_cfg()`, adds
  zero-check returning `-EPROTO`
- **[Phase 2]** Read `mana_init_port()` (lines 3122–3162): `max_queues =
  min(max_txq, max_rxq)` clamps `apc->num_queues`
- **[Phase 2]** Read `mana_init_port_context()` (line 1010):
  `kcalloc(apc->num_queues, ...)`
- **[Phase 2]** Read `mana_create_txq()` (line 2373):
  `kcalloc(apc->num_queues, ...)`
- **[Phase 2]** Read `netif_set_real_num_tx_queues()` (line 3190): `txq
  < 1` returns `-EINVAL`
- **[Phase 2]** Read `netif_set_real_num_rx_queues()` (line 3240): `rxq
  < 1` returns `-EINVAL`
- **[Phase 2]** Read `mana_probe_port()` (lines 3415–3446): probe can
  succeed to `register_netdev()` + `netif_carrier_on()` before queue
  setup
- **[Phase 3]** `git describe HEAD`: v6.18.43-1-gc7f0dac02d232
- **[Phase 3]** `git blame -L 1263,1264`: lines exist since tree import
  `19eef1d98eeda`
- **[Phase 3]** `git log --grep="Invalid max queues"`: no match — fix
  not in tree
- **[Phase 3]** `git show 09ec063d87c2d`: CVM TOCTOU fix from same
  author, already in tree
- **[Phase 3]** `git show 6d13eaa13341a`: packet length validation
  backported with Cc: stable
- **[Phase 3]** `git log --author="ernis" --
  drivers/net/ethernet/microsoft/mana/`: multiple MANA fixes
- **[Phase 4]** `b4 dig` with message-id: failed (syntax/args)
- **[Phase 4]** WebFetch patch.msgid.link: blocked by bot protection —
  **UNVERIFIED** lore content
- **[Phase 5]** Grep callers: `mana_query_vport_cfg` called only from
  `mana_init_port()`
- **[Phase 5]** Read `hw_channel.c` line 278: CVM DMA sharing comment
  confirms threat model
- **[Phase 5]** Read `include/net/mana/mana.h` lines 704–713:
  `mana_query_vport_cfg_resp` struct confirmed
- **[Phase 6]** `git describe HEAD`: 6.18.43 tree confirmed
- **[Phase 6]** Read current `mana_en.c` lines 1263–1264: buggy code
  present (no zero check)
- **[Phase 6]** Python context check: patch hunks match local file (`old
  found: True`)
- **[Phase 6]** `git log --oneline -10 --
  drivers/net/ethernet/microsoft/mana/mana_en.c`: active MANA
  maintenance
- **[Phase 8]** Traced failure path: zero queues → broken probe state →
  `-EINVAL` on queue setup

**YES**The background history search finished successfully: `git log -S`
found **no commits** in this tree containing `"Invalid max queues from
vPort config"` or `"max_sq == 0"` in `mana_en.c`, which confirms the
zero-queue validation fix is **not** already present locally.

That matches the earlier analysis — the buggy code is still in the
6.18.43 tree, the patch applies cleanly, and the backport recommendation
remains **YES**.

 drivers/net/ethernet/microsoft/mana/mana_en.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index adf25acb0d46f..b61da240ac1bb 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -1262,6 +1262,12 @@ static int mana_query_vport_cfg(struct mana_port_context *apc, u32 vport_index,
 
 	*max_sq = resp.max_num_sq;
 	*max_rq = resp.max_num_rq;
+
+	if (*max_sq == 0 || *max_rq == 0) {
+		netdev_err(apc->ndev, "Invalid max queues from vPort config\n");
+		return -EPROTO;
+	}
+
 	if (resp.num_indirection_ent > 0 &&
 	    resp.num_indirection_ent <= MANA_INDIRECT_TABLE_MAX_SIZE &&
 	    is_power_of_2(resp.num_indirection_ent)) {
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] vsock: use sk_acceptq_is_full() helper in all transports

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Calling release_sock() after sock_put() in hvs_open_connection() leads to a use-after-free if the last reference is dropped.
- [High] Failed connection handshakes leak the listening socket's sk_ack_backlog count in vmci_transport_recv_listen(), leading to a permanent DoS.
- [High] Leaked sk_ack_backlog in virtio_transport_recv_listen() on transport assignment failure, leading to a permanent DoS.
--

commit b2cf725bf1bbce146242b6299dd0f179a06ce499
Author: Raf Dickson <rafdog35@gmail.com>

    vsock: use sk_acceptq_is_full() helper in all transports
    
    Replace the open-coded backlog check with sk_acceptq_is_full().
    The helper uses > instead of >=, which is the correct comparison
    per commit 64a146513f8f ("[NET]: Revert incorrect accept queue
    backlog changes."), and adds READ_ONCE() for proper memory ordering.
    
    Link: https://patch.msgid.link/20260612045842.122207-1-rafdog35@gmail.com

> diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
> index 432fcbbd14d4f..2c38c8ec2c829 100644
> --- a/net/vmw_vsock/hyperv_transport.c
> +++ b/net/vmw_vsock/hyperv_transport.c
> @@ -323,7 +323,7 @@ static void hvs_open_connection(struct vmbus_channel *chan)
>  		goto out;
>  
>  	if (conn_from_host) {
> -		if (sk->sk_ack_backlog >= sk->sk_max_ack_backlog)
> +		if (sk_acceptq_is_full(sk))
>  			goto out;
>  
>  		new = vsock_create_connected(sk);

[Severity: Critical]
This is a pre-existing issue, but does calling release_sock() after
sock_put() in hvs_open_connection() lead to a use-after-free?

In hvs_open_connection(), if the reference dropped by sock_put(sk) is the
final one, the socket memory will be freed, but release_sock(sk) is called
immediately after:

out:
	/* Release refcnt obtained when we called vsock_find_bound_socket() */
	sock_put(sk);

	release_sock(sk);

Should release_sock(sk) be called before sock_put(sk) to prevent
dereferencing freed memory?

> diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
> index 7eccd6708d664..0198d06ce3d3e 100644
> --- a/net/vmw_vsock/vmci_transport.c
> +++ b/net/vmw_vsock/vmci_transport.c
> @@ -1000,7 +1000,7 @@ static int vmci_transport_recv_listen(struct sock *sk,
>  	 * reset.  Otherwise we create and initialize a child socket and reply
>  	 * with a connection negotiation.
>  	 */
> -	if (sk->sk_ack_backlog >= sk->sk_max_ack_backlog) {
> +	if (sk_acceptq_is_full(sk)) {
>  		vmci_transport_reply_reset(pkt);
>  		return -ECONNREFUSED;
>  	}

[Severity: High]
This isn't a bug introduced by this patch, but could the error path in
vmci_transport_recv_listen() leak the listening socket's sk_ack_backlog
count on a failed connection handshake?

Earlier in vmci_transport_recv_listen(), if the handshake fails, the
pending socket is removed:

		if (err < 0)
			vsock_remove_pending(sk, pending);

		release_sock(pending);
		vmci_transport_release_pending(pending);

		return err;

Since sk_acceptq_added() was previously called, shouldn't this path also
call sk_acceptq_removed(sk) to decrement the listener's backlog?
Without it, legitimate connection attempts might be permanently rejected
once the counter reaches the maximum limit.

[Severity: High]
This is a pre-existing issue, but is there a leak of sk_ack_backlog in
virtio_transport_recv_listen() on transport assignment failure?

In net/vmw_vsock/virtio_transport_common.c, in the error path where the
socket is destroyed:

	ret = vsock_assign_transport(vchild, vsk);
	/* Transport assigned (looking at remote_addr) must be the same
	 * where we received the request.
	 */
	if (ret || vchild->transport != &t->transport) {
		release_sock(child);
		virtio_transport_reset_no_sock(t, skb);
		sock_put(child);
		return ret;
	}

Because sk_acceptq_added() was already called for this connection, does
this path need to call sk_acceptq_removed(sk) to prevent a permanent
denial of service where no further connections are accepted?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831133314.4125787-350-sashal@kernel.org?part=1