[PATCH AUTOSEL 7.0-6.12] HID: logitech-hidpp: Add support for newer Bluetooth keyboards

[PATCH AUTOSEL 7.0-6.12] HID: logitech-hidpp: Add support for newer Bluetooth keyboards

[Sasha Levin]

From: Alain Michaud <alainmichaud@google.com>

[ Upstream commit 64ffa2e5e02ff54b23221d0282155f37283fabea ]

Add product IDs (PIDs) for several newer Logitech Bluetooth keyboards
to the hidpp_devices matching table, enabling full HID++ support for
them.

The added keyboards are:
- Logitech Signature K650 & B2B
- Logitech Pebble Keys 2 K380S
- Logitech Casa Pop-Up Desk & B2B
- Logitech Wave Keys & B2B
- Logitech Signature Slim K950 & B2B
- Logitech MX Keys S & B2B
- Logitech Keys-To-Go 2
- Logitech Pop Icon Keys
- Logitech MX Keys Mini & B2B
- Logitech Signature Slim Solar+ K980 B2B
- Logitech Bluetooth Keyboard K250/K251
- Logitech Signature Comfort K880 & B2B

Signed-off-by: Alain Michaud <alainmichaud@google.com>
Reviewed-by: Olivier Gay <ogay@logitech.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
**Phase 1 Record:** Subsystem `HID: logitech-hidpp`; action `Add`;
intent is to add Bluetooth PIDs so newer Logitech keyboards bind to
`hid-logitech-hidpp`. Tags: `Signed-off-by: Alain Michaud`, `Reviewed-
by: Olivier Gay <ogay@logitech.com>`, `Signed-off-by: Jiri Kosina`; no
`Fixes`, `Reported-by`, `Tested-by`, `Link`, or stable Cc. Body
describes hardware enablement, not crash/security. Hidden bug fix: no,
this is explicit device-ID enablement.

**Phase 2 Record:** One file changed: `drivers/hid/hid-logitech-
hidpp.c`, 38 insertions, all in `hidpp_devices[]`. Before: listed
Logitech Bluetooth devices stopped at existing IDs such as
`0xb391`/`0xb042`. After: adds 19
`HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, pid)` entries. Bug
category: hardware enablement/device IDs. Fix quality: mechanically
simple, no code flow, locking, allocation, ABI, or API changes.

**Phase 3 Record:** Upstream commit is
`64ffa2e5e02ff54b23221d0282155f37283fabea`, contained by
`v7.1-rc4~28^2`. Blame shows the new entries are from this commit;
surrounding table entries are established prior HID++ Bluetooth IDs. No
`Fixes:` tag to follow. Related history shows repeated prior Logitech
HID++ Bluetooth ID additions, plus a prior broad “match all Logitech
Bluetooth” approach that was reverted because it could bind unsupported
mice and leave them dead. This supports the narrow-ID approach. Author
has only this HID/HIDPP commit locally; reviewer/maintainer path is
through HID maintainers.

**Phase 4 Record:** `b4 dig -c 64ffa2e5e02f` found the original
submission at `https://patch.msgid.link/20260512132244.2194556-1-
alainmichaud@google.com`. `b4 dig -a` showed only v1. `b4 dig -w` showed
Jiri Kosina, Benjamin Tissoires, HID++/Logitech reviewers, `linux-
input`, and `linux-kernel` were included. Saved mbox shows Jiri replied
“Applied, thanks.” No objections or stable nomination found in that
mbox. WebFetch to lore/stable was blocked by Anubis, so stable-list
search could not be verified externally.

**Phase 5 Record:** Key changed object is `hidpp_devices[]`. It is
assigned to `hidpp_driver.id_table`, exported via `MODULE_DEVICE_TABLE`,
and registered by `module_hid_driver(hidpp_driver)`. HID core uses
`hid_match_device()` -> `hid_match_id()` against `hdrv->id_table`,
matching bus/vendor/product. `HID_BLUETOOTH_DEVICE` expands to
`BUS_BLUETOOTH` plus vendor/product. Reachability: Bluetooth HID device
enumeration/driver matching. Similar pattern: many existing Logitech
Bluetooth HID++ IDs in the same table.

**Phase 6 Record:** Checked tags `v5.10`, `v5.15`, `v6.1`, `v6.6`,
`v6.12`, `v6.18`, `v6.19`, and `v7.0`: all have `hidpp_devices[]`,
`MODULE_DEVICE_TABLE(hid, hidpp_devices)`, and `HID_BLUETOOTH_DEVICE`;
all lack the candidate PIDs. Patch applies cleanly to current
`stable/linux-7.0.y`; older trees likely need trivial context placement
because some newer adjacent IDs are absent.

**Phase 7 Record:** Subsystem is HID Logitech HID++ driver, under
maintained HID/Input. Criticality: driver-specific, but for affected
Logitech keyboard users it controls full HID++ support. Subsystem is
active; recent history includes HIDPP fixes and other device-ID
additions.

**Phase 8 Record:** Affected users are owners of the listed Logitech
Bluetooth keyboards on stable kernels. Trigger is pairing/using those
devices over Bluetooth. Failure mode is missing enhanced HID++ driver
support, not a crash; severity medium for affected hardware
functionality. Benefit is high for those users and low system-wide risk.
Risk is very low: data-only ID table entries, no behavioral change for
non-matching devices.

**Phase 9 Record:** Evidence for backporting: classic stable exception
for adding device IDs to an existing driver; small and contained;
reviewed by Logitech contact; applied by HID maintainer; code exists in
active stable trees; prior history favors explicit IDs over broad
matching. Evidence against: not a crash/security/data-corruption fix;
product ID correctness is verified only by commit review, not an
external public spec. Stable checklist: obviously correct yes; real
user-visible hardware support issue yes; important under device-ID
exception yes; small/contained yes; no new API yes; applies cleanly to
7.0 and should be trivial elsewhere.

## Verification
- [Phase 1] Parsed commit metadata with `git show --format=fuller`:
  confirmed tags and no `Fixes`/`Reported-by`.
- [Phase 2] Inspected full diff: 38 insertions only in
  `hidpp_devices[]`.
- [Phase 3] Used `git blame` around the table and `git log` on the file:
  confirmed surrounding HID++ Bluetooth ID history and related revert of
  broad Bluetooth matching.
- [Phase 4] Used `b4 dig -c/-a/-w` and saved/read mbox: confirmed v1
  thread, recipients, and maintainer “Applied, thanks.”
- [Phase 5] Used code search/read of `hid-core.c`,
  `include/linux/hid.h`, and `hid-logitech-hidpp.c`: confirmed driver
  table matching path.
- [Phase 6] Checked stable tags for table/macro/PID presence and ran
  `git apply --check` on current 7.0 tree.
- [Phase 7] Checked `MAINTAINERS` and recent HID/HIDPP logs.
- [Phase 8] Impact/risk derived from verified diff and HID matching
  path.
- UNVERIFIED: lore stable-search results, because WebFetch was blocked
  by Anubis.
- UNVERIFIED: independent public confirmation of every Logitech PID
  beyond the patch author/reviewer/maintainer record.

This should be backported under the stable device-ID exception. It
enables existing HID++ driver support for specific hardware with minimal
regression risk.

**YES**

 drivers/hid/hid-logitech-hidpp.c | 38 ++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index d1dea7297712d..68f055ef1f444 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4672,6 +4672,44 @@ static const struct hid_device_id hidpp_devices[] = {
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb391) },
 	{ /* MX Master 4 mouse over Bluetooth */
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb042) },
+	{ /* Logitech Signature K650 over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb36f) },
+	{ /* Logitech Signature K650 B2B over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb370) },
+	{ /* Logitech Pebble Keys 2 K380S over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb377) },
+	{ /* Logitech Casa Pop-Up Desk over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb371) },
+	{ /* Logitech Casa Pop-Up Desk B2B over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb374) },
+	{ /* Logitech Wave Keys over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb383) },
+	{ /* Logitech Wave Keys B2B over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb384) },
+	{ /* Logitech Signature Slim K950 over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb386) },
+	{ /* Logitech Signature Slim K950 B2B over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb388) },
+	{ /* Logitech MX Keys S over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb378) },
+	{ /* Logitech MX Keys S B2B over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb380) },
+	{ /* Logitech Keys-To-Go 2 over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb38c) },
+	{ /* Logitech Pop Icon Keys over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb38f) },
+	{ /* Logitech MX Keys Mini over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb369) },
+	{ /* Logitech MX Keys Mini B2B over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb36e) },
+	{ /* Logitech Signature Slim Solar+ K980 B2B over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb394) },
+	{ /* Logitech Bluetooth Keyboard K250/K251 over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb397) },
+	{ /* Logitech Signature Comfort K880 over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb39c) },
+	{ /* Logitech Signature Comfort K880 B2B over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb39d) },
 	{}
 };
 
-- 
2.53.0

[PATCH AUTOSEL 7.0] drm/amdgpu: remove deadlocks from amdgpu_userq_pre_reset

[Sasha Levin]

From: Christian König <christian.koenig@amd.com>

[ Upstream commit d5971c5c34303a00bf841a902ca00a703602c500 ]

The purpose of a GPU reset is to make sure that fence can be signaled
again and the signal and resume workers can make progress again.

So waiting for the resume worker or any fence in the GPU reset path is
just utterly nonsense.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Prike Liang <Prike.Liang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit fcd5f065eab46993af43442fd77ee8d9eb9c5bdf)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
This should be backported for stable trees that contain
`amdgpu_userq_pre_reset()`. It removes two blocking waits from the GPU
reset path: `cancel_delayed_work_sync(&uqm->resume_work)` and
`amdgpu_userq_wait_for_last_fence()`, where the latter waits on
`dma_fence_wait_timeout(..., MAX_SCHEDULE_TIMEOUT)`. The reset path is
precisely what is supposed to let those fences/workers make progress, so
waiting there can deadlock GPU recovery.

The patch is one-function, one-file, no new API, and `git apply --check`
succeeds against this `7.0.y` checkout. Main concern: the review thread
confirms broader queue-state locking concerns remain, but those are pre-
existing and the accepted patch was explicitly scoped to removing the
obvious deadlock.

## Phase Walkthrough
Phase 1:
- Record 1.1: subsystem `drm/amdgpu`; action `remove`; intent is to
  remove deadlocks from `amdgpu_userq_pre_reset()`.
- Record 1.2: tags present: `Signed-off-by: Christian König`, `Reviewed-
  by: Prike Liang`, `Signed-off-by: Alex Deucher`; no `Fixes:`,
  `Reported-by:`, `Tested-by:`, `Acked-by:`, `Link:`, or `Cc: stable`.
- Record 1.3: commit body says GPU reset exists to allow fences and
  signal/resume workers to progress; waiting for resume worker or fences
  inside reset is wrong. Failure mode: reset can hang/deadlock.
- Record 1.4: not hidden; it is explicitly a deadlock fix.

Phase 2:
- Record 2.1: one file, `drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c`,
  `+12/-14`; only `amdgpu_userq_pre_reset()` changed; single-file
  surgical fix.
- Record 2.2: before, reset path canceled `resume_work` synchronously
  and waited for `last_fence` before unmapping mapped queues. After, it
  skips non-mapped queues and directly unmaps/marks hung/force-completes
  mapped queues.
- Record 2.3: bug category is deadlock/hang. Mechanism: reset path
  waited on work/fences that may require reset progress to complete.
- Record 2.4: fix is minimal. Regression risk is low-to-medium because
  queue-state locking is still called out by the TODO and review
  discussion, but no new API or broad behavior is added.

Phase 3:
- Record 3.1: `git blame` shows the reset function came from
  `290f46cf57265` (`drm/amdgpu: Implement user queue reset
  functionality`); current textual lines were later touched by
  `473f12f820956` and `dc21e39fd20c7` helper/signature cleanups. `git
  describe --contains 290f46cf...` points to `v6.19-rc1`, so older
  stable trees before v6.19 likely do not contain this exact code.
- Record 3.2: no `Fixes:` tag, so no Fixes target to follow.
- Record 3.3: recent file history shows active userq work and related
  reset/fence changes; this patch applies standalone to current `7.0.y`.
- Record 3.4: `MAINTAINERS` lists Christian König and Alex Deucher as
  AMDGPU DRM maintainers; author/committer are subsystem maintainers.
- Record 3.5: no compile dependency found; patch is part of an 11-patch
  series but applies cleanly by itself.

Phase 4:
- Record 4.1: `b4 dig` failed because the commit object is absent
  locally. Fallback found the original patch at
  `lists.freedesktop.org/archives/amd-gfx/2026-April/143199.html`;
  committed version matches the patch content with `Reviewed-by` added.
- Record 4.2: `b4 -w` failed; lore thread shows Alex Deucher, Prike
  Liang, Sunil Khatri, and `amd-gfx` were involved.
- Record 4.3: no external bug report or syzbot link found.
- Record 4.4: series context exists (`[PATCH 02/11]`), with later
  userq/fence/reset cleanups, but no hard prerequisite was identified
  for this specific deadlock removal.
- Record 4.5: web search did not find stable-list discussion for this
  exact patch.

Phase 5:
- Record 5.1: modified function: `amdgpu_userq_pre_reset()`.
- Record 5.2: callers: local search shows only
  `amdgpu_device_halt_activities()`, called from
  `amdgpu_device_gpu_recover()` and PCI error handling.
- Record 5.3: affected callees include `userq_funcs->unmap()` and
  `amdgpu_userq_fence_driver_force_completion()`; removed callees
  include `cancel_delayed_work_sync()` and
  `amdgpu_userq_wait_for_last_fence()`.
- Record 5.4: reachable through AMDGPU recovery paths, including job
  timeout/GPU recovery paths; exact unprivileged trigger policy was not
  fully verified.
- Record 5.5: similar wait/cancel patterns remain in non-reset paths
  such as destroy/suspend/eviction, but the reset-path instance is the
  one fixed here.

Phase 6:
- Record 6.1: buggy code exists in this `7.0.y` tree and appears
  introduced for `v6.19-rc1`; likely relevant to v6.19+ stable trees
  containing userq reset support.
- Record 6.2: `git apply --check` succeeds against this checkout, so
  current `7.0.y` backport difficulty is clean.
- Record 6.3: no exact related stable replacement fix found locally or
  in web stable search.

Phase 7:
- Record 7.1: subsystem is AMDGPU DRM driver; criticality is IMPORTANT,
  driver-specific but for widely used GPU hardware.
- Record 7.2: subsystem/file is active; recent history contains many
  userq reset/fence fixes and refactors.

Phase 8:
- Record 8.1: affected users are AMDGPU users with user queues enabled
  who hit GPU reset/recovery.
- Record 8.2: trigger is GPU reset while user queues have pending resume
  work or unsignaled fences; commonality depends on userq usage and GPU
  hangs.
- Record 8.3: failure mode is GPU reset deadlock/hang; severity HIGH to
  CRITICAL because recovery can stall.
- Record 8.4: benefit is high for affected systems; risk is low-to-
  medium due small scope but reset-path concurrency sensitivity. Ratio
  favors backport.

Phase 9:
- Record 9.1 FOR: fixes deadlock, reset-path hang, small one-function
  diff, maintainer-authored, reviewed, applies cleanly. AGAINST: no
  reported user bug, no stable tag, part of a larger userq series,
  residual queue-state locking TODO. UNRESOLVED: no runtime
  reproduction/build, exact applicability to every active stable branch
  not verified.
- Record 9.2 stable rules: obviously correct enough by code and
  maintainer review: yes; fixes real bug: yes, deadlock; important
  issue: yes, recovery hang; small/contained: yes; no new API/features:
  yes; can apply to current stable tree: yes.
- Record 9.3 exception category: none.
- Record 9.4 decision: backport to stable trees containing this userq
  reset code.

## Verification
- [Phase 1] Parsed GitHub patch and lore message: confirmed subject,
  body, tags, and lack of `Fixes`/`Cc stable`.
- [Phase 2] Compared diff: confirmed one-file `+12/-14` change removing
  `cancel_delayed_work_sync()` and `amdgpu_userq_wait_for_last_fence()`.
- [Phase 3] `git blame`: confirmed reset code origin/refactor history
  around `amdgpu_userq_pre_reset()`.
- [Phase 3] `git describe --contains`: confirmed introduction is in the
  v6.19 era.
- [Phase 3] `MAINTAINERS`: confirmed Christian König and Alex Deucher
  maintain AMDGPU DRM.
- [Phase 4] `b4 dig -c/-a/-w`: failed because commit object is not in
  this checkout.
- [Phase 4] WebFetch GitHub patch and freedesktop lore: confirmed
  original patch, review discussion, and `Reviewed-by: Prike Liang`.
- [Phase 5] `rg` and file reads: confirmed caller path through
  `amdgpu_device_halt_activities()` and `amdgpu_device_gpu_recover()`.
- [Phase 6] `git apply --check`: confirmed clean application to current
  `7.0.y`.
- UNVERIFIED: no kernel build or runtime reproduction was performed;
  exact applicability to all non-`7.0.y` stable trees was not fully
  checked.

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 26 +++++++++++------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
index 0a1b93259887a..6f49ba3bd0394 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
@@ -1583,23 +1583,21 @@ void amdgpu_userq_pre_reset(struct amdgpu_device *adev)
 {
 	const struct amdgpu_userq_funcs *userq_funcs;
 	struct amdgpu_usermode_queue *queue;
-	struct amdgpu_userq_mgr *uqm;
 	unsigned long queue_id;
 
+	/* TODO: We probably need a new lock for the queue state */
 	xa_for_each(&adev->userq_doorbell_xa, queue_id, queue) {
-		uqm = queue->userq_mgr;
-		cancel_delayed_work_sync(&uqm->resume_work);
-		if (queue->state == AMDGPU_USERQ_STATE_MAPPED) {
-			amdgpu_userq_wait_for_last_fence(queue);
-			userq_funcs = adev->userq_funcs[queue->queue_type];
-			userq_funcs->unmap(queue);
-			/* just mark all queues as hung at this point.
-			 * if unmap succeeds, we could map again
-			 * in amdgpu_userq_post_reset() if vram is not lost
-			 */
-			queue->state = AMDGPU_USERQ_STATE_HUNG;
-			amdgpu_userq_fence_driver_force_completion(queue);
-		}
+		if (queue->state != AMDGPU_USERQ_STATE_MAPPED)
+			continue;
+
+		userq_funcs = adev->userq_funcs[queue->queue_type];
+		userq_funcs->unmap(queue);
+		/* just mark all queues as hung at this point.
+		 * if unmap succeeds, we could map again
+		 * in amdgpu_userq_post_reset() if vram is not lost
+		 */
+		queue->state = AMDGPU_USERQ_STATE_HUNG;
+		amdgpu_userq_fence_driver_force_completion(queue);
 	}
 }
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ALSA: sparc/dbri: add missing fallthrough

[Sasha Levin]

From: Rosen Penev <rosenp@gmail.com>

[ Upstream commit 2bcbb163162789d3488562073dbb99d9bd71a762 ]

Fixes compiler error with probably newer compilers:

sound/sparc/dbri.c:595:2: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
  595 |         case 1:
      |         ^
sound/sparc/dbri.c:595:2: note: insert 'break;' to avoid fall-through
  595 |         case 1:
      |         ^
      |         break;

Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260506031854.780411-1-rosenp@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

Step 1.1 Record: Subsystem `ALSA: sparc/dbri`; action verb `add`; intent
is to add a missing `fallthrough` annotation in `reverse_bytes()`.

Step 1.2 Record: Tags present: `Signed-off-by: Rosen Penev
<rosenp@gmail.com>`, `Link:
https://patch.msgid.link/20260506031854.780411-1-rosenp@gmail.com`,
`Signed-off-by: Takashi Iwai <tiwai@suse.de>`. No `Fixes:`, `Reported-
by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc: stable`.

Step 1.3 Record: The commit body reports a concrete compiler error:
`-Werror,-Wimplicit-fallthrough` in `sound/sparc/dbri.c` at the
fallthrough from `case 2` to `case 1`. Symptom is a build failure for
this driver/config with a compiler that diagnoses this unannotated
fallthrough as an error. No kernel version is named. Root cause is an
intentional fallthrough lacking the kernel `fallthrough;` marker.

Step 1.4 Record: This is not a hidden runtime bug fix; it is an explicit
build fix. Build fixes are stable-acceptable when they repair
compilation of existing code.

## Phase 2: Diff Analysis

Step 2.1 Record: One file changed: `sound/sparc/dbri.c`, `+1/-0`. One
function modified: `reverse_bytes()`. Scope is a single-file, one-line
surgical build fix.

Step 2.2 Record: Before, `case 2` performed the final bit swap and
implicitly fell into `case 1`/`case 0`, which then `break`s. After, the
same fallthrough is explicitly annotated with `fallthrough;`. Runtime
control flow is unchanged.

Step 2.3 Record: Bug category is build fix / compiler diagnostic fix.
Specific mechanism: the kernel already annotates earlier intentional
fallthroughs in the same switch, but the `case 2` to `case 1`
fallthrough lacked the annotation, triggering `-Wimplicit-fallthrough`
as an error.

Step 2.4 Record: Fix quality is high: it is one line, uses the existing
kernel `fallthrough` pseudo-keyword, matches nearby code style in
current branches, and does not change APIs or runtime behavior.
Regression risk is very low.

## Phase 3: Git History Investigation

Step 3.1 Record: `git blame` on `2bcbb16316278^` attributes this code to
`c3c9a75ede23f`, but the repository is shallow/grafted there, so that is
not a reliable true introduction point. I verified the same missing
annotation exists in local stable-related branches `pending-5.4`,
`pending-5.10`, `pending-5.15`, `pending-6.1`, `pending-6.6`,
`pending-6.12`, `pending-6.19`, and `pending-7.0`.

Step 3.2 Record: No `Fixes:` tag is present, so there is no introducing
commit to follow from the message.

Step 3.3 Record: Recent `sound/sparc/dbri.c` history on `linux-
next/master` shows this commit, then `ALSA: sparc/dbri: Use guard() for
spin locks`, then the shallow boundary. The guard refactor is not a
semantic prerequisite for adding this annotation, although older stable
branches may have slightly different context.

Step 3.4 Record: Author Rosen Penev has this recent `sound/sparc` commit
in the checked history. The commit was applied by Takashi Iwai, and
`MAINTAINERS` lists Takashi Iwai and Jaroslav Kysela as SOUND
maintainers.

Step 3.5 Record: No dependent `reverse_bytes` commits were found by
subject search. The change can be applied standalone as an annotation.
For `pending-5.4`, context differs because earlier fallthroughs are
comments rather than `fallthrough;`, so that tree may need a trivial
backport adjustment.

## Phase 4: Mailing List And External Research

Step 4.1 Record: `b4 dig -c 2bcbb16316278` found the original submission
at the provided lore/patch URL. `b4 dig -a` found only v1; no later
revision. The saved mbox contains Takashi Iwai’s reply: “Applied now.
Thanks.” No NAKs or concerns were present in the fetched thread.

Step 4.2 Record: `b4 dig -w` shows recipients: Rosen Penev, `linux-
sound@vger.kernel.org`, Jaroslav Kysela, Takashi Iwai, and `linux-
kernel@vger.kernel.org`.

Step 4.3 Record: No separate bug report or `Reported-by` tag. The
reported failure is the compiler diagnostic included in the patch email
and commit message.

Step 4.4 Record: `b4 dig -a` shows this is a single-patch series, not
part of a multi-patch dependency chain.

Step 4.5 Record: WebFetch to lore/stable search was blocked by Anubis.
Local stable branch log searches did not find this exact fix or a
related `unannotated fall-through` fix already present in the checked
stable branches.

## Phase 5: Code Semantic Analysis

Step 5.1 Record: Modified function: `reverse_bytes()`.

Step 5.2 Record: Callers found in `sound/sparc/dbri.c`: `xmit_fixed()`
calls `reverse_bytes()` for MSB fixed-pipe transmit data;
`dbri_process_one_interrupt()` calls it for fixed-data receive
interrupts.

Step 5.3 Record: `reverse_bytes()` only performs bit manipulation and
may print an error for unsupported lengths; it does not allocate memory,
take locks, or call into external subsystems.

Step 5.4 Record: Runtime paths are reachable through DBRI/CS4215
initialization/control and interrupt handling on supported SPARC SBus
DBRI hardware. For this patch, runtime reachability is not the main
issue because the fix targets compilation and preserves runtime flow.

Step 5.5 Record: Nearby switch cases already had intentional fallthrough
annotations; this patch fills the only missing annotation in that chain.

## Phase 6: Stable Tree Analysis

Step 6.1 Record: The missing annotation exists in checked stable-related
branches from `pending-5.4` through `pending-7.0`. Therefore the
affected source is present in active stable-era trees available locally.

Step 6.2 Record: Expected backport difficulty is clean or trivial for
most branches. `pending-5.4` has older comment-style fallthrough context
before `case 2`, so it may require a small context adjustment, but the
same one-line semantic change applies.

Step 6.3 Record: No related fix with this subject or `unannotated fall-
through` in `sound/sparc/dbri.c` was found in the checked stable-related
branches.

## Phase 7: Subsystem And Maintainer Context

Step 7.1 Record: Subsystem is ALSA SPARC sound driver, specifically Sun
DBRI. Criticality is peripheral/platform-specific, not core kernel-wide.

Step 7.2 Record: Recent `sound/sparc` history is sparse and mostly
maintenance/refactoring/build-style changes, indicating a mature low-
churn driver area.

## Phase 8: Impact And Risk Assessment

Step 8.1 Record: Affected users are config/platform-specific: SPARC/SBus
builds with `SND_SUN_DBRI`.

Step 8.2 Record: Trigger is building this driver with a
compiler/configuration that treats the unannotated fallthrough warning
as an error. I did not independently reproduce the compiler failure
locally.

Step 8.3 Record: Failure mode is build failure, not runtime crash or
data corruption. Severity is high for affected builders because the
kernel/module cannot be built successfully under that toolchain/config.

Step 8.4 Record: Benefit is meaningful for affected stable users because
it restores buildability of an existing driver. Risk is very low: one
annotation line, no feature, no API change, no runtime logic change.
Risk-benefit ratio favors backporting.

## Phase 9: Final Synthesis

Step 9.1 Record: Evidence for backporting: concrete compiler error,
existing driver code in stable branches, one-line obviously-correct fix,
maintainer-applied patch, no runtime behavior change, and build fixes
are valid stable material. Evidence against: platform-specific impact
and no independent local build reproduction. Unresolved: exact true
historical introduction predates the shallow boundary; lore stable
search via WebFetch was blocked.

Step 9.2 Record: Stable rules checklist:
1. Obviously correct and tested: yes for correctness by inspection;
   maintainer applied it. No local build test performed.
2. Fixes a real bug: yes, reported compiler error in existing code.
3. Important issue: yes for affected stable builds, because it can stop
   compilation.
4. Small and contained: yes, one line in one function.
5. No new features/APIs: yes.
6. Can apply to stable trees: yes with at most trivial context
   adjustment, especially for older comment-style fallthrough branches.

Step 9.3 Record: Exception category applies: build fix.

Step 9.4 Record: Decision is to backport. This is exactly the kind of
low-risk build fix stable trees should carry.

## Verification

- [Phase 1] Parsed `git show --format=fuller --stat --patch
  2bcbb16316278`: confirmed subject, tags, compiler-error body, and one-
  line patch.
- [Phase 2] Read `sound/sparc/dbri.c`: confirmed `reverse_bytes()` has
  annotated fallthroughs except the candidate-added `case 2` annotation.
- [Phase 3] Ran `git blame 2bcbb16316278^ -L 578,598 --
  sound/sparc/dbri.c`: confirmed changed area, with shallow/grafted
  limitation.
- [Phase 3] Ran branch snippet checks on `pending-5.4` through
  `pending-7.0`: confirmed the missing annotation exists in all checked
  stable-related branches.
- [Phase 3] Ran recent file history and author history checks: found
  only related maintenance/refactor commits, no dependency series.
- [Phase 4] Ran `b4 dig -c`, `-a`, `-w`, and saved the mbox: confirmed
  single v1 patch, proper ALSA recipients, and maintainer “Applied now”
  reply.
- [Phase 5] Searched `reverse_bytes(` call sites: confirmed callers are
  `xmit_fixed()` and `dbri_process_one_interrupt()`.
- [Phase 6] Searched stable branch logs: no existing backport or
  duplicate fix found locally.
- [Phase 7] Checked `MAINTAINERS`: confirmed SOUND maintainers include
  Jaroslav Kysela and Takashi Iwai.
- [Phase 8] Checked `include/linux/compiler_attributes.h`: confirmed
  `fallthrough` is the intended kernel pseudo-keyword and is available
  in checked stable branches.
- UNVERIFIED: I did not reproduce the compiler error with a local
  SPARC/SBus DBRI build.
- UNVERIFIED: The exact original introduction before the repository’s
  shallow/grafted boundary could not be determined.
- UNVERIFIED: WebFetch could not read lore/stable search results because
  Anubis blocked the page.

**YES**

 sound/sparc/dbri.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/sparc/dbri.c b/sound/sparc/dbri.c
index 75f82a92ff44f..2f5f62079fa4a 100644
--- a/sound/sparc/dbri.c
+++ b/sound/sparc/dbri.c
@@ -592,6 +592,7 @@ static __u32 reverse_bytes(__u32 b, int len)
 		fallthrough;
 	case 2:
 		b = ((b & 0xaaaaaaaa) >> 1) | ((b & 0x55555555) << 1);
+		fallthrough;
 	case 1:
 	case 0:
 		break;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] docs: cgroup-v1: Update charge-commit section

[Sasha Levin]

From: "T.J. Mercier" <tjmercier@google.com>

[ Upstream commit d8769544bde51b0ac980d10f8fe9f9fed6c95995 ]

Commit 1d8f136a421f ("memcg/hugetlb: remove memcg hugetlb
try-commit-cancel protocol") removed mem_cgroup_commit_charge() and
mem_cgroup_cancel_charge(), but the docs still refer to those functions.
There is no longer any charge cancellation.

Update the docs to match the code.

Signed-off-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `docs: cgroup-v1`; action verb `Update`;
intent: update `Documentation/admin-guide/cgroup-v1/memcg_test.rst` so
the charge-commit section matches current memcg code.

Step 1.2 Record: tags present: `Signed-off-by: T.J. Mercier
<tjmercier@google.com>` and `Signed-off-by: Tejun Heo <tj@kernel.org>`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable@vger.kernel.org` tags in the committed message.

Step 1.3 Record: the body says commit `1d8f136a421f` removed
`mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, while the
cgroup-v1 memcg docs still name them and describe cancellation.
Symptom/failure mode: incorrect documentation only. Version information:
the referenced removal commit is from 2025-01-13 in the local object
database; candidate commit is from 2026-04-30. Root cause: docs were not
updated when the code was changed.

Step 1.4 Record: this is not a hidden runtime bug fix. It is an explicit
documentation correctness fix.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `Documentation/admin-
guide/cgroup-v1/memcg_test.rst`, `2 insertions(+), 4 deletions(-)`. No
functions modified. Scope: single-file documentation-only surgical
change.

Step 2.2 Record: before, the section was titled `charge-commit-cancel`,
listed `mem_cgroup_commit_charge()` or `mem_cgroup_cancel_charge()`, and
described `cancel()`. After, it is titled `charge-commit`, lists
`commit_charge()`, and removes the cancellation text.

Step 2.3 Record: bug category is documentation/comment correctness.
Specific mechanism: removes stale references to APIs that are absent in
current `6.19.y`/`7.0.y` code and in `origin/master`.

Step 2.4 Record: fix quality is obviously correct for trees whose memcg
code no longer has `mem_cgroup_commit_charge()` /
`mem_cgroup_cancel_charge()`. Regression risk is zero runtime risk, but
there is a branch-selection concern: `stable/linux-6.12.y` still
contains those functions, so this exact doc update would be misleading
there.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` before the candidate shows the stale doc
lines came from `f3f5edc5e41e` in this repository’s history. `git blame
origin/master` shows the changed lines attributed to `d8769544bde51`.

Step 3.2 Record: no `Fixes:` tag. I still inspected referenced commit
`1d8f136a421f26747e58c01281cba5bffae8d289`; it removed prototypes and
implementations for `mem_cgroup_commit_charge()`,
`mem_cgroup_cancel_charge()`, and related hugetlb try/commit/cancel
helpers.

Step 3.3 Record: recent history for `Documentation/admin-
guide/cgroup-v1/memcg_test.rst` on `origin/master` has only the file
introduction/import commit and this candidate. Related path history
shows the candidate was merged via `cgroup-for-7.1-rc2-fixes`. No
prerequisite doc series found.

Step 3.4 Record: author `T.J. Mercier` has at least one other cgroup-
related commit in `origin/master`; Tejun Heo is listed in `MAINTAINERS`
as cgroup maintainer and committed the patch.

Step 3.5 Record: no code dependencies for the patch itself. It can apply
standalone to the current `stable/linux-7.0.y` checkout. Applicability
must be gated by whether the target tree’s code has removed the old
APIs.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c d8769544bde51...` found the original
submission at
`https://patch.msgid.link/20260430201142.240387-1-tjmercier@google.com`.
`b4 dig -a` found only v1 of a single-patch series. The mbox contains
Tejun’s reply: “Applied to cgroup/for-7.1-fixes.” No NAKs or concerns
found in the saved thread.

Step 4.2 Record: `b4 dig -w` shows recipients included cgroup
maintainers/list and docs list: `tj@kernel.org`, `hannes@cmpxchg.org`,
`mkoutny@suse.com`, `cgroups@vger.kernel.org`, `corbet@lwn.net`,
`skhan@linuxfoundation.org`, `linux-doc@vger.kernel.org`, `linux-
kernel@vger.kernel.org`.

Step 4.3 Record: no `Reported-by` or bug-report `Link:` tags. No syzbot,
bugzilla, or user-impact bug report applies.

Step 4.4 Record: b4 found a standalone single-patch series, not part of
a multi-patch dependency chain.

Step 4.5 Record: web search did not find stable-list discussion for this
exact patch. `WebFetch` to lore/patch.msgid was blocked by Anubis, but
b4 successfully fetched the mbox.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: no functions modified by the diff.

Step 5.2 Record: no callers affected by the diff. For documentation
accuracy, I verified current `stable/linux-7.0.y` code has
`commit_charge()` callers in `charge_memcg()`,
`mem_cgroup_replace_folio()`, and `mem_cgroup_migrate()`.

Step 5.3 Record: no changed callees. The relevant current code has
`commit_charge()` assigning `folio->memcg_data`, and callers also invoke
`memcg1_commit_charge()` where appropriate.

Step 5.4 Record: runtime reachability is not relevant because no
executable code changes.

Step 5.5 Record: similar stale docs pattern exists in stable branches;
however code state differs by branch. `6.19.y`/`7.0.y` have stale docs
and no old API. `6.12.y` still has `mem_cgroup_commit_charge()` and
`mem_cgroup_cancel_charge()` in code.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: buggy stale documentation exists in
`stable/linux-7.0.y`, `stable/linux-6.19.y`, `stable/linux-6.18.y`,
`stable/linux-6.6.y`, `stable/linux-6.1.y`, `stable/linux-5.15.y`, and
`stable/linux-5.10.y` by exact doc grep. I verified the old APIs are
absent in several of those trees, but `stable/linux-6.12.y` still
contains `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`,
so this exact upstream text is not universally correct for all
maintained stable lines.

Step 6.2 Record: `git apply --check` of the candidate diff succeeds on
the current `stable/linux-7.0.y` checkout. Expected backport difficulty:
clean for trees with matching doc context; branch-specific review needed
for `6.12.y`.

Step 6.3 Record: no related stable fix for this exact doc update found
by local stable branch ancestry checks or web search.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is cgroup-v1 memcg documentation.
Criticality: peripheral/runtime-none; important only for documentation
correctness.

Step 7.2 Record: cgroup and memcg areas are active; recent
`origin/master` history includes multiple cgroup/mm fixes. The candidate
was applied by the cgroup maintainer.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected population is documentation readers and
developers/admins consulting old cgroup-v1 memcg internals. No kernel
runtime users are affected.

Step 8.2 Record: trigger condition is reading or relying on the stale
documentation. Unprivileged users cannot trigger a kernel failure
because there is no runtime behavior.

Step 8.3 Record: failure mode is incorrect documentation. Severity: LOW.
It can mislead developers/admins, but it does not fix crash, corruption,
leak, deadlock, or security behavior.

Step 8.4 Record: benefit is low but real for documentation correctness,
especially because the stable rules exception allows
documentation/comment fixes and runtime risk is zero. Risk is very low
for branches whose code matches the new text; risk is documentation-
regression risk if applied to a branch like `6.12.y` where cancellation
APIs still exist.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: tiny docs-only patch;
corrects verified stale references in current `7.0.y` and `6.19.y`;
applied by cgroup maintainer; no runtime regression risk; documentation
fixes are allowed. Evidence against: no runtime bug or user-visible
stability issue; not correct for every stable branch, specifically
verified `6.12.y` still has the old commit/cancel APIs. Unresolved: I
did not exhaustively validate every maintained stable branch’s memcg API
state.

Step 9.2 Stable rules checklist:
1. Obviously correct and tested? Yes for matching-code branches;
   verified by code grep, `git diff --check`, and `git apply --check` on
   `7.0.y`.
2. Fixes a real bug that affects users? It fixes incorrect
   documentation, not runtime behavior.
3. Important issue? No runtime severity; LOW documentation correctness
   issue.
4. Small and contained? Yes, 6-line docs-only diff in one file.
5. No new features or APIs? Yes.
6. Can apply to stable trees? Yes to at least current `7.0.y`; should
   not be applied blindly to `6.12.y`.

Step 9.3 Record: exception category is documentation fix.

Step 9.4 Decision: backport is acceptable for stable trees whose memcg
implementation no longer has charge cancellation APIs. It should be
excluded from trees like `6.12.y` where the old APIs still exist. With
that branch-selection caveat, this qualifies under the documentation-fix
exception.

Verification:
- [Phase 1] Parsed candidate commit
  `d8769544bde51b0ac980d10f8fe9f9fed6c95995`: only two Signed-off-by
  tags, no bug/report/stable tags.
- [Phase 2] `git show --stat --patch`: confirmed one docs file, `2
  insertions(+), 4 deletions(-)`.
- [Phase 3] `git show 1d8f136a421f...`: confirmed referenced commit
  removed `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`
  from mainline code.
- [Phase 3] `git log origin/master --grep`: found candidate and merge
  via `cgroup-for-7.1-rc2-fixes`.
- [Phase 4] `b4 dig`: found lore thread and exact patch-id match.
- [Phase 4] `b4 dig -a`: only v1 single-patch series.
- [Phase 4] `b4 dig -w`: relevant cgroup and docs maintainers/lists were
  included.
- [Phase 4] Saved mbox: confirmed Tejun replied “Applied to
  cgroup/for-7.1-fixes”; no NAKs or stable nomination found.
- [Phase 5] `rg`/`git grep`: confirmed current code uses
  `commit_charge()` and no longer has old API names in `7.0.y`.
- [Phase 6] `git apply --check`: candidate applies cleanly to current
  `7.0.y`.
- [Phase 6] Branch checks: `6.12.y` still has
  `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, so this
  patch must not be applied there unchanged.
- [Phase 8] Runtime impact verified as none because only
  `Documentation/admin-guide/cgroup-v1/memcg_test.rst` changes.

**YES**

 Documentation/admin-guide/cgroup-v1/memcg_test.rst | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
index 9f8e27355cba5..7c7cd457cf695 100644
--- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst
+++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
@@ -47,21 +47,19 @@ Please note that implementation details can be changed.
 	  Called when swp_entry's refcnt goes down to 0. A charge against swap
 	  disappears.
 
-3. charge-commit-cancel
+3. charge-commit
 =======================
 
 	Memcg pages are charged in two steps:
 
 		- mem_cgroup_try_charge()
-		- mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
+		- commit_charge()
 
 	At try_charge(), there are no flags to say "this page is charged".
 	at this point, usage += PAGE_SIZE.
 
 	At commit(), the page is associated with the memcg.
 
-	At cancel(), simply usage -= PAGE_SIZE.
-
 Under below explanation, we assume CONFIG_SWAP=y.
 
 4. Anonymous
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] drm/panel: feiyang-fy07024di26a30d: return display-on error

[Sasha Levin]

From: Christian Van <cvan20191@gmail.com>

[ Upstream commit c67e8787f6743101c90c7a9c4bb7cf6f1f739f83 ]

mipi_dsi_dcs_set_display_on() returns an error code, but feiyang_enable()
currently ignores it and always reports success.

Return the DCS command result so callers can observe enable failures.

Signed-off-by: Christian Van <cvan20191@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `drm/panel`, action verb `return`, summary:
`feiyang-fy07024di26a30d` should propagate the MIPI DSI display-on
command error instead of reporting success.

Step 1.2 Record: tags verified:
- `Signed-off-by: Christian Van <cvan20191@gmail.com>`
- `Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>`
- `Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>`
- `Link:
  https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Cc: stable`, syzbot, or
sanitizer tags were present.

Step 1.3 Record: the body says `mipi_dsi_dcs_set_display_on()` returns
an error but `feiyang_enable()` ignores it and always returns success.
Verified in `drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c`.
Symptom: DRM panel core cannot observe a failed display-on command and
may continue the enable sequence as if the panel enabled successfully.
No user report, stack trace, or affected-version statement was found.

Step 1.4 Record: yes, this is a hidden bug fix: it fixes ignored error
handling in a panel enable path. It is not cleanup or refactoring.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed, `drivers/gpu/drm/panel/panel-feiyang-
fy07024di26a30d.c`; 1 insertion, 3 deletions. Modified function:
`feiyang_enable()`. Scope: single-file surgical driver fix.

Step 2.2 Record: before, `feiyang_enable()` called
`mipi_dsi_dcs_set_display_on(ctx->dsi)` and always returned `0`. After,
it returns the DCS command result directly. Affected path: normal panel
enable path, after the 200 ms enable delay.

Step 2.3 Record: bug category is logic/error-propagation correctness.
The broken mechanism was an ignored negative return from
`mipi_dsi_dcs_set_display_on()`. Verified that
`mipi_dsi_dcs_set_display_on()` returns `0` on success or a negative
error code on failure.

Step 2.4 Record: fix quality is high: minimal, obviously correct, no new
API, no locking, no data structure change. Regression risk is very low;
the only behavior change is that a real display-on failure prevents
`drm_panel_enable()` from marking the panel enabled and enabling
backlight/followers.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the ignored return was introduced
with the original driver commit
`69dc678abc2b9d36ff005413ca6e9edabe4c369a` (`drm/panel: Add Feiyang
FY07024DI26A30-D MIPI-DSI LCD panel`), first contained in `v5.2-rc1`.

Step 3.2 Record: no `Fixes:` tag was present, so there was no tag to
follow. I inspected the original driver commit anyway; it added the
driver and already ignored this display-on return.

Step 3.3 Record: recent file history shows mostly unrelated panel API
conversions and cleanup. The candidate patch is standalone and only
needs the existing `feiyang_enable()` and
`mipi_dsi_dcs_set_display_on()` code.

Step 3.4 Record: no other `Christian Van` commits under
`drivers/gpu/drm/panel` were found in checked `master` or `graphics-
next`. Neil Armstrong is listed as DRM panel maintainer in `MAINTAINERS`
and reviewed/applied the patch.

Step 3.5 Record: no dependencies found. The patch applies directly to
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`; `v5.4`
contains the buggy code but needs a trivial context backport.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c c67e8787f6743101c90c7a9c4bb7cf6f1f739f83`
found the original submission at
`https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com`.
`b4 dig -a` found only v1, so the committed version is the only revision
found.

Step 4.2 Record: `b4 dig -w` showed the original recipients included
Christian Van, Jagan Teki, Neil Armstrong, Jessica Zhang, Maarten
Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie, Simona
Vetter, `dri-devel`, and `linux-kernel`. Neil Armstrong reviewed it and
later applied it to `drm-misc-fixes`.

Step 4.3 Record: no `Reported-by` or bug-report link exists. WebFetch
for lore URLs was blocked by Anubis, but `b4 mbox` fetched the thread
successfully. The thread contained Neil’s `Reviewed-by` reply and an
applied notice.

Step 4.4 Record: no multi-patch series found; this is a standalone
1-patch series.

Step 4.5 Record: WebFetch searches of `lore.kernel.org/stable` were
blocked by Anubis. Local pending/stable candidate branches searched did
not show this patch already present.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified function: `feiyang_enable()`.

Step 5.2 Record: `feiyang_enable()` is installed as `.enable` in
`feiyang_funcs`. `drm_panel_enable()` calls
`panel->funcs->enable(panel)` and checks negative returns. Multiple DRM
bridge/host drivers call `drm_panel_enable()`.

Step 5.3 Record: key callees are `msleep(200)` and
`mipi_dsi_dcs_set_display_on(ctx->dsi)`. The latter calls
`mipi_dsi_dcs_write()` and returns a negative error on write failure.

Step 5.4 Record: reachable through DRM panel enable paths during display
modeset/enable for systems using this panel. This is driver/hardware-
specific, not universal. No in-tree DTS user of
`feiyang,fy07024di26a30d` was found beyond the binding example and
driver match table.

Step 5.5 Record: many other panel drivers already check and return or
handle `mipi_dsi_dcs_set_display_on()` errors, confirming this driver
was an outlier.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: buggy code exists in `v5.4`, `v5.10`, `v5.15`, `v6.1`,
`v6.6`, `v6.12`, `v6.19`, and `v7.0`. The driver was introduced for
`v5.2-rc1`, so all active stable trees at or after that point likely
contain it.

Step 6.2 Record: expected backport difficulty is clean for `v5.10+`
based on apply checks. `v5.4` failed direct apply due to context drift
but contains the same ignored call and should need only a trivial one-
function backport.

Step 6.3 Record: no related stable-side fix for this same issue was
found in the checked stable/pending branches.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is DRM panel driver, criticality
`PERIPHERAL`/driver-specific. It affects users of Feiyang
FY07024DI26A30-D MIPI-DSI panels.

Step 7.2 Record: DRM panel is maintained and active. The file has had
several API-conversion commits since introduction, but this fix is not
dependent on those conversions for `v5.10+`.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected population is driver-specific/config-specific:
kernels with `CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D` and hardware
described with `feiyang,fy07024di26a30d`.

Step 8.2 Record: trigger is a failure of the DSI `SET_DISPLAY_ON`
command during panel enable. I did not verify a specific real-world
reporter, so frequency is unverified. It is not shown to be
unprivileged-user-triggerable.

Step 8.3 Record: failure mode is user-visible display enable
misreporting: before the patch, the panel core could treat the panel as
enabled despite the failed display-on command. Severity: `MEDIUM` for
affected hardware, because it can leave display/backlight state wrong,
but no crash, memory corruption, deadlock, or security issue was
verified.

Step 8.4 Record: benefit is moderate for affected hardware; risk is very
low because the patch only returns an existing error code from a
function that already has an `int` return type.

## Phase 9: Final Synthesis
Step 9.1 Record:
Evidence for backporting: real ignored-error bug; affects display enable
correctness; original buggy code dates to `v5.2-rc1`; one-line surgical
fix; maintainer reviewed/applied to `drm-misc-fixes`; clean apply to
`v5.10+`; no new API or feature.
Evidence against backporting: no user report, crash, security issue,
data corruption, syzbot report, or `Fixes:` tag; affected population is
limited to one panel driver; `v5.4` needs a trivial manual backport.
Unresolved: actual field frequency of DSI display-on failures was not
verified.

Step 9.2 Record:
1. Obviously correct and tested? Correct by inspection; reviewed by DRM
   panel maintainer. No explicit `Tested-by`.
2. Fixes a real bug? Yes, ignored negative return from a hardware
   command.
3. Important issue? Moderate: display enable state correctness for
   affected hardware, not a critical kernel-wide failure.
4. Small and contained? Yes, one function, one file, 1 insertion/3
   deletions.
5. No new features/APIs? Yes.
6. Can apply to stable? Yes for `v5.10+`; trivial backport needed for
   `v5.4`.

Step 9.3 Record: no automatic exception category applies; this is not a
device ID, quirk, DT, build, or documentation patch.

Step 9.4 Record: I recommend backporting. Although the impact is driver-
specific and not a crash-class bug, the fix is a genuine hardware enable
error propagation fix, very small, maintainer-reviewed, and low risk.
Stable users with this panel should not have the panel core mark the
panel enabled after the display-on command failed.

## Verification
- Phase 1: Parsed commit `c67e8787f6743101c90c7a9c4bb7cf6f1f739f83` with
  `git show`; confirmed subject, body, trailers, and diff.
- Phase 2: Read `panel-feiyang-fy07024di26a30d.c`; confirmed old
  `feiyang_enable()` ignored `mipi_dsi_dcs_set_display_on()` and
  returned `0`.
- Phase 2: Read `drm_mipi_dsi.c`; confirmed
  `mipi_dsi_dcs_set_display_on()` returns a negative error on failure.
- Phase 3: Ran `git blame -L 94,104`; confirmed buggy lines came from
  `69dc678abc2b9d`.
- Phase 3: Ran `git describe --contains 69dc678abc2b9d`; confirmed first
  containing version `v5.2-rc1`.
- Phase 3: Inspected original commit `69dc678abc2b9d`; confirmed the
  ignored return existed from driver introduction.
- Phase 4: Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; confirmed one
  v1 patch, original lore URL, and recipient list.
- Phase 4: Ran `b4 mbox`; confirmed Neil Armstrong reviewed and applied
  it to `drm-misc-fixes`.
- Phase 4: WebFetch lore and stable searches were blocked by Anubis;
  this limitation did not drive the final decision.
- Phase 5: Read `drm_panel.c`; confirmed `drm_panel_enable()` checks
  negative `.enable` return and skips enabled/backlight/follower path on
  failure.
- Phase 5: Searched for `feiyang_enable`; confirmed it is used via
  `.enable = feiyang_enable`.
- Phase 5: Searched panel drivers for `mipi_dsi_dcs_set_display_on()`;
  confirmed many peers handle its return.
- Phase 6: Used `git grep` against stable tags; confirmed the ignored
  call exists in `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.19`, and
  `v7.0`.
- Phase 6: Apply-checked the patch in detached worktrees; clean for
  `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`; failed
  direct apply on `v5.4` due to context only.
- Phase 7: Checked `MAINTAINERS`; confirmed Neil Armstrong maintains DRM
  panel drivers.
- Phase 8: Checked Kconfig and compatible strings; confirmed impact is
  limited to the Feiyang panel driver/config and no in-tree board DTS
  use was found.
- UNVERIFIED: no actual user report or frequency of display-on command
  failures was found.

**YES**

 drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 4f8d6d8c07e4d..dbdb7e3cb7b62 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -98,9 +98,7 @@ static int feiyang_enable(struct drm_panel *panel)
 	/* T12 (video & logic signal rise + backlight rise) T12 >= 200ms */
 	msleep(200);
 
-	mipi_dsi_dcs_set_display_on(ctx->dsi);
-
-	return 0;
+	return mipi_dsi_dcs_set_display_on(ctx->dsi);
 }
 
 static int feiyang_disable(struct drm_panel *panel)
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] ALSA: usb-audio: Add iface reset and delay quirk for TTGK Technology USB-C Audio

[Sasha Levin]

From: Lianqin Hu <hulianqin@vivo.com>

[ Upstream commit 2149c011510cbdcf183a13b26756e4a02071f0f2 ]

Setting up the interface when suspended/resumeing fail on this card.
Adding a reset and delay quirk will eliminate this problem.

usb 1-1: new full-speed USB device number 2 using xhci-hcd
usb 1-1: New USB device found, idVendor=3302, idProduct=17c2
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: USB-C Audio
usb 1-1: Manufacturer: TTGK Technology
usb 1-1: SerialNumber: 170120210706

Signed-off-by: Lianqin Hu <hulianqin@vivo.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/TYUPR06MB621720E4E8F99A42E162FD51D23D2@TYUPR06MB6217.apcprd06.prod.outlook.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record: Subsystem is `ALSA: usb-audio`; action verb is `Add`; intent is
adding an interface reset plus interface delay quirk for TTGK Technology
USB-C Audio `3302:17c2`.

Record: Tags present in the provided commit/message: `Signed-off-by:
Lianqin Hu <hulianqin@vivo.com>`, `Signed-off-by: Takashi Iwai
<tiwai@suse.de>`, `Link: https://patch.msgid.link/TYUPR06MB621720E4E8F99
A42E162FD51D23D2@TYUPR06MB6217.apcprd06.prod.outlook.com`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Cc: stable`.

Record: Commit body describes a real device-specific failure: interface
setup fails when the card is suspended/resumed. The included USB
enumeration log verifies the target device ID `3302:17c2`, product
`USB-C Audio`, manufacturer `TTGK Technology`.

Record: This is not a hidden cleanup fix; it is an explicit hardware
workaround/quirk for a suspend/resume interface setup failure.

## Phase 2: Diff Analysis
Record: One file changed: `sound/usb/quirks.c`, 2 insertions. Modified
area: `quirk_flags_table[]`. Scope: single-file surgical hardware quirk.

Record: Before: device `3302:17c2` had no built-in quirk flags. After:
it gets `QUIRK_FLAG_FORCE_IFACE_RESET | QUIRK_FLAG_IFACE_DELAY`.

Record: Bug category is hardware workaround. Verified semantics:
`QUIRK_FLAG_IFACE_DELAY` adds 50 ms after `usb_set_interface()` in
`endpoint_set_interface()`, and `QUIRK_FLAG_FORCE_IFACE_RESET` marks
playback endpoints for re-prepare/interface setup after stop/restart.

Record: Fix quality is high: exact VID/PID match, existing flag
mechanisms, no new API, no broad behavior change. Regression risk is
very low and limited to this USB device ID.

## Phase 3: Git History Investigation
Record: `git blame` around the insertion area shows the quirk table is
established and contains many adjacent hardware-specific entries; nearby
entries are from existing ALSA USB-audio quirk commits.

Record: No `Fixes:` tag, so no introducing commit to follow.

Record: Recent file history shows many similar stable-style quirks,
including `ALSA: usb-audio: Add iface reset and delay quirk for AB17X
USB Audio`, `SPACETOUCH USB Audio`, `AB13X USB Audio`, and `GHW-123P`.

Record: Author history under `sound/usb` shows Lianqin Hu has submitted
multiple similar USB-audio delay/reset quirk patches.

Record: Dependency check: `QUIRK_FLAG_IFACE_DELAY` exists since
v5.15-era code, but `QUIRK_FLAG_FORCE_IFACE_RESET` appears from
v6.2-rc1. Therefore v6.6+ style trees have the required infrastructure;
v6.1/v5.15 do not have the reset flag without additional
prerequisite/adaptation.

## Phase 4: Mailing List And External Research
Record: No local commit hash was found on `master`, `sound-next`, or
`all-next`, so `b4 dig -c <commit>` could not be used. I used the
provided `Link:` with `b4 am`/`b4 mbox`.

Record: `b4 am` found one patch and a two-message thread. `b4 am -c`
checked for newer revisions and did not report a newer version.

Record: Full thread shows Takashi Iwai replied: “Applied now. Thanks.”
No objections, NAKs, or risk concerns were present in the fetched
thread.

Record: Original recipients included ALSA maintainers/lists: Jaroslav
Kysela, Takashi Iwai, `linux-sound@vger.kernel.org`, and `linux-
kernel@vger.kernel.org`.

Record: Stable-specific web search did not find usable stable-list
discussion; lore web pages were blocked by Anubis, and search results
did not reveal a stable objection.

## Phase 5: Code Semantic Analysis
Record: Key affected function/data is `quirk_flags_table[]`; consumers
are `snd_usb_init_quirk_flags_table()`, `endpoint_set_interface()`,
`snd_usb_endpoint_stop()`, and `snd_usb_endpoint_prepare()`.

Record: Callers: `usb_audio_probe()` creates the USB audio card, calls
`snd_usb_audio_create()`, which initializes quirk flags from the built-
in table. PCM prepare paths call `snd_usb_endpoint_prepare()`, and PCM
stop paths call `snd_usb_endpoint_stop()`.

Record: Callees/effects: `endpoint_set_interface()` calls
`usb_set_interface()` and then delays if `QUIRK_FLAG_IFACE_DELAY` is
set. `snd_usb_endpoint_stop()` sets `need_prepare`/`need_setup` for
playback endpoints if `QUIRK_FLAG_FORCE_IFACE_RESET` is set.

Record: Reachability is verified through USB device probe and normal
ALSA PCM suspend/resume/stream restart paths for this hardware.

Record: Similar patterns exist in the same table for several devices
using the same two flags, so this follows established local practice.

## Phase 6: Stable Tree Analysis
Record: The generic USB-audio quirk table exists in v5.15, v6.1, v6.6,
v6.12, and v7.0 tags checked.

Record: Required reset-flag infrastructure exists in v6.6, v6.12, and
v7.0; it is absent in v6.1/v5.15 tags checked.

Record: Textual `git apply --check` failed on v6.6, v6.12, v6.1, and
current 7.0 checkout because nearby table context differs. `git apply
--check --3way` on current 7.0 succeeded cleanly; representative
release-tag worktrees reported conflicts with three-way check, so older
backports need minor context adjustment.

Record: No related `TTGK` or `3302:17c2` entry exists locally under
`sound/usb`.

## Phase 7: Subsystem Context
Record: Subsystem is ALSA USB audio, an important driver subsystem for
USB audio peripherals.

Record: Activity level is high: recent history in `sound/usb/quirks.c`
contains multiple hardware quirk additions and USB-audio behavior fixes.

## Phase 8: Impact And Risk
Record: Affected users are owners of TTGK Technology USB-C Audio device
`3302:17c2`.

Record: Trigger condition is using this device across suspend/resume or
stream restart/interface setup paths. The commit message explicitly
reports interface setup failure in that scenario.

Record: Failure mode is device malfunction after suspend/resume, not a
kernel crash. Severity is medium for the kernel generally but high for
affected hardware users because audio can fail after power-management
transitions.

Record: Benefit is high for affected hardware and low-risk for everyone
else. Risk is very low because the change is an exact VID/PID quirk
using existing flags.

## Phase 9: Final Synthesis
Record: Evidence for backporting: real hardware failure, exact device
ID, standard quirk exception category, two-line contained patch,
existing flag behavior, maintainer applied it, no API/feature expansion
beyond a device-specific workaround.

Record: Evidence against: no external bug report or Tested-by tag found;
exact mail patch needs context adjustment for stable trees; v6.1/v5.15
lack `QUIRK_FLAG_FORCE_IFACE_RESET`, so those trees would need a
deliberate adaptation or prerequisite decision.

Record: Stable rules: obviously correct: yes; fixes a real user-visible
hardware bug: yes; important enough for affected users: yes; small and
contained: yes; no new API/feature: yes; applies cleanly: not textually
everywhere, but trivial/minor for v6.6+ style trees.

Record: Exception category: hardware quirk/workaround for a broken USB
audio device. This is a standard stable-acceptable category.

## Verification
- [Phase 1] Parsed provided subject, tags, commit body, and USB
  enumeration log.
- [Phase 2] Verified diff is two inserted lines in `sound/usb/quirks.c`.
- [Phase 2/5] Verified `QUIRK_FLAG_IFACE_DELAY` and
  `QUIRK_FLAG_FORCE_IFACE_RESET` definitions and consumers in
  `sound/usb/usbaudio.h` and `sound/usb/endpoint.c`.
- [Phase 3] Ran `git blame` around the table insertion area and recent
  `git log` for `sound/usb/quirks.c`.
- [Phase 3] Verified similar reset/delay quirk commits and Lianqin Hu’s
  related ALSA USB-audio quirk history.
- [Phase 4] `b4 am` fetched the patch from the provided message-id link;
  `b4 mbox` fetched the two-message thread.
- [Phase 4] Verified Takashi Iwai’s maintainer reply: “Applied now.
  Thanks.”
- [Phase 4] `b4 am -c` did not report newer revisions.
- [Phase 5] Traced quirk flag initialization from `usb_audio_probe()` to
  `snd_usb_audio_create()` to `snd_usb_init_quirk_flags_table()`.
- [Phase 6] Checked v5.15, v6.1, v6.6, v6.12, and v7.0 tag contents for
  flag availability.
- [Phase 6] Verified `FORCE_IFACE_RESET` absent in v6.1/v5.15 and
  present in v6.6+.
- [Phase 6] Verified plain apply fails due context; current 7.0 three-
  way apply check succeeds without modifying the worktree.
- UNVERIFIED: exact upstream commit SHA, because the commit was not
  present on checked local branches and web search did not find it.

This should be backported to stable trees that already contain the
quirk-flag infrastructure, especially v6.6+ style trees. For older
v6.1/v5.15 trees, it should not be applied verbatim unless maintainers
choose a small adapted backport or also carry the reset-flag
infrastructure.

**YES**

 sound/usb/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 2ffc69b57ab49..1428a0b620d37 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2417,6 +2417,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_IGNORE_CTL_ERROR),
 	DEVICE_FLG(0x3255, 0x0000, /* Luxman D-10X */
 		   QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY),
+	DEVICE_FLG(0x3302, 0x17c2, /* TTGK Technology USB-C Audio */
+		   QUIRK_FLAG_FORCE_IFACE_RESET | QUIRK_FLAG_IFACE_DELAY),
 	DEVICE_FLG(0x339b, 0x3a07, /* Synaptics HONOR USB-C HEADSET */
 		   QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE),
 	DEVICE_FLG(0x413c, 0xa506, /* Dell AE515 sound bar */
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] selftests/cgroup: Fix cg_read_strcmp() empty string comparison

[Sasha Levin]

From: Hongfu Li <lihongfu@kylinos.cn>

[ Upstream commit e32e6f02168f2ad7991eb5d160d312d2001520c8 ]

cg_read_strcmp() allocated a buffer sized to strlen(expected) + 1,
then passed it to read_text() which calls read(fd, buf, size-1).

When comparing against an empty string (""), strlen("") = 0 gives a
1-byte buffer, and read() is asked to read 0 bytes.  The file content
is never actually read, so strcmp("", buf) always returns 0 regardless
of the real content.  This caused cg_test_proc_killed() to always
report the cgroup as empty immediately, making OOM tests pass without
verifying that processes were killed.

Signed-off-by: Hongfu Li <lihongfu@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

Step 1.1 Record: Subsystem `selftests/cgroup`; action verb `Fix`; intent
is to correct empty-string comparison in `cg_read_strcmp()`.

Step 1.2 Record: Tags present are:
- `Signed-off-by: Hongfu Li <lihongfu@kylinos.cn>`
- `Signed-off-by: Tejun Heo <tj@kernel.org>`

No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable@vger.kernel.org` tags are present.

Step 1.3 Record: The commit describes a concrete selftest bug: for
expected `""`, `strlen(expected) + 1` allocates one byte, and
`read_text()` calls `read(fd, buf, size - 1)`, so zero bytes are read.
The symptom is false success: `cg_test_proc_killed()` can report a
cgroup as empty immediately, so OOM tests can pass without verifying
process death.

Step 1.4 Record: This is a direct bug fix, not hidden cleanup. It fixes
incorrect test validation logic.

## Phase 2: Diff Analysis

Step 2.1 Record: One file changed:
`tools/testing/selftests/cgroup/lib/cgroup_util.c`, with 3 insertions
and 2 deletions. Modified function: `cg_read_strcmp()`. Scope: single-
file surgical selftest helper fix.

Step 2.2 Record: Before, non-NULL `expected` always used
`strlen(expected) + 1`; for `""`, that meant `size == 1` and `cg_read()`
read zero bytes. After, empty expected strings use `size == 2`, allowing
one byte to be read so non-empty file contents are detected.

Step 2.3 Record: Bug category is logic/correctness in a userspace
selftest helper. No kernel runtime locking, refcounting, memory safety,
or API behavior changes.

Step 2.4 Record: The fix is obviously correct for the described case:
empty file still compares equal, non-empty file no longer compares equal
after reading at least one byte. Regression risk is very low and limited
to cgroup selftests.

## Phase 3: Git History Investigation

Step 3.1 Record: Blame shows `cg_read_strcmp()` came from `84092dbcf901`
in v4.18-rc1, and the `size = strlen(expected) + 1` logic was last
touched by `48c2bb0b9cf86` in v4.19-rc5. The bug has therefore existed
across many stable releases.

Step 3.2 Record: No `Fixes:` tag is present. I inspected related commits
anyway: `84092dbcf901` introduced the selftest utility, `48c2bb0b9cf86`
tried to fix `cg_read_strcmp()` but still checked `!expected` rather
than empty `expected`, and `d830020656c5b` changed the NULL case to
return `-1`.

Step 3.3 Record: Recent related history includes `6680c162b4850` adding
`cg_read_strcmp_wait()` and `2c754a84ff16a` moving the utility into
`lib/`. No functional prerequisite for this fix was identified.

Step 3.4 Record: No prior Hongfu Li commits under
`tools/testing/selftests/cgroup` were found. The commit was applied by
Tejun Heo, who is listed as a cgroup maintainer in `MAINTAINERS`.

Step 3.5 Record: No dependent code changes are required for the logic
itself. Older stable trees before the selftest library move need a path-
only backport adjustment.

## Phase 4: Mailing List And External Research

Step 4.1 Record: `b4 dig -c e32e6f02168f2...` found the original
submission at
`https://patch.msgid.link/20260509080328.632007-1-lihongfu@kylinos.cn`.
`b4 dig -a` found only v1. The saved mbox shows Tejun replied: “Applied
to cgroup/for-7.1-fixes.” No NAKs or concerns were present in the
fetched thread.

Step 4.2 Record: `b4 dig -w` showed the patch was sent to Tejun Heo,
Johannes Weiner, Michal Koutný, Shuah Khan, cgroups, linux-kselftest,
and linux-kernel, so the right maintainers/lists were included.

Step 4.3 Record: No separate bug report, syzbot report, or bugzilla link
was present.

Step 4.4 Record: No multi-patch series or related required patches were
found; this is standalone.

Step 4.5 Record: Lore WebFetch was blocked by Anubis for stable search.
WebSearch did not find stable-specific discussion for this exact 2026
commit.

## Phase 5: Code Semantic Analysis

Step 5.1 Record: Modified function: `cg_read_strcmp()`.

Step 5.2 Record: Callers found include `cg_read_strcmp_wait()`,
`test_memcontrol.c`, `test_core.c`, `test_kill.c`, `test_pids.c`, and
`test_zswap.c`. Empty-string `cgroup.procs` checks are in
`test_memcontrol.c`.

Step 5.3 Record: The relevant callees are `malloc()`, `cg_read()`,
`read_text()`, `read()`, `strcmp()`, and `free()`.

Step 5.4 Record: Verified call chain: `test_memcontrol` main test loop
-> OOM tests such as `test_memcg_oom_events()` / `cg_test_proc_killed()`
-> `cg_read_strcmp()` -> `cg_read()` -> `read_text()`. This is reachable
by running cgroup kselftests, not by normal kernel runtime use.

Step 5.5 Record: Similar affected pattern exists in stable branches
where `cg_read_strcmp(..., "cgroup.procs", "")` is used and the helper
still has `size = strlen(expected) + 1`.

## Phase 6: Stable Tree Analysis

Step 6.1 Record: I verified the buggy helper and affected empty
`cgroup.procs` checks exist in `stable/linux-5.4.y`, `5.10.y`, `5.15.y`,
`6.1.y`, `6.6.y`, `6.12.y`, `6.17.y`, `6.18.y`, `6.19.y`, and `7.0.y`.

Step 6.2 Record: The patch applies cleanly to current
`stable/linux-7.0.y` with `git apply --check`. Branches using
`tools/testing/selftests/cgroup/cgroup_util.c` instead of
`lib/cgroup_util.c` need a trivial path adjustment.

Step 6.3 Record: Related older fixes are present, but no checked stable
branch contained the candidate’s `expected[0] == '\0'` fix.

## Phase 7: Subsystem Context

Step 7.1 Record: Subsystem is cgroup selftests. Runtime criticality is
peripheral, but test criticality is meaningful for memcg/cgroup
validation.

Step 7.2 Record: The subsystem is active; recent stable history includes
multiple cgroup selftest fixes, and `MAINTAINERS` lists
`tools/testing/selftests/cgroup/` under maintained cgroup ownership.

## Phase 8: Impact And Risk

Step 8.1 Record: Affected users are kernel developers, distributions, CI
systems, and stable maintainers running cgroup kselftests.

Step 8.2 Record: Trigger is running affected cgroup OOM selftests that
compare `cgroup.procs` with `""`. This is not an unprivileged runtime
kernel trigger.

Step 8.3 Record: Failure mode is false PASS / missed test validation,
not a kernel crash or data corruption. Severity: MEDIUM for stable
validation quality.

Step 8.4 Record: Benefit is medium because it prevents false success in
OOM-related stable testing. Risk is very low because the change is tiny,
userspace-only, and does not affect kernel runtime behavior.

## Phase 9: Final Synthesis

Evidence for backporting: fixes a real, verified selftest correctness
bug; bug exists in many stable trees; affects OOM/memcg validation;
patch is tiny and obvious; reviewed/applied by the cgroup maintainer; no
runtime regression risk.

Evidence against backporting: it does not fix a production kernel
crash/security/data-corruption bug directly, only test correctness.

Stable rules checklist:
1. Obviously correct and tested by review? Yes, obviously correct by
   code inspection; no explicit `Tested-by`.
2. Fixes a real bug? Yes, false empty-string comparison in selftests.
3. Important issue? Medium: prevents false PASS in OOM selftests, not
   runtime-critical.
4. Small and contained? Yes, 5-line single-function change.
5. No new features/APIs? Yes.
6. Can apply to stable? Yes for 7.0 cleanly; older branches need trivial
   path adjustment.

Exception category: Not a device ID, quirk, DT, build, or documentation
fix. It is a selftest correctness fix.

## Verification

- Phase 1: `git show e32e6f02168f2...` verified subject, body, tags,
  author, committer, and no `Fixes:`/stable tags.
- Phase 2: `git show --patch` verified the 3 insertion / 2 deletion
  change in `cg_read_strcmp()`.
- Phase 3: `git blame -L 99,123 e32e6f^ --
  tools/testing/selftests/cgroup/lib/cgroup_util.c` verified line
  history.
- Phase 3: `git show 84092dbcf901`, `git show 48c2bb0b9cf86`, and `git
  show d830020656c5b` verified related history.
- Phase 4: `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and saved mbox
  verified lore URL, v1-only series, recipients, and Tejun’s applied
  reply.
- Phase 5: `rg "cg_read_strcmp\\(" tools/testing/selftests/cgroup` and
  file reads verified callers and empty-string uses.
- Phase 6: Python checks against stable branches verified buggy code and
  affected tests in listed stable trees.
- Phase 6: `git diff e32e6f^ e32e6f | git apply --check` verified clean
  application to `stable/linux-7.0.y`.
- Phase 7: `rg` in `MAINTAINERS` verified cgroup maintainers and
  selftest path ownership.
- Phase 8: Impact classification is based on verified file path under
  `tools/testing/selftests`, verified test call chain, and no kernel
  runtime files changed.
- UNVERIFIED: I did not run the cgroup selftests, and Lore WebFetch was
  blocked by Anubis for direct stable archive browsing.

**YES**

 tools/testing/selftests/cgroup/lib/cgroup_util.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/cgroup/lib/cgroup_util.c b/tools/testing/selftests/cgroup/lib/cgroup_util.c
index 6a7295347e90b..42f54936f4bbd 100644
--- a/tools/testing/selftests/cgroup/lib/cgroup_util.c
+++ b/tools/testing/selftests/cgroup/lib/cgroup_util.c
@@ -106,8 +106,9 @@ int cg_read_strcmp(const char *cgroup, const char *control,
 	/* Handle the case of comparing against empty string */
 	if (!expected)
 		return -1;
-	else
-		size = strlen(expected) + 1;
+
+	/* needs size > 1, otherwise cg_read() reads 0 bytes */
+	size = (expected[0] == '\0') ? 2 : strlen(expected) + 1;
 
 	buf = malloc(size);
 	if (!buf)
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] smb: client: Zero-pad short GSS session keys per MS-SMB2

[Sasha Levin]

From: Piyush Sachdeva <s.piyush1024@gmail.com>

[ Upstream commit 8cb6fc3231500233ddaf63cb7fd5435008d9ed5f ]

Per MS-SMB2 section 3.2.5.3, Session.SessionKey is the first 16 bytes
of the GSS cryptographic key, right-padded with zero bytes if the key
is shorter than 16 bytes.

SMB2_auth_kerberos() copies the GSS session key from the cifs.upcall
response using kmemdup(msg->data, msg->sesskey_len, ...) and stores
the GSS-reported length verbatim in ses->auth_key.len. generate_key()
reads SMB2_NTLMV2_SESSKEY_SIZE bytes from this buffer when feeding the
HMAC-SHA256 KDF for signing key derivation. If a GSS mechanism returns
a session key shorter than 16 bytes (e.g. a deprecated single-DES
Kerberos enctype with an 8-byte session key), the KDF call performs an
out-of-bounds slab read and derives keys that do not match the server,
which pads per the spec.

Modern KDCs disable short-key enctypes by default, so this is latent
rather than reachable in production, but it is still a kernel heap
over-read.

Allocate auth_key.response with kzalloc() at a length of
max(msg->sesskey_len, SMB2_NTLMV2_SESSKEY_SIZE), copy the GSS key in,
and rely on kzalloc()'s zero initialization for the spec-mandated
padding. Set ses->auth_key.len to the padded length. Larger GSS keys
(e.g. the 32-byte aes256-cts-hmac-sha1-96 session key) continue to be
stored at their natural length, preserving the FullSessionKey path.

Emit a cifs_dbg(VFS, ...) message when a short key is encountered to
surface deprecated-enctype usage.

NTLMv2 and NTLMSSP code paths produce a 16-byte session key by
construction and are unaffected.

Signed-off-by: Piyush Sachdeva <psachdeva@microsoft.com>
Signed-off-by: Piyush Sachdeva <s.piyush1024@gmail.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record 1.1: subsystem `smb: client`; action verb `Zero-pad`; intent is
to make short GSS session keys comply with MS-SMB2 and avoid short-
buffer use in SMB2 key derivation.

Record 1.2: tags present are:
- `Signed-off-by: Piyush Sachdeva <psachdeva@microsoft.com>`
- `Signed-off-by: Piyush Sachdeva <s.piyush1024@gmail.com>`
- `Signed-off-by: Steve French <stfrench@microsoft.com>`

No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable@vger.kernel.org` tag was present in the supplied
commit message.

Record 1.3: the commit describes a real memory-safety bug:
`SMB2_auth_kerberos()` allocates exactly `msg->sesskey_len` bytes, but
SMB2 key derivation later consumes `SMB2_NTLMV2_SESSKEY_SIZE` bytes,
which is `16`. If `msg->sesskey_len < 16`, the kernel reads past the
allocated buffer and also derives a non-spec-compliant key. MS-SMB2 says
`Session.SessionKey` is the first 16 bytes of the cryptographic key,
right-padded with zeros if shorter.

Record 1.4: this is not just cleanup. It is a hidden memory-safety and
protocol-correctness fix: short allocation plus fixed 16-byte HMAC key
input creates an out-of-bounds read.

### Phase 2: Diff Analysis
Record 2.1: one file changed: `fs/smb/client/smb2pdu.c`, one hunk in
`SMB2_auth_kerberos()`, roughly 18 insertions and 5 deletions from the
supplied diff. Scope is a single-file surgical fix.

Record 2.2: before, `ses->auth_key.response = kmemdup(msg->data,
msg->sesskey_len, GFP_KERNEL)` and `ses->auth_key.len =
msg->sesskey_len`. After, the code sets `ses->auth_key.len =
max(msg->sesskey_len, 16)`, allocates a zeroed buffer of that size,
copies only the original GSS key, and leaves zero padding if the key was
short.

Record 2.3: bug category is memory safety / out-of-bounds read plus
protocol correctness. The verified consumer is `generate_key()` in
`fs/smb/client/smb2transport.c`, which calls
`hmac_sha256_init_usingrawkey(&hmac_ctx, ses->auth_key.response,
SMB2_NTLMV2_SESSKEY_SIZE)`. The HMAC helper copies `raw_key_len` bytes
from the pointer, so a shorter allocation is a real over-read.

Record 2.4: fix quality is good: it preserves larger keys, fixes only
Kerberos/GSS key storage, does not change the security blob pointer, and
uses zeroed allocation to implement the spec padding. Regression risk is
low; the only behavior change for short keys is from invalid over-
read/wrong key material to zero-padded spec behavior. It adds one VFS
debug message for short keys.

### Phase 3: Git History Investigation
Record 3.1: `git blame` on current `fs/smb/client/smb2pdu.c` shows the
current `kmemdup(msg->data, msg->sesskey_len)` lines came from
`d9d1e319b39e` (`smb: client: fix broken multichannel with
krb5+signing`), first contained in local tags starting at `v7.0`. The
fixed-size 16-byte HMAC use in current `generate_key()` came from
`4b4c6fdb25de`, first contained in local tags starting at `v6.18`.

Record 3.2: no `Fixes:` tag is present, so there was no tagged
introducing commit to follow.

Record 3.3: recent local history for `smb2pdu.c` includes related
Kerberos/multichannel work (`d9d1e319b39e`). Recent `smb2transport.c`
history includes crypto-library conversion commits. The candidate itself
is standalone for current `v7.0.y` context.

Record 3.4: local `git log master --author='Piyush Sachdeva' -10 --
fs/smb/client fs/cifs` found no matching prior local commits. `Steve
French` is listed in `MAINTAINERS` as maintainer for `COMMON INTERNET
FILE SYSTEM CLIENT (CIFS and SMB3)`, and he signed off this patch.

Record 3.5: no functional dependency was found for the current `v7.0.y`
file: `git apply --check` of the supplied patch against this checkout
succeeded. Older stable trees need path/context adjustments because
older releases use `fs/cifs/` and some have the allocation inside an `if
(!is_binding)` / `if (!ses->binding)` block.

### Phase 4: Mailing List and External Research
Record 4.1: no candidate commit hash was available locally. `git log
master`, `pending-7.0`, and `for-greg/7.0-200` with the exact subject
found no commit. `b4 dig -c '<subject>'`, `b4 dig -a`, and `b4 dig -w`
failed because `b4 dig` needs a commitish.

Record 4.2: reviewer/recipient data could not be obtained from `b4 dig`
for this candidate. The only maintainer signal verified is Steve
French’s signoff and MAINTAINERS entry.

Record 4.3: no `Link:` or `Reported-by:` tags exist. Lore web queries
were blocked by Anubis, so no bug-report thread was verified.

Record 4.4: no series context was verified. No local subject match was
found in searched branches.

Record 4.5: stable-list search via lore was blocked by Anubis; no
stable-specific discussion was verified.

### Phase 5: Code Semantic Analysis
Record 5.1: modified function: `SMB2_auth_kerberos()`.

Record 5.2: caller path verified locally: `connect.c` calls
`server->ops->sess_setup()`, SMB2/SMB3 ops point that to
`SMB2_sess_setup()`, `SMB2_select_sec()` selects `SMB2_auth_kerberos()`
for Kerberos, and `SMB2_sess_setup()` runs the selected auth function.

Record 5.3: key callees are `cifs_get_spnego_key()`,
`SMB2_sess_sendreceive()`, and `SMB2_sess_establish_session()`.
`SMB2_sess_establish_session()` calls
`server->ops->generate_signingkey()`, which reaches
`generate_smb3signingkey()` and then `generate_key()` for SMB3 dialects.

Record 5.4: reachability is from a user-requested CIFS/SMB mount using
Kerberos, with `CONFIG_CIFS_UPCALL` enabled. `Kconfig` says
`CIFS_UPCALL` enables Kerberos/SPNEGO advanced session setup and is used
for Kerberos tickets needed to mount secure servers.

Record 5.5: similar short allocation plus 16-byte consumer patterns
exist across stable tags. I verified the same `kmemdup(msg->data,
msg->sesskey_len)` and 16-byte key use in `v5.4`, `v5.10`, `v5.15`,
`v6.1`, `v6.6`, `v6.12`, `v6.18`, `v6.19`, and `v7.0`, with path changes
from `fs/cifs/` to `fs/smb/client/`.

### Phase 6: Cross-Referencing and Stable Tree Analysis
Record 6.1: buggy code exists in multiple stable-era tags. `v5.4`
through `v6.1` use `fs/cifs/`; `v6.6+` uses `fs/smb/client/`. The
relevant allocation and 16-byte key consumption pattern is present in
those checked tags.

Record 6.2: expected backport difficulty is clean for current `v7.0.y`
because `git apply --check` succeeded. Older stable trees need minor
backporting for path and context differences; pre-`d9d1e319b39e` trees
should preserve their existing binding conditional unless that
multichannel Kerberos fix is also backported.

Record 6.3: local searches for the exact subject, `short GSS session
key`, and related `MS-SMB2` terms did not find an existing local fix.

### Phase 7: Subsystem and Maintainer Context
Record 7.1: subsystem is CIFS/SMB3 client filesystem/network filesystem
code. Criticality is important: it affects users mounting SMB shares
with Kerberos/SPNEGO.

Record 7.2: subsystem is active; recent `master` history under
`fs/smb/client` includes multiple SMB client fixes and refactors. The
maintained subsystem is marked `Supported` in `MAINTAINERS`.

### Phase 8: Impact and Risk Assessment
Record 8.1: affected population is config- and workload-specific:
CIFS/SMB2+ Kerberos users with `CONFIG_CIFS_UPCALL`, especially where
the GSS session key returned to the kernel is shorter than 16 bytes.

Record 8.2: trigger condition is a Kerberos/SPNEGO session setup where
`msg->sesskey_len < SMB2_NTLMV2_SESSKEY_SIZE`. The mount path is user
reachable, but whether unprivileged users can trigger it depends on
mount permissions and local configuration, which I did not verify.

Record 8.3: failure mode is a kernel heap out-of-bounds read during HMAC
key setup and incorrect SMB key derivation. Severity is high for memory
safety, though likely low-frequency because it requires a short GSS
session key.

Record 8.4: benefit is high for affected users because it removes a
kernel heap over-read and implements the protocol-required padding. Risk
is low because the patch is small, local, and preserves behavior for
keys of length 16 or greater.

### Phase 9: Final Synthesis
Record 9.1: evidence for backporting:
- Verified short allocation in `SMB2_auth_kerberos()`.
- Verified fixed 16-byte read in `generate_key()`.
- Verified HMAC helper copies the specified key length.
- Verified MS-SMB2 requires right-zero-padding short session keys.
- Verified bug pattern exists across multiple stable-era tags.
- Fix is small, local, and cleanly applies to current `v7.0.y`.

Evidence against / concerns:
- No `Reported-by`, `Tested-by`, `Reviewed-by`, `Fixes`, or `Link` tag
  was supplied.
- No lore review discussion could be verified.
- Older stable trees need minor path/context backport adjustments.
- Trigger appears specific to short GSS keys; I did not independently
  verify real-world frequency.

Unresolved:
- No upstream commit hash was available locally, so `b4 dig` could not
  retrieve the original thread.
- Lore web searches were blocked.
- I did not compile-test the patch.

Record 9.2 stable rules:
1. Obviously correct and tested: obviously correct by code inspection;
   external testing not verified.
2. Fixes a real bug: yes, verified out-of-bounds read when `sesskey_len
   < 16`.
3. Important issue: yes, kernel heap over-read and broken key
   derivation.
4. Small and contained: yes, one function in one file.
5. No new feature/API: yes, no new API or userspace interface.
6. Can apply to stable: yes for current `v7.0.y`; minor backport work
   needed for older trees.

Record 9.3: no automatic exception category applies. This is not a
device ID, quirk, DT, build, or documentation-only change.

Record 9.4: decision is to backport. The memory-safety fix is small and
technically well justified; the limited trigger scope reduces urgency
but not suitability.

## Verification
- [Phase 1] Parsed the supplied subject and tags; no `Fixes`, `Reported-
  by`, `Tested-by`, `Reviewed-by`, `Link`, or stable Cc was present.
- [Phase 2] Read `SMB2_auth_kerberos()` in `fs/smb/client/smb2pdu.c`;
  verified current exact-size `kmemdup()` allocation and
  `ses->auth_key.len = msg->sesskey_len`.
- [Phase 2] Read `generate_key()` in `fs/smb/client/smb2transport.c`;
  verified it passes `SMB2_NTLMV2_SESSKEY_SIZE` bytes from
  `ses->auth_key.response`.
- [Phase 2] Read `lib/crypto/sha256.c`; verified HMAC raw-key setup
  copies `raw_key_len` bytes from the supplied pointer.
- [Phase 2] Verified `SMB2_NTLMV2_SESSKEY_SIZE` is `16` in
  `fs/smb/common/smb2pdu.h`.
- [Phase 3] `git blame` identified local current-line history for the
  allocation and HMAC key setup.
- [Phase 3] `git show` inspected `d9d1e319b39e` and `4b4c6fdb25de`.
- [Phase 3] `git tag --contains` showed `d9d1e319b39e` starts at local
  `v7.0` tags and `4b4c6fdb25de` at local `v6.18` tags.
- [Phase 4] `b4 dig` attempts by subject failed because no local
  commitish exists; lore WebFetch searches were blocked by Anubis.
- [Phase 5] `rg` and `ReadFile` traced `connect.c -> SMB2_sess_setup()
  -> SMB2_auth_kerberos() -> SMB2_sess_establish_session() ->
  generate_key()`.
- [Phase 6] Checked `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
  `v6.18`, `v6.19`, and `v7.0` for the allocation and 16-byte consumer
  pattern.
- [Phase 6] `git apply --check` confirmed the supplied patch applies
  cleanly to current `v7.0.y`.
- [Phase 7] Verified CIFS/SMB3 client maintainership and supported
  status in `MAINTAINERS`.
- [Phase 8] Verified `CONFIG_CIFS_UPCALL` Kconfig text describes
  Kerberos/SPNEGO upcall support for secure SMB mounts.
- UNVERIFIED: original mailing-list review, patch revisions, explicit
  stable discussion, compile-test results, and real-world frequency of
  short GSS session keys.

**YES**

 fs/smb/client/smb2pdu.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c
index 5188218c25be4..0792e0c38b44f 100644
--- a/fs/smb/client/smb2pdu.c
+++ b/fs/smb/client/smb2pdu.c
@@ -1714,17 +1714,30 @@ SMB2_auth_kerberos(struct SMB2_sess_data *sess_data)
 	is_binding = (ses->ses_status == SES_GOOD);
 	spin_unlock(&ses->ses_lock);
 
+	/*
+	 * Per MS-SMB2 3.2.5.3, Session.SessionKey is the first 16 bytes of the
+	 * GSS cryptographic key, right-padded with zero bytes if shorter.
+	 * Allocate at least SMB2_NTLMV2_SESSKEY_SIZE bytes (zeroed) so the KDF
+	 * input buffer is always valid for HMAC-SHA256 even with deprecated
+	 * Kerberos enctypes that return a short session key.
+	 */
+	if (unlikely(msg->sesskey_len < SMB2_NTLMV2_SESSKEY_SIZE))
+		cifs_dbg(VFS,
+			 "short GSS session key (%u bytes); zero-padding per MS-SMB2 3.2.5.3\n",
+			 msg->sesskey_len);
+
 	kfree_sensitive(ses->auth_key.response);
-	ses->auth_key.response = kmemdup(msg->data,
-					 msg->sesskey_len,
-					 GFP_KERNEL);
+	ses->auth_key.len = max_t(unsigned int, msg->sesskey_len,
+				  SMB2_NTLMV2_SESSKEY_SIZE);
+	ses->auth_key.response = kzalloc(ses->auth_key.len, GFP_KERNEL);
 	if (!ses->auth_key.response) {
 		cifs_dbg(VFS, "%s: can't allocate (%u bytes) memory\n",
-			 __func__, msg->sesskey_len);
+			 __func__, ses->auth_key.len);
+		ses->auth_key.len = 0;
 		rc = -ENOMEM;
 		goto out_put_spnego_key;
 	}
-	ses->auth_key.len = msg->sesskey_len;
+	memcpy(ses->auth_key.response, msg->data, msg->sesskey_len);
 
 	sess_data->iov[1].iov_base = msg->data + msg->sesskey_len;
 	sess_data->iov[1].iov_len = msg->secblob_len;
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] HID: magicmouse: Prevent out-of-bounds (OOB) read during DOUBLE_REPORT_ID

[Sasha Levin]

From: Lee Jones <lee@kernel.org>

[ Upstream commit d93ba918a185aca2594da63e92fdc5495b559c0f ]

It is currently possible for a malicious or misconfigured USB device to
cause an out-of-bounds (OOB) read when submitting reports using
DOUBLE_REPORT_ID by specifying a large report length and providing a
smaller one.

Let's prevent that by comparing the specified report length with the
actual size of the data read in from userspace.  If the actual data
length ends up being smaller than specified, we'll politely warn the
user and prevent any further processing.

Signed-off-by: Lee Jones <lee@kernel.org>
Reviewed-by: Günther Noack <gnoack@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `HID: magicmouse`; action verb `Prevent`;
claimed intent is preventing an out-of-bounds read while parsing
`DOUBLE_REPORT_ID`.

Step 1.2 Record: Tags present: `Signed-off-by: Lee Jones
<lee@kernel.org>`, `Reviewed-by: Günther Noack <gnoack@google.com>`,
`Signed-off-by: Jiri Kosina <jkosina@suse.com>`. No `Fixes:`, `Reported-
by:`, `Tested-by:`, `Link:`, or `Cc: stable@vger.kernel.org` tag was
present in the supplied commit text.

Step 1.3 Record: The body describes a malformed HID report where
`data[1]` advertises a larger embedded report length than the actual
received buffer. Symptom/failure mode: OOB read during recursive
parsing. No affected kernel versions are named. Root cause:
`magicmouse_raw_event()` trusted the embedded length before checking
that the buffer actually contained that many bytes.

Step 1.4 Record: This is not a hidden cleanup; it is an explicit memory-
safety bug fix.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `drivers/hid/hid-magicmouse.c`, 16
insertions, no removals. Modified function: `magicmouse_raw_event()`.
Scope: single-file surgical fix.

Step 2.2 Record: First hunk adds `if (size < 1) return 0;` before
`switch (data[0])`, preventing zero-sized recursive calls from
dereferencing `data[0]`. Second hunk adds `size < 2` before reading
`data[1]`, then validates `size >= data[1] + 2` before splitting the
double report into recursive calls.

Step 2.3 Record: Bug category is memory safety / bounds validation.
Broken mechanism: the `DOUBLE_REPORT_ID` case used `data[1]` to choose
recursive buffer pointers and sizes without proving the first embedded
report existed in the received buffer.

Step 2.4 Record: The fix is obviously correct by inspection: it checks
the exact fields before use and follows existing invalid-report behavior
of returning `0`. Regression risk is very low; only malformed undersized
reports are rejected. Minor concern: the new `hid_warn()` string lacks a
trailing newline, but that is logging style, not functional risk.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows `magicmouse_raw_event()` dates back
to `128537cea464` from 2010, while the `DOUBLE_REPORT_ID` recursive
parsing lines were introduced by `a462230e16acc` (`HID: magicmouse:
enable Magic Trackpad support`). `git describe --contains` places that
introduction at `v2.6.37-rc1~144^2~3^5~2`.

Step 3.2 Record: No `Fixes:` tag is present, so there was no tagged
introducing commit to follow. Blame independently identifies the
relevant old code.

Step 3.3 Record: Recent `drivers/hid/hid-magicmouse.c` history contains
other fixes such as missing input crash prevention and report-fixup leak
fixes, but no prerequisite for this bounds check was identified. This
patch is standalone.

Step 3.4 Record: `git log --author='Lee Jones' -- drivers/hid` shows Lee
Jones has multiple recent HID fixes, including OOB/UAF-related HID work.
The patch was reviewed by Günther Noack and applied by HID maintainer
Jiri Kosina in the mailing-list thread.

Step 3.5 Record: No dependency was found. The patch only uses existing
`hid_warn()` and local variables already present in
`magicmouse_raw_event()`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: No commit hash was supplied and the commit object was
not found in local `git log`, so `b4 dig -c <commit>` was not
applicable. I used `b4 mbox` with the v2 Message-ID instead. Lore URL:
`https://lore.kernel.org/all/20260416131655.2279756-1-lee@kernel.org/`.
Series revisions found: v1 and v2.

Step 4.2 Record: The v2 headers show Lee sent it to Jiri Kosina,
Benjamin Tissoires, `linux-input@vger.kernel.org`, `linux-
kernel@vger.kernel.org`, and Cc’d Günther Noack. Jiri later replied
“Applied”.

Step 4.3 Record: No `Reported-by` or external bug-report link was
present. The thread itself contains the bug explanation.

Step 4.4 Record: v1 added only the `size < data[1] + 2` check. Günther
Noack objected that `size == data[1] + 2` still caused a zero-sized
second recursive call which then dereferenced `data[0]`. v2 added the
top-level `size < 1` and `DOUBLE_REPORT_ID` `size < 2` checks; Günther
replied “This looks correct now” and gave `Reviewed-by`.

Step 4.5 Record: Web search for stable-specific discussion did not find
a stable nomination or a reason not to backport.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `magicmouse_raw_event()`.

Step 5.2 Record: Callers are HID core through the driver `.raw_event`
callback and recursive self-calls in the `DOUBLE_REPORT_ID` case. `hid-
core.c` calls `hdrv->raw_event(hid, report, data, size)` before generic
report processing.

Step 5.3 Record: Key callees in the affected path are recursive
`magicmouse_raw_event()` calls, `magicmouse_emit_touch()`, input event
reporting helpers, and `hid_warn()`. The new checks run before recursive
pointer arithmetic.

Step 5.4 Record: Reachability is verified through `hid_input_report()`,
including `usbhid` interrupt/control paths and `uhid` input paths. A
matched or emulated HID device can feed raw reports to this parser.
Unprivileged triggering was not verified and is not needed for the
decision.

Step 5.5 Record: Search in `drivers/hid` found this `DOUBLE_REPORT_ID`
split pattern only in `hid-magicmouse.c`.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: The vulnerable pattern exists in `v6.6`, `v6.1`,
`v5.15`, `v5.10`, `v5.4`, and `v4.19` by `git grep`. The relevant code
was introduced around `v2.6.37-rc1`.

Step 6.2 Record: Expected backport difficulty is low: the same block and
function exist across checked stable baselines, though line offsets
differ. Exact clean application to every stable branch was not tested.

Step 6.3 Record: Local history searches for `DOUBLE_REPORT_ID` and `out-
of-bounds.*magicmouse` found no prior equivalent fix in this checkout.

## Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is HID input driver support for Apple Magic
Mouse/Trackpad, under `drivers/hid`. Criticality: peripheral/driver-
specific, but memory-safety relevant.

Step 7.2 Record: HID is actively maintained; recent `drivers/hid`
history shows multiple 2026 fixes including OOB, UAF, and NULL-deref
fixes.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems with `CONFIG_HID_MAGICMOUSE`
and matching Apple Magic Trackpad/Magic Mouse style HID devices or
emulated/spoofed devices reaching this driver.

Step 8.2 Record: Trigger requires a malformed `DOUBLE_REPORT_ID` report
where the embedded length does not fit the actual received size, or
where the second recursive call would be zero-sized. This is not a
normal-path trigger, but it is reachable via raw HID reports.

Step 8.3 Record: Failure mode is OOB read in kernel HID parsing.
Severity: HIGH because it is memory safety in a device-input path and
can be triggered by malformed device input; exact crash or disclosure
behavior was not independently reproduced.

Step 8.4 Record: Benefit is high for affected systems because it blocks
a concrete OOB read. Risk is very low: 16 inserted validation lines,
single function, no ABI/API change, no locking change.

## Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: real OOB read, old code
present in many stable baselines, small surgical validation, reviewed
after v1 caught an incomplete fix, applied by HID maintainer. Evidence
against: no `Tested-by`, no explicit stable nomination, exact clean
apply to every tree not tested. Unresolved: exact upstream commit hash
unavailable locally; exact unprivileged triggerability unverified; exact
USB-vs-Bluetooth trigger wording not independently verified.

Step 9.2 Record: Stable rules: obviously correct: yes, by code
inspection and review; tested: no explicit `Tested-by`. Fixes real bug:
yes, OOB read. Important issue: yes, memory safety. Small and contained:
yes, one function, 16 insertions. No new features/APIs: yes. Can apply
to stable: likely low difficulty; exact apply unverified.

Step 9.3 Record: No exception category applies; this is a normal memory-
safety bug fix, not a device ID, quirk, DT, build, or documentation
patch.

Step 9.4 Record: The technical merit strongly favors backporting. The
fix is narrow, old affected code is present across stable trees, and the
mailing-list review specifically corrected the subtle recursive zero-
size case.

## Verification
- Phase 1: Parsed supplied commit message and tags.
- Phase 2: Compared supplied diff with local `drivers/hid/hid-
  magicmouse.c` context.
- Phase 3: Ran `git blame -L 386,496 -- drivers/hid/hid-magicmouse.c`;
  identified `a462230e16acc` as the `DOUBLE_REPORT_ID` recursive parsing
  introduction.
- Phase 3: Ran `git describe --contains --match 'v[0-9]*'
  a462230e16acc`; found `v2.6.37-rc1~144^2~3^5~2`.
- Phase 4: Used `b4 mbox 20260416131655.2279756-1-lee@kernel.org`; found
  v2 thread, reviewer approval, and Jiri’s “Applied” reply.
- Phase 4: Used `b4 mbox ad-S8Riah-f6mEWm@google.com`; found v1 review
  pointing out the remaining zero-sized recursive-call bug.
- Phase 5: Used `rg` and read `hid-core.c`; verified `.raw_event`
  dispatch and `hid_input_report()` reachability.
- Phase 6: Used `git grep` on `v6.6`, `v6.1`, `v5.15`, `v5.10`, `v5.4`,
  and `v4.19`; confirmed vulnerable code exists.
- Phase 7: Checked `drivers/hid/Kconfig`; confirmed
  `CONFIG_HID_MAGICMOUSE`.
- Phase 8: Severity assessment is based on verified OOB read mechanics;
  exact crash/leak manifestation is unverified.
- UNVERIFIED: Exact commit hash in local repository; exact clean apply
  to every stable branch; unprivileged triggerability.

**YES**

 drivers/hid/hid-magicmouse.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index 9eadf3252d0dc..f53839484c861 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -390,6 +390,10 @@ static int magicmouse_raw_event(struct hid_device *hdev,
 	struct input_dev *input = msc->input;
 	int x = 0, y = 0, ii, clicks = 0, npoints;
 
+	/* Protect against zero sized recursive calls from DOUBLE_REPORT_ID */
+	if (size < 1)
+		return 0;
+
 	switch (data[0]) {
 	case TRACKPAD_REPORT_ID:
 	case TRACKPAD2_BT_REPORT_ID:
@@ -490,6 +494,18 @@ static int magicmouse_raw_event(struct hid_device *hdev,
 		/* Sometimes the trackpad sends two touch reports in one
 		 * packet.
 		 */
+
+		/* Ensure that we have at least 2 elements (report type and size) */
+		if (size < 2)
+			return 0;
+
+		if (size < data[1] + 2) {
+			hid_warn(hdev,
+				 "received report length (%d) was smaller than specified (%d)",
+				 size, data[1] + 2);
+			return 0;
+		}
+
 		magicmouse_raw_event(hdev, report, data + 2, data[1]);
 		magicmouse_raw_event(hdev, report, data + 2 + data[1],
 			size - 2 - data[1]);
-- 
2.53.0

[PATCH AUTOSEL 7.0] smb: client: avoid integer overflow in SMB2 READ length check

[Sasha Levin]

From: Jeremy Erazo <mendozayt13@gmail.com>

[ Upstream commit 81a874233c305d29e37fdb70b691ff4254294c0b ]

SMB2 READ response validation in cifs_readv_receive() and
handle_read_data() checks data_offset + data_len against the received
buffer length.  Both values are attacker-controlled fields from the
server response and are stored as unsigned int, so the addition can
wrap before the bounds check:

	fs/smb/client/transport.c:1259
		if (!use_rdma_mr && (data_offset + data_len > buflen))

	fs/smb/client/smb2ops.c:4839
		else if (buf_len >= data_offset + data_len)

A malicious SMB server can use this to bypass validation.  In the
non-encrypted receive path the client attempts an oversized socket
read and stalls for the SMB response timeout (180 seconds) before
reconnecting.  In the SMB3 encrypted path, runtime testing shows the
malformed length can reach copy_to_iter() in handle_read_data() with
attacker-controlled size, where usercopy hardening stops the oversized
copy before bytes reach userspace.

Guard both call sites with check_add_overflow(), which is already
used elsewhere in this subsystem (smb2pdu.c).  On overflow, treat the
response as malformed and reject with -EIO.

Signed-off-by: Jeremy Erazo <mendozayt13@gmail.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record: Subsystem is `smb: client`; action verb is `avoid`; claimed
intent is preventing integer overflow in SMB2 READ response length
validation.

Record: Tags present are `Signed-off-by: Jeremy Erazo
<mendozayt13@gmail.com>` and `Signed-off-by: Steve French
<stfrench@microsoft.com>`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Reviewed-by:`, `Acked-by:`, `Link:`, or `Cc: stable@vger.kernel.org`
tags were present.

Record: The body describes attacker-controlled SMB2 READ response fields
`DataOffset` and `DataLength` being added as `unsigned int`, allowing
wraparound before bounds checks. The stated symptoms are a 180-second
client stall/reconnect in the non-encrypted path and an oversized
`copy_to_iter()` attempt in the encrypted path, stopped by usercopy
hardening.

Record: This is a direct bug fix, not hidden cleanup: it changes
overflow-prone bounds checks into checked arithmetic and rejects
malformed responses with `-EIO`.

### Phase 2: Diff Analysis
Record: Files changed: `fs/smb/client/smb2ops.c` and
`fs/smb/client/transport.c`; upstream stat is 12 insertions and 7
deletions. Modified functions are `handle_read_data()` and
`cifs_readv_receive()`. Scope is small and surgical.

Record: In `handle_read_data()`, before the patch `buf_len >=
data_offset + data_len` could pass after unsigned wrap. After the patch,
`check_add_overflow(data_offset, data_len, &end_off)` must be false and
`buf_len >= end_off` must be true before copying from `buf +
data_offset`.

Record: In `cifs_readv_receive()`, before the patch `data_offset +
data_len > buflen` could wrap and fail to reject malformed lengths.
After the patch, overflow or `end_off > buflen` marks the response
malformed and discards the frame.

Record: Bug category is integer overflow leading to bounds-check bypass.
The fix quality is good: it uses the kernel overflow helper already used
in this SMB client area, changes no ABI, and affects only malformed
server responses. Regression risk is low.

### Phase 3: Git History Investigation
Record: Upstream commit found on `origin/master` as
`81a874233c305d29e37fdb70b691ff4254294c0b`, merged by `b0662be9131d8` in
“Pull smb client fixes from Steve French”, explicitly listing “Fix
integer overflow in read”.

Record: `git blame` shows the current `handle_read_data()` vulnerable
expression attributed to `7c00c3a625f8`, but `git grep` confirmed the
same expression exists as far back as `v4.14`, so the bug predates that
current-line attribution. The `cifs_readv_receive()` vulnerable
expression is attributed to `fb157ed226d2`, described by `git describe
--contains` as `v6.0-rc1~75^2~4`.

Record: No `Fixes:` tag exists, so Step 3.2 is not applicable.

Record: Recent file history contains other SMB client fixes, including
OOB and data-corruption fixes, but no prerequisite for this commit was
identified. The commit is standalone.

Record: Jeremy Erazo had no prior SMB client commits in the checked
history. Steve French has many SMB/CIFS commits and is the SMB client
maintainer who committed this patch.

### Phase 4: Mailing List And External Research
Record: `b4 dig -c 81a874233c305d29e37fdb70b691ff4254294c0b` found the
original submission at `https://patch.msgid.link/20260514120334.2925013-
1-mendozayt13@gmail.com`.

Record: `b4 dig -a` found only v1 of the patch; no later revisions were
found.

Record: `b4 dig -w` showed Jeremy Erazo, Steve French, `linux-
cifs@vger.kernel.org`, `samba-technical@lists.samba.org`, and `linux-
kernel@vger.kernel.org` were included.

Record: Saved mbox contained the patch only; no review replies, NAKs,
stable nominations, or objections were present in that matched thread.
WebFetch to lore search pages was blocked by Anubis, so stable-list
search via web could not be independently verified.

### Phase 5: Code Semantic Analysis
Record: Modified functions are `handle_read_data()` and
`cifs_readv_receive()`.

Record: Callers: `smb2_async_readv()` passes `cifs_readv_receive` and
`smb3_handle_read_data` to `cifs_call_async()`. `cifs_call_async()`
stores them in the MID entry. The receive loop in `connect.c` invokes
`mids[0]->receive()` for non-encrypted async reads, while encrypted
large reads call `receive_encrypted_read()` and then
`handle_read_data()`.

Record: User reachability is verified through normal file reads:
`cifs_issue_read()` calls the dialect `async_readv()` operation, and
SMB2/SMB3 operation tables use `smb2_async_readv()`.

Record: Key callees are `server->ops->read_data_offset()`,
`server->ops->read_data_length()`, `cifs_read_iter_from_socket()`,
`cifs_readv_discard()`, and `copy_to_iter()`. `smb2_read_data_offset()`
reads `DataOffset`; `smb2_read_data_length()` reads `DataLength` or
`DataRemaining`.

Record: Similar pattern search found the same vulnerable `data_offset +
data_len` expressions in active stable tags; `check_add_overflow()` is
already used elsewhere in SMB client files.

### Phase 6: Stable Tree Analysis
Record: The vulnerable `handle_read_data()` expression exists in `v7.0`,
`v6.12`, `v6.6`, `v6.1`, `v5.15`, `v5.10`, `v4.19`, and `v4.14`. The
vulnerable `cifs_readv_receive()` expression exists in `v7.0`, `v6.12`,
`v6.6`, and `v6.1`; it was not found in `v5.15`/`v5.10` by the checked
grep.

Record: The patch applies cleanly to the current `7.0` tree with `git
apply --check`.

Record: Backport difficulty should be low for `v7.0`, `v6.12`, and
`v6.6`; `v6.1` and older need path adjustment from `fs/smb/client` to
`fs/cifs`. Older trees may need per-tree adjustment because
`v5.15`/`v5.10` only showed the `smb2ops.c` instance, and `v4.14` did
not have `check_add_overflow()` in `include/linux`.

### Phase 7: Subsystem Context
Record: Subsystem is SMB/CIFS client filesystem/network filesystem code.
Criticality is important: it affects SMB/CIFS mounts and reads from
remote servers.

Record: The subsystem is active; recent history includes SMB client
fixes for OOB reads, data corruption, replay initialization, races, and
read-path issues.

### Phase 8: Impact And Risk
Record: Affected users are SMB2/SMB3 client users mounting shares from a
malicious or broken server.

Record: Trigger condition is a crafted SMB2 READ response with
`DataOffset + DataLength` wrapping `unsigned int`. This is reachable
from normal file read paths over an SMB mount. Whether an unprivileged
local user can trigger it depends on mount/access policy; a malicious
server can trigger it once the client reads from that share.

Record: Failure mode is high severity: denial of service via read
stall/reconnect in the non-encrypted path, and malformed attacker-
controlled copy length reaching `copy_to_iter()` in the encrypted path.
I verified the call path to `copy_to_iter()` and the 3 * default
60-second unresponsive timeout logic; I did not independently reproduce
the runtime usercopy-hardening behavior.

Record: Benefit is high because this prevents a remotely supplied
malformed SMB response from bypassing validation. Risk is low because
the patch only rejects overflowed or out-of-bounds malformed READ
responses and does not alter valid response handling.

### Phase 9: Final Synthesis
Evidence for backporting: real bounds-check bypass from attacker-
controlled network fields; reachable in normal SMB read paths; high-
impact DoS/memory-safety-adjacent behavior; tiny two-function fix;
committed by the SMB maintainer; merged by Linus as an SMB client fix;
vulnerable code exists in multiple stable trees.

Evidence against backporting: no `Fixes:`/`Cc: stable`/review tags;
older stable trees need path/context adjustments, and very old trees may
lack `check_add_overflow()`.

Unresolved: I could not verify stable-list discussion because lore
WebFetch search was blocked, and I did not reproduce the runtime
hardening behavior. These do not change the decision because the integer
overflow and reachable bounds-check bypass are verified from code.

Stable rules checklist: obviously correct and tested enough by
review/merge evidence, yes; fixes a real bug, yes; important issue, yes;
small and contained, yes; no new feature/API, yes; applies cleanly to
7.0 and should be straightforward elsewhere with noted adjustments,
yes/minor backport work.

Verification:
- [Phase 1] Parsed upstream commit
  `81a874233c305d29e37fdb70b691ff4254294c0b`; found only Jeremy/Steve
  `Signed-off-by` tags.
- [Phase 2] `git show --stat` confirmed 2 files, 12 insertions, 7
  deletions.
- [Phase 3] `git blame` and `git describe --contains` checked history
  for both changed sites.
- [Phase 4] `b4 dig`, `b4 dig -a`, `b4 dig -w`, and saved mbox verified
  lore URL, v1-only series, recipients, and lack of replies.
- [Phase 5] `rg` and source reads verified read call path from
  `cifs_issue_read()` to `smb2_async_readv()` to receive handlers.
- [Phase 6] `git grep` checked vulnerable expressions in `v7.0`,
  `v6.12`, `v6.6`, `v6.1`, `v5.15`, `v5.10`, `v4.19`, and `v4.14`; `git
  apply --check` confirmed clean 7.0 application.
- [Phase 8] Source reads verified socket-read loop, reconnect timeout
  basis, and `copy_to_iter()` path.
- UNVERIFIED: independent runtime reproduction of the oversized
  copy/usercopy-hardening stop.
- UNVERIFIED: stable mailing-list search beyond `b4` mbox, because lore
  WebFetch search pages were blocked.

This should be backported to stable trees.

**YES**

 fs/smb/client/smb2ops.c   |  4 +++-
 fs/smb/client/transport.c | 15 +++++++++------
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
index ccc06c83956b5..d443cc8097df6 100644
--- a/fs/smb/client/smb2ops.c
+++ b/fs/smb/client/smb2ops.c
@@ -4721,6 +4721,7 @@ handle_read_data(struct TCP_Server_Info *server, struct mid_q_entry *mid,
 {
 	unsigned int data_offset;
 	unsigned int data_len;
+	unsigned int end_off;
 	unsigned int cur_off;
 	unsigned int cur_page_idx;
 	unsigned int pad_len;
@@ -4836,7 +4837,8 @@ handle_read_data(struct TCP_Server_Info *server, struct mid_q_entry *mid,
 		}
 		rdata->got_bytes = buffer_len;
 
-	} else if (buf_len >= data_offset + data_len) {
+	} else if (!check_add_overflow(data_offset, data_len, &end_off) &&
+		   buf_len >= end_off) {
 		/* read response payload is in buf */
 		WARN_ONCE(buffer, "read data can be either in buf or in buffer");
 		copied = copy_to_iter(buf + data_offset, data_len, &rdata->subreq.io_iter);
diff --git a/fs/smb/client/transport.c b/fs/smb/client/transport.c
index 05f8099047e1a..fdf4e50c27ceb 100644
--- a/fs/smb/client/transport.c
+++ b/fs/smb/client/transport.c
@@ -1158,7 +1158,7 @@ int
 cifs_readv_receive(struct TCP_Server_Info *server, struct mid_q_entry *mid)
 {
 	int length, len;
-	unsigned int data_offset, data_len;
+	unsigned int data_offset, data_len, end_off;
 	struct cifs_io_subrequest *rdata = mid->callback_data;
 	char *buf = server->smallbuf;
 	unsigned int buflen = server->pdu_size;
@@ -1256,11 +1256,14 @@ cifs_readv_receive(struct TCP_Server_Info *server, struct mid_q_entry *mid)
 	use_rdma_mr = rdata->mr;
 #endif
 	data_len = server->ops->read_data_length(buf, use_rdma_mr);
-	if (!use_rdma_mr && (data_offset + data_len > buflen)) {
-		/* data_len is corrupt -- discard frame */
-		rdata->result = smb_EIO2(smb_eio_trace_read_rsp_malformed,
-					 data_offset + data_len, buflen);
-		return cifs_readv_discard(server, mid);
+	if (!use_rdma_mr) {
+		if (check_add_overflow(data_offset, data_len, &end_off) ||
+		    end_off > buflen) {
+			/* data_len is corrupt -- discard frame */
+			rdata->result = smb_EIO2(smb_eio_trace_read_rsp_malformed,
+						 end_off, buflen);
+			return cifs_readv_discard(server, mid);
+		}
 	}
 
 #ifdef CONFIG_CIFS_SMB_DIRECT
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] libceph: Fix unnecessarily high ceph_decode_need() for uniform bucket

[Sasha Levin]

From: Raphael Zimmer <raphael.zimmer@tu-ilmenau.de>

[ Upstream commit 596f91294b351866956808b1ecb8dfae15382a6d ]

In crush_decode_uniform_bucket(), the item_weight field of the bucket
is set. This is a single field of type u32 since the uniform bucket uses
the same weight for all items. The value in ceph_decode_need() is set to
(1+b->h.size) * sizeof(u32), which is higher than actually needed.

This patch removes the call to ceph_decode_need() with the unnecessarily
high value and switches the subsequent operation from ceph_decode_32()
to ceph_decode_32_safe(), which already includes the correct bounds
check.

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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `libceph`/`net/ceph`; action verb `Fix`; intent:
correct an overlarge bounds check in `crush_decode_uniform_bucket()`.

Record 1.2: Tags: `Signed-off-by: Raphael Zimmer`, `Reviewed-by: Ilya
Dryomov`, `Signed-off-by: Ilya Dryomov`. No `Fixes:`, `Reported-by:`,
`Tested-by:`, `Link:`, or `Cc: stable` tag in this commit.

Record 1.3: The body says uniform buckets have one `u32 item_weight`,
but the old check required `(1 + b->h.size) * sizeof(u32)`. Symptom
implied by code is false `-EINVAL` during CRUSH map decode when only the
real uniform payload is present. No version info or reporter in the
message.

Record 1.4: Hidden bug fix: yes. It is not cleanup only; it changes a
bounds check from a size-dependent false requirement to the actual
single-field requirement.

## Phase 2: Diff Analysis
Record 2.1: One file, `net/ceph/osdmap.c`, 1 insertion and 2 deletions.
Modified function: `crush_decode_uniform_bucket()`. Scope: single-
function surgical fix.

Record 2.2: Before: checked for `1 + b->h.size` `u32`s, then consumed
one `u32`. After: `ceph_decode_32_safe()` checks and consumes exactly
one `u32`. This affects CRUSH uniform-bucket decode.

Record 2.3: Bug category: logic/correctness and bounds-check bug.
Mechanism: an over-strict buffer check can reject a CRUSH map even
though the following decode only needs `sizeof(u32)`.

Record 2.4: Fix quality: obviously correct from `struct
crush_bucket_uniform`, which contains only `item_weight` after the
common bucket header. Regression risk is very low because the
replacement macro performs the same safe bounds check for the one value
actually read.

## Phase 3: Git History
Record 3.1: `git blame` shows the overlarge check dates to
`f24e9980eb860d` (`ceph: OSD client`), first contained in `v2.6.34`. The
assignment line was later touched by `c89136ea4253c7`, but the wrong
size expression was already present.

Record 3.2: No `Fixes:` tag, so there was no tagged introducing commit
to follow.

Record 3.3: Recent related file history shows adjacent CRUSH decode
hardening, especially `6a782b546337a` (`libceph: Fix potential out-of-
bounds access in crush_decode()`), followed by this patch. This patch’s
hunk is standalone.

Record 3.4: Author Raphael Zimmer has several recent libceph hardening
fixes. Ilya Dryomov is listed in `MAINTAINERS` as a libceph maintainer
and reviewed/committed this patch.

Record 3.5: No functional dependency found for this exact hunk. `git
apply --check` succeeds on the current checkout.

## Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c 29e2da9499784` found the original submission:
`https://patch.msgid.link/20260424133737.921463-1-raphael.zimmer@tu-
ilmenau.de`. `b4 dig -a` found only v1. The saved mbox shows Ilya
replied “Applied.” No objections or NAKs found.

Record 4.2: `b4 dig -w` shows Raphael Zimmer, Ilya Dryomov, Alex
Markuze, Viacheslav Dubeyko, and `ceph-devel@vger.kernel.org` were
included. `MAINTAINERS` confirms these are the libceph maintainers/list.

Record 4.3: No `Reported-by` or `Link` in this commit. I found Ceph
tracker bug #75829 for adjacent CRUSH decode out-of-bounds work, but it
directly matches `6a782b...`, not this exact overlarge-check patch, so I
did not use it as primary evidence.

Record 4.4: Related patch context is the adjacent `6a782b...` CRUSH
decode safety fix. This patch is not part of a multi-patch series
according to `b4 dig -a`.

Record 4.5: Web lore fetching was blocked by Anubis, but `b4` retrieved
the thread. Web search did not find stable-specific discussion for this
exact subject/hash.

## Phase 5: Code Semantic Analysis
Record 5.1: Modified function: `crush_decode_uniform_bucket()`.

Record 5.2: Caller path verified: `mon_dispatch()` handles
`CEPH_MSG_OSD_MAP` -> `ceph_osdc_handle_map()` -> `handle_one_map()` ->
`ceph_osdmap_decode()` or incremental decode -> `crush_decode()` ->
`crush_decode_uniform_bucket()`.

Record 5.3: Key callees: `ceph_decode_32_safe()` expands to
`ceph_decode_need(..., sizeof(u32), ...)` plus `ceph_decode_32()`.
Failure returns `-EINVAL`, then `crush_decode()` destroys the partial
map and returns `ERR_PTR(err)`.

Record 5.4: Reachability: this is reached from received Ceph monitor OSD
map messages, not a local syscall path. Affected users are Ceph clients
receiving CRUSH maps with uniform buckets.

Record 5.5: Similar patterns: list/straw/straw2 bucket decoders
correctly check size-dependent arrays because they actually decode
arrays. Uniform bucket is the outlier because its bucket-specific data
is one scalar.

## Phase 6: Stable Tree Analysis
Record 6.1: Checked `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.18`,
`v6.19`, and `v7.0`; all contain the old overlarge check.

Record 6.2: Backport difficulty: expected clean or trivial. The exact
target lines are present across checked stable tags/pending branches,
and `git apply --check` succeeds on the current checkout.

Record 6.3: No different fix for this exact uniform-bucket overcheck
found in the checked history before `29e2da9499784`.

## Phase 7: Subsystem Context
Record 7.1: Subsystem: libceph common code, CRUSH/OSD map decoding.
Criticality: important for Ceph users, not universal to all Linux users.

Record 7.2: Subsystem activity: active, with recent libceph decode and
message-processing hardening commits from Raphael Zimmer and Ilya
Dryomov.

## Phase 8: Impact And Risk
Record 8.1: Affected population: Ceph kernel clients using CRUSH maps
with uniform buckets.

Record 8.2: Trigger: receiving a CRUSH map where a uniform bucket’s
`b->h.size` makes the old false requirement exceed the remaining buffer
even though the one actual `item_weight` field is available. Not
verified as unprivileged-user-triggerable.

Record 8.3: Failure mode: false `-EINVAL` in CRUSH/OSD map decode,
leading `ceph_osdc_handle_map()` to report a corrupt map message and
skip the update. Severity: high for affected Ceph clients because OSD
map decode failure can disrupt storage access.

Record 8.4: Benefit: medium-high for Ceph client reliability. Risk: very
low, because the patch narrows a bounds check to the exact field
consumed and introduces no API or behavioral feature.

## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: real decode correctness bug;
ancient code present in all checked stable trees; affects storage client
map updates; one-line surgical fix; maintainer reviewed; clean apply.
Evidence against: no reporter, no test tag, no direct crash/data-
corruption proof for this exact patch. Unresolved: no external stable-
list discussion found due lore web blocking; no live Ceph reproducer
run.

Record 9.2: Stable rules: obviously correct: yes; fixes a real bug: yes,
over-strict valid-buffer rejection; important: yes for affected Ceph
clients because OSD map updates are core storage functionality;
small/contained: yes, 1-line functional change; no new APIs/features:
yes; applies to stable: yes/trivial based on checked code.

Record 9.3: Exception category: none. This is a normal bug fix, not a
device ID, quirk, DT, build, or documentation exception.

Record 9.4: Decision: backport. The benefit outweighs the tiny risk.

## Verification
- Phase 1: Parsed `git show --format=fuller 29e2da9499784`; confirmed
  subject, tags, author, reviewer, committer, and absence of
  reporter/link/fixes tags.
- Phase 2: Inspected the full diff; confirmed only
  `crush_decode_uniform_bucket()` changes from overlarge
  `ceph_decode_need()` plus raw decode to `ceph_decode_32_safe()`.
- Phase 3: Ran `git blame` on the affected lines; found
  `f24e9980eb860d`, first in `v2.6.34`. Checked related history and
  author history.
- Phase 4: Ran `b4 dig -c`, `-a`, `-w`, and saved/read the mbox; found
  v1 submission and maintainer “Applied” reply.
- Phase 5: Traced callers with source searches and file reads through
  monitor OSD map handling to CRUSH decode.
- Phase 6: Checked stable tags/pending branches for the exact old code
  and ran `git apply --check`.
- Phase 7: Checked `MAINTAINERS`; confirmed libceph maintainers and
  supported status.
- Phase 8: Verified failure path returns `-EINVAL`, destroys partial
  CRUSH map, and causes `ceph_osdc_handle_map()` to log corrupt message
  handling.
- UNVERIFIED: No runtime reproducer was executed; no direct user report
  was found for this exact patch.

**YES**

 net/ceph/osdmap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
index c89e66d4fcb7f..753a2ed31e5bf 100644
--- a/net/ceph/osdmap.c
+++ b/net/ceph/osdmap.c
@@ -72,8 +72,7 @@ static int crush_decode_uniform_bucket(void **p, void *end,
 				       struct crush_bucket_uniform *b)
 {
 	dout("crush_decode_uniform_bucket %p to %p\n", *p, end);
-	ceph_decode_need(p, end, (1+b->h.size) * sizeof(u32), bad);
-	b->item_weight = ceph_decode_32(p);
+	ceph_decode_32_safe(p, end, b->item_weight, bad);
 	return 0;
 bad:
 	return -EINVAL;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] ALSA: hda/realtek: fix mic boost on Framework PTL

[Sasha Levin]

From: Daniel Schaefer <dhs@frame.work>

[ Upstream commit 67c73815220784074ff13ec07df955911caf1b73 ]

In addition to the mic jack fix, also need to avoid boosting the
internal mic too much, otherwise >50% input volume clips a lot.

Also add a second SSID. We have one for the classic chassis/speaker and
one for the new Pro chassis/speaker.

To: Jaroslav Kysela <perex@perex.cz>
To: Takashi Iwai <tiwai@suse.com>
To: linux-sound@vger.kernel.org
Cc: Dustin L. Howett <dustin@howett.net>
Cc: linux@frame.work
Signed-off-by: Daniel Schaefer <dhs@frame.work>
Link: https://patch.msgid.link/20260513155513.11683-1-dhs@frame.work
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `ALSA: hda/realtek`. Action verb is `fix`.
Claimed intent is to fix excessive internal microphone boost on
Framework PTL systems and add a second Framework PTL SSID.

Step 1.2 Record: Tags present:
- `To`: Jaroslav Kysela, Takashi Iwai, `linux-sound@vger.kernel.org`
- `Cc`: Dustin L. Howett, `linux@frame.work`
- `Signed-off-by`: Daniel Schaefer
- `Link`:
  `https://patch.msgid.link/20260513155513.11683-1-dhs@frame.work`
- `Signed-off-by`: Takashi Iwai
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by`,
  or `Cc: stable@vger.kernel.org` tag was present.

Step 1.3 Record: The commit describes a real user-visible audio defect:
the internal microphone clips heavily when input volume is above 50%. It
also states there are two SSIDs for the Framework PTL generation, one
classic chassis/speaker and one Pro chassis/speaker. No crash, stack
trace, or kernel-version range is described.

Step 1.4 Record: This is not a hidden memory-safety bug. It is an
explicit hardware quirk/audio correctness fix: it corrects the quirk
selected for one Framework PTL SSID and adds another SSID.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `sound/hda/codecs/realtek/alc269.c`,
9 insertions and 1 deletion. Modified areas are the Realtek fixup enum,
`alc269_fixups[]`, and `alc269_fixup_tbl[]`. Scope is a single-file,
surgical driver quirk change.

Step 2.2 Record:
- Enum hunk: before, only
  `ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE` existed; after, a
  Framework-specific chained mic-boost limiter fixup ID is added.
- Fixup table hunk: before, Framework systems only got the mic-
  presence/headset-mode chain; after, the new Framework PTL fixup first
  invokes `alc269_fixup_limit_int_mic_boost` and then chains to the
  existing Framework mic-presence fixup.
- Quirk table hunk: before, `0xf111:0x000f` used only the Framework mic-
  presence fixup; after, `0xf111:0x000f` uses the mic-boost-limiting
  chain, and `0xf111:0x010f` is added with the same chain.

Step 2.3 Record: Bug category is hardware quirk/workaround plus device
ID addition. The fix reuses existing `alc269_fixup_limit_int_mic_boost`,
which, on `HDA_FIXUP_ACT_PROBE`, finds internal analog mic pins and
overrides input amp caps to limit boost levels. No race, memory-safety,
refcount, or error-path bug is involved.

Step 2.4 Record: Fix quality is high: minimal, contained, uses existing
Realtek HDA fixup infrastructure, and only affects two explicit
Framework subsystem IDs. Regression risk is very low and limited to
those two machines; the only plausible risk is reducing available mic
gain too much on those exact SSIDs.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` on the parent of commit
`67c73815220784074ff13ec07df955911caf1b73` shows the existing Framework
fixup/table structure came through the Realtek driver split/import
commit `c08e42c9a40ab`, while the `0xf111:0x000f` quirk line itself was
introduced by `bac1e57adf08c9` in the v7.0 cycle. Historical `git show`
verified the original Framework fixup was introduced by `309d7363ca3d9`,
first described by `git describe` as `v5.18~27^2~3`. The boost-limiting
helper pattern was present since `8903376dc6994`, described as
`v5.14-rc7~16^2~1`.

Step 3.2 Record: No `Fixes:` tag is present, so there was no Fixes
target to follow.

Step 3.3 Record: Recent file history shows many Realtek laptop quirk
commits, including `bac1e57adf08c` for Framework `0xf111:000f`. No
required multi-patch series was found for this candidate.

Step 3.4 Record: Author Daniel Schaefer previously authored Framework
`0xf111:000c` Realtek quirk work. Dustin Howett, CC’d here, authored
several Framework Realtek quirk commits. Takashi Iwai applied this patch
and is the ALSA HDA maintainer path for these commits.

Step 3.5 Record: Dependencies are the existing Framework mic-presence
fixup and existing mic-boost limiter helper. They exist in the local
current tree; older stable trees before the
`sound/hda/codecs/realtek/alc269.c` split would need a path/context
backport to `sound/pci/hda/patch_realtek.c`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 67c73815220784074ff13ec07df955911caf1b73`
matched the patch by patch-id and found
`https://patch.msgid.link/20260513155513.11683-1-dhs@frame.work`. `b4
dig -a` found only v1. The saved thread contains Takashi Iwai’s reply:
“Applied now. Thanks.” No NAKs or requested revisions were found.

Step 4.2 Record: `b4 dig -w` lists Daniel Schaefer, Jaroslav Kysela,
Takashi Iwai, `linux-sound@vger.kernel.org`, Dustin L. Howett, and
`linux@frame.work` as original participants. Appropriate ALSA
maintainers/list were included.

Step 4.3 Record: No separate `Reported-by` bug report was linked.
Phoronix independently reports the same applied commit and repeats the
stated impact: Framework PTL internal mic clips above 50% input volume;
it identifies the hardware as Framework Laptop 13 Pro / Panther Lake.

Step 4.4 Record: Related patches include earlier Framework Realtek quirk
additions for `0xf111:0001`, `0009`, `000c`, and `000f`, plus several
prior “Limit mic boost” Realtek quirks. This candidate is standalone.

Step 4.5 Record: Web search did not find stable-list discussion for this
exact candidate. No stable-specific objection was found.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: No ordinary function body is newly changed. The
affected code is the Realtek HDA fixup selection tables plus the
existing helper `alc269_fixup_limit_int_mic_boost`.

Step 5.2 Record: Caller path is `alc269_probe`, which calls
`snd_hda_pick_fixup` using `alc269_fixup_tbl`, then applies fixups at
`HDA_FIXUP_ACT_PRE_PROBE` and `HDA_FIXUP_ACT_PROBE`. The impact surface
is limited to probe/init of matching Realtek HDA codecs with Framework
SSIDs `0xf111:000f` or `0xf111:010f`.

Step 5.3 Record: The key helper calls `snd_hda_codec_get_pincfg`,
`snd_hda_get_input_pin_attr`, and `snd_hda_override_amp_caps`.
`snd_hda_override_amp_caps` is documented in code as overriding cached
amp caps, useful to adjust amp ranges such as limiting to 0 dB.

Step 5.4 Record: The buggy path is reachable automatically during codec
probe on the affected hardware. The user-visible failure is then
triggered by normal microphone capture with input volume above 50%. This
is not an unprivileged security trigger; it is normal hardware use.

Step 5.5 Record: Similar Realtek mic-boost limiter quirks exist,
including `8903376dc6994`, `86a433862912f`, `6db03b1929e20`, and
`76b0a22d4cf7d`. Some prior similar mic-boost quirk commits carried `Cc:
stable@vger.kernel.org`.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: `v7.0` contains the `0xf111:000f` Framework line, so
the wrong/insufficient fixup exists in v7.0.y candidates. `v6.18` and
`v6.17` tags checked locally did not contain `0xf111:000f`. `v6.12` and
`v6.6` contain the base Framework fixup and boost helper, but not the
newer `000f`/`010f` IDs.

Step 6.2 Record: The patch applies cleanly to the current local tree
with `git apply --check`. It should be straightforward for v7.0.y. Older
stable trees may need mechanical backporting because the Realtek code
lived in `sound/pci/hda/patch_realtek.c` before the driver split.

Step 6.3 Record: No alternate fix for this exact Framework PTL mic boost
issue was found in local history or stable-search results.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is ALSA HDA Realtek codec driver. Criticality
is driver-specific/important for affected laptop users, not core-kernel
universal.

Step 7.2 Record: The Realtek HDA quirk area is very active; recent
history shows many laptop quirk additions/fixes in the same file.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: Affected population is Framework Laptop 13 Pro PTL and
Framework Laptop 13 PTL users with Realtek HDA audio matching
`0xf111:000f` or `0xf111:010f`.

Step 8.2 Record: Trigger is common on affected hardware: normal internal
microphone use with input volume above 50%. It is not security-sensitive
and does not require unusual kernel configuration beyond the Realtek HDA
driver.

Step 8.3 Record: Failure mode is bad/clipped microphone capture,
severity MEDIUM. It is not a crash, data corruption, deadlock, or
memory-safety issue, but it materially breaks expected laptop audio
behavior.

Step 8.4 Record: Benefit is high for the affected hardware because it
makes microphone capture usable and adds the second SSID. Risk is very
low: 10-line single-driver quirk, no API changes, no broad behavior
change.

## Phase 9: Final Synthesis
Step 9.1 Record:
- Evidence for backporting: real hardware-specific bug, explicit user-
  visible clipping, new SSID addition, standard stable-acceptable quirk
  pattern, tiny patch, existing helper reused, maintainer applied, clean
  current-tree apply.
- Evidence against backporting: not a crash/security/data-corruption
  fix; affected population is specific new hardware; older trees may
  need path/context adjustments.
- Unresolved: no local runtime test on Framework PTL hardware; exact
  older stable applicability depends on whether those trees have or
  should receive the newer Framework PTL SSIDs.

Step 9.2 Record:
1. Obviously correct and tested? Mostly yes by inspection and maintainer
   acceptance; no `Tested-by` and no local hardware test.
2. Fixes a real bug affecting users? Yes, verified from commit body and
   external report: internal mic clips above 50% volume.
3. Important issue? Medium severity, but stable rules commonly accept
   hardware quirks/device IDs.
4. Small and contained? Yes, one file, 9 insertions/1 deletion.
5. No new features/APIs? Yes, no API or userspace ABI change.
6. Can apply to stable trees? Clean on current/v7.0-style tree; older
   trees need mechanical backport.

Step 9.3 Record: This falls squarely into stable exception categories:
hardware quirk/workaround and device ID/SSID addition for an existing
driver.

Step 9.4 Decision: Backport. Although not a severe kernel stability bug,
stable policy routinely accepts small hardware quirks like this, and the
risk is confined to two Framework SSIDs while the benefit is fixing
broken microphone behavior on affected systems.

## Verification
- Phase 1: Parsed commit `67c73815220784074ff13ec07df955911caf1b73` with
  `git show`; verified tags and absence of `Fixes`, `Reported-by`,
  `Tested-by`, `Reviewed-by`, and stable CC.
- Phase 2: Verified diffstat: `sound/hda/codecs/realtek/alc269.c`, 10
  changed lines, 9 insertions/1 deletion.
- Phase 3: Ran `git blame` on parent commit around enum, fixup table,
  and quirk table; verified `0xf111:000f` came from `bac1e57adf08c9`.
- Phase 3: Ran `git show` on `309d7363ca3d9`, `8903376dc6994`,
  `bac1e57adf08c9`, `7b509910b3ad6`, and related boost quirk commits.
- Phase 4: Ran `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and `b4 dig -m`;
  verified v1-only patch, original recipients, lore URL, and maintainer
  “Applied now” reply.
- Phase 4: WebFetch of lore/git.kernel direct pages was blocked by
  Anubis, but `b4` successfully fetched the lore thread and Phoronix
  verified the applied commit ID and issue summary.
- Phase 5: Used `rg`/code reads to verify `alc269_probe` selects and
  applies fixups, and that `snd_hda_override_amp_caps` adjusts cached
  amp capabilities.
- Phase 6: Ran `git grep` against `v7.0`, `v6.18`, `v6.17`, `v6.12`, and
  `v6.6` for Framework IDs/helper presence.
- Phase 6: Ran `git apply --check` on the mbox; it applies cleanly to
  the current tree.
- Unverified: no physical Framework PTL hardware test was performed
  locally.

**YES**

 sound/hda/codecs/realtek/alc269.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index b1fb5e1cf0078..3a36ae494c39b 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -4097,6 +4097,7 @@ enum {
 	ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED,
 	ALC285_FIXUP_HP_SPEAKERS_MICMUTE_LED,
 	ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE,
+	ALC295_FIXUP_FRAMEWORK_LAPTOP_LIMIT_INT_MIC_BOOST,
 	ALC287_FIXUP_LEGION_16ITHG6,
 	ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK,
 	ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN,
@@ -6346,6 +6347,12 @@ static const struct hda_fixup alc269_fixups[] = {
 		.chained = true,
 		.chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
 	},
+	[ALC295_FIXUP_FRAMEWORK_LAPTOP_LIMIT_INT_MIC_BOOST] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc269_fixup_limit_int_mic_boost,
+		.chained = true,
+		.chain_id = ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE,
+	},
 	[ALC287_FIXUP_LEGION_16ITHG6] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc287_fixup_legion_16ithg6_speakers,
@@ -7824,7 +7831,8 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0xf111, 0x0009, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0xf111, 0x000b, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0xf111, 0x000c, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
-	SND_PCI_QUIRK(0xf111, 0x000f, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0xf111, 0x000f, "Framework Laptop 13 Pro PTL", ALC295_FIXUP_FRAMEWORK_LAPTOP_LIMIT_INT_MIC_BOOST),
+	SND_PCI_QUIRK(0xf111, 0x010f, "Framework Laptop 13 PTL", ALC295_FIXUP_FRAMEWORK_LAPTOP_LIMIT_INT_MIC_BOOST),
 
 #if 0
 	/* Below is a quirk table taken from the old code.
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] io_uring: hold uring_lock when walking link chain in io_wq_free_work()

[Sasha Levin]

From: Jens Axboe <axboe@kernel.dk>

[ Upstream commit 20c39819a27646573dfa0ac0d01c38895298a6f6 ]

io_wq_free_work() calls io_req_find_next() from io-wq worker context,
which reads and clears req->link without holding any lock. This can
potentially race with other paths that mutate the same chain under
ctx->uring_lock.

Take ctx->uring_lock around the io_req_find_next() call. Only requests
with IO_REQ_LINK_FLAGS reach this path, which is not the hot path.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `io_uring`; action verb `hold`; intent:
serialize linked-request chain walking in `io_wq_free_work()` with
`ctx->uring_lock`.

Step 1.2 Record: Tags present in commit
`20c39819a27646573dfa0ac0d01c38895298a6f6`:
- `Signed-off-by: Jens Axboe <axboe@kernel.dk>`
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, `Link:`, or `Cc: stable@vger.kernel.org` tags in the committed
  message.

Step 1.3 Record: The commit states that `io_wq_free_work()` calls
`io_req_find_next()` from io-wq worker context, and `io_req_find_next()`
reads and clears `req->link` without a lock. The stated failure mode is
a potential race with other paths mutating the same chain under
`ctx->uring_lock`. No stack trace, reproducer, affected-version
statement, or user report is in the commit message.

Step 1.4 Record: This is a hidden bug fix despite the subject not saying
“fix”: it adds missing synchronization around shared linked-request
state. The diff confirms it is not a cleanup or feature.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `io_uring/io_uring.c`, 6 insertions
and 1 deletion. Only `io_wq_free_work()` is modified. Scope: single-file
surgical locking fix.

Step 2.2 Record: Before, `io_wq_free_work()` called
`io_req_find_next(req)` directly when `IO_REQ_LINK_FLAGS` was set.
After, it stores `req->ctx`, takes `ctx->uring_lock`, calls
`io_req_find_next(req)`, and unlocks. The affected path is io-wq worker
completion/freeing of linked requests, not the normal unlinked hot path.

Step 2.3 Record: Bug category is synchronization/race condition.
`io_req_find_next()` reads `req->link` and clears it; `git grep`
verified other link-chain assignment/mutation sites in
submission/timeout paths. The fix serializes this worker-side chain walk
with the mutex used by normal chain mutation paths.

Step 2.4 Record: The fix is obviously small and locally correct: it
protects exactly the shared `req->link` read/clear. Regression risk is
low but not zero, because it adds a mutex acquisition in worker cleanup.
The commit message and code both verify the path is limited to requests
with `IO_REQ_LINK_FLAGS`.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` on the pre-fix parent showed the current
direct `io_wq_free_work()` call to `io_req_find_next()` came from
`247f97a5f19b64`, described by `git describe` as `v6.5-rc1~235^2~10`.
Older helper-based worker cleanup existed before that;
`io_wq_free_work()`/io-wq callback code is present from at least
`v5.15-rc1~185^2~41`, and stable branch checks show equivalent
vulnerable helper paths in `5.10.y`, `5.15.y`, and `6.1.y`.

Step 3.2 Record: No `Fixes:` tag is present, so there was no tagged
introducing commit to follow.

Step 3.3 Record: Recent `io_uring/io_uring.c` history includes related
io-wq/refcount work, notably `390513642ee676` / stable variants,
“io_uring: always do atomic put from iowq,” which changed the same
function and was KCSAN/syzbot-motivated. Mainline related commits
immediately after this candidate are `49ae66eb8c273` and
`a65855ec34aed`, the other two patches in the linked-request locking
series.

Step 3.4 Record: `MAINTAINERS` verifies Jens Axboe is the `IO_URING`
maintainer. `git log --author='Jens Axboe' -- io_uring` shows multiple
recent io_uring commits by him.

Step 3.5 Record: Build-wise this patch is standalone for trees with the
current direct `io_wq_free_work()` shape. For older stable trees using
`io_put_req_find_next()`, it needs a manual backport into the helper or
equivalent worker path. Semantically, it is patch 1/3 of a related
locking series; patches `49ae66eb8c273` and `a65855ec34aed` should be
considered with it to complete the linked-chain locking invariant.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 20c39819a2764` found the original submission
at `https://patch.msgid.link/20260511182217.226763-2-axboe@kernel.dk`.
`b4 dig -a` found only v1. The saved mbox shows this was `[PATCH 1/3]`.

Step 4.2 Record: `b4 dig -w` showed the patch was sent by Jens Axboe to
`io-uring@vger.kernel.org`, with Jens on Cc. No separate
reviewer/maintainer tags or replies were found in the saved matched
thread.

Step 4.3 Record: No bug-report link or `Reported-by:` tag exists. Web
search for the exact subject did not find a direct bug report.

Step 4.4 Record: The mbox cover letter says the series is “Linked
request fix” and “closing some gaps on linked requests, where iterating
a chain must hold either ->uring_lock OR ->timeout_lock, and modifying
any existing [chain] must hold both.” Patch 2 defers linked-timeout
splicing out of hrtimer context; patch 3 keeps `uring_lock` held across
`io_kill_timeouts()`.

Step 4.5 Record: WebFetch of lore was blocked by Anubis, but `b4`
successfully retrieved the thread. Web search did not find stable-
specific discussion for this exact patch. No direct stable nomination
was verified.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `io_wq_free_work()`.

Step 5.2 Record: Callers verified by `git grep`: `io_wq_free_work()` is
called from `io_uring/io-wq.c` after `io_wq_submit_work()` in the worker
loop and from the cancel path helper `io_run_cancel()`. This is io-wq
worker context.

Step 5.3 Record: Key callee is `io_req_find_next()`, verified to read
`req->link`, set `req->link = NULL`, and return the next linked request.
`io_wq_free_work()` then frees the current request via `io_free_req()`.

Step 5.4 Record: Reachability is verified from userspace:
`io_uring_enter()` locks `ctx->uring_lock` and calls `io_submit_sqes()`,
user SQE flags include `IOSQE_IO_LINK`, `IOSQE_IO_HARDLINK`, and
`IOSQE_ASYNC`, and async paths queue work into io-wq. This makes the
affected path reachable by user-submitted linked async io_uring
requests.

Step 5.5 Record: Similar patterns found: the normal completion/free
batching path calls `io_queue_next()`/`io_req_find_next()` while
`__io_submit_flush_completions()` and `io_free_batch_list()` require
`ctx->uring_lock`. Timeout code also mutates `req->link`, and the same
series addresses that.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: Stable branch checks verified equivalent vulnerable
code in `stable/linux-5.10.y`, `stable/linux-5.15.y`,
`stable/linux-6.1.y`, `stable/linux-6.6.y`, `stable/linux-6.12.y`,
`stable/linux-6.19.y`, and `stable/linux-7.0.y`. The exact direct hunk
exists in newer trees; older trees use `io_put_req_find_next()`.

Step 6.2 Record: `git apply --check` of the candidate patch succeeded on
the current checked-out `stable/linux-7.0.y` tree. Backport difficulty:
clean or near-clean for newer trees with the direct function body;
manual but simple for older helper-based trees.

Step 6.3 Record: Exact-subject `git log` over listed stable branches
found no existing stable copy of this fix. Related stable history
contains earlier io_uring link/refcount fixes, but not this locking fix.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is `io_uring`, a core async I/O subsystem
reachable through the `io_uring_enter` syscall. Criticality:
important/core-adjacent because it is syscall-reachable and handles
request lifetime, completion, and linked request ordering.

Step 7.2 Record: The subsystem is active: recent mainline history around
the candidate contains multiple io_uring fixes and refactors, and the
candidate came through the io_uring maintainer tree.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: Affected users are systems using io_uring linked
requests that can complete through io-wq, especially linked async
operations. This is feature/config/user-workload specific, not
universal.

Step 8.2 Record: Trigger requires linked request chains and worker
completion/cancellation interleaving with other chain mutation/walk
paths. Unprivileged reachability depends on system policy, but the code
path is syscall-reachable through io_uring submission. No public
reproducer was verified.

Step 8.3 Record: Verified failure mode is an unsynchronized data race on
`req->link`. The precise observed symptom is unverified, but the raced
state controls request-chain lifetime/progression; plausible
consequences include lost/misordered linked request handling or memory-
safety/lifetime bugs. Severity: medium-high to high because it is a
syscall-reachable race in request lifetime code, though no crash report
was verified.

Step 8.4 Record: Benefit is high enough for stable because it removes a
real locking hole in io_uring linked-request handling. Risk is low:
6-line contained mutex protection, not on the unlinked hot path, no new
API, no behavior change except serialization.

## Phase 9: Final Synthesis
Step 9.1 Evidence for backporting:
- Verified real unsynchronized access: `io_wq_free_work()` called
  `io_req_find_next()` without `ctx->uring_lock`, while
  `io_req_find_next()` reads and clears `req->link`.
- Verified reachability from user-submitted io_uring linked async
  requests.
- Verified equivalent code exists across active stable trees from
  `5.10.y` through `7.0.y`.
- Verified fix is tiny, contained, maintainer-authored, and applies
  cleanly to `7.0.y`.
- Verified this is part of an explicit “Linked request fix” series
  closing locking gaps.

Evidence against or concerns:
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, stable Cc,
  stack trace, or reproducer was verified.
- It is patch 1/3 of a related series; for best stable correctness,
  patches `49ae66eb8c273` and `a65855ec34aed` should be
  evaluated/backported together.
- Older stable trees need manual adaptation to `io_put_req_find_next()`.

Step 9.2 Stable rules checklist:
1. Obviously correct and tested? Correct by inspection; external testing
   not verified.
2. Fixes a real bug? Yes, verified race on `req->link`.
3. Important issue? Yes enough for stable: syscall-reachable request-
   chain/lifetime race, though exact crash symptom is unverified.
4. Small and contained? Yes, one function, one file, 6 insertions.
5. No new features/APIs? Yes.
6. Can apply to stable? Yes for newer trees; older trees need
   straightforward backport.

Step 9.3 Exception category: None. This is not a device ID, quirk, DT,
build, or documentation-only patch.

Step 9.4 Decision: Backport. The technical merit is a small, maintainer-
authored synchronization fix for a verified io_uring linked-request race
in code present across stable trees. Treat the rest of the 3-patch
linked-request locking series as related follow-up material rather than
ignoring it.

## Verification
- [Phase 1] `git show --format=fuller --stat --patch 20c39819a2764`:
  confirmed subject, body, tags, one-file diff, and absence of
  `Fixes:`/`Reported-by:`/stable tags.
- [Phase 2] Diff inspection: confirmed
  `mutex_lock(&ctx->uring_lock)`/unlock added around
  `io_req_find_next()` only in `io_wq_free_work()`.
- [Phase 3] `git blame` on the parent: confirmed `io_wq_free_work()`
  direct call history and `req->link` read/clear history.
- [Phase 3] `git describe --contains`: confirmed relevant code history
  reaches released kernels including `v6.5-rc1`, `v5.15-rc1`, and
  earlier helper behavior.
- [Phase 3] Stable branch `git grep`: confirmed vulnerable worker/helper
  paths in `5.10.y`, `5.15.y`, `6.1.y`, `6.6.y`, `6.12.y`, `6.19.y`, and
  `7.0.y`.
- [Phase 4] `b4 dig -c`, `-a`, `-w`, and saved mbox: confirmed original
  submission URL, v1-only series, recipients, cover-letter context, and
  3-patch series.
- [Phase 4] WebFetch: lore direct fetch was blocked by Anubis; b4 mbox
  provided the thread content.
- [Phase 5] `git grep` call tracing: confirmed `io_wq_free_work()`
  callers in io-wq worker/cancel paths, `io_uring_enter()` to
  `io_submit_sqes()` submission path, and user-visible link flags.
- [Phase 6] `git apply --check`: confirmed the patch applies cleanly to
  the current `stable/linux-7.0.y` worktree.
- [Phase 7] `MAINTAINERS` search: confirmed Jens Axboe is the `IO_URING`
  maintainer.
- [Phase 8] Verified no public reproducer or exact crash symptom in the
  commit/thread; severity assessment is based on verified race location
  and syscall reachability, not on an observed report.

**YES**

 io_uring/io_uring.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 97260bca67e7b..a72efb3a62bac 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -1450,8 +1450,13 @@ struct io_wq_work *io_wq_free_work(struct io_wq_work *work)
 	struct io_kiocb *nxt = NULL;
 
 	if (req_ref_put_and_test_atomic(req)) {
-		if (req->flags & IO_REQ_LINK_FLAGS)
+		if (req->flags & IO_REQ_LINK_FLAGS) {
+			struct io_ring_ctx *ctx = req->ctx;
+
+			mutex_lock(&ctx->uring_lock);
 			nxt = io_req_find_next(req);
+			mutex_unlock(&ctx->uring_lock);
+		}
 		io_free_req(req);
 	}
 	return nxt ? &nxt->work : NULL;
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] wifi: nl80211: re-check wiphy netns in nl80211_prepare_wdev_dump() continuation

[Sasha Levin]

From: Maoyi Xie <maoyi.xie@ntu.edu.sg>

[ Upstream commit 79240f3f6d766b342b57c32397d643e1cfa26b81 ]

NL80211_CMD_GET_SCAN is implemented as a multi-call dumpit. The first
invocation of nl80211_prepare_wdev_dump() validates the requested wdev
against the caller's netns via __cfg80211_wdev_from_attrs(). Subsequent
invocations look up the same wiphy by its global index and do not check
that the wiphy is still in the caller's netns.

Add the same filter to the continuation path. If the wiphy's netns no
longer matches the caller's, return -ENODEV and the netlink dump
machinery terminates the walk cleanly.

Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260506064854.2207105-3-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

**Phase 1: Commit Message Forensics**
- Step 1.1 Record: Subsystem `wifi: nl80211`; action verb `re-check`;
  intent is to revalidate the wiphy net namespace during
  `nl80211_prepare_wdev_dump()` continuation.
- Step 1.2 Record: Tags are `Signed-off-by: Maoyi Xie`, `Link: https://p
  atch.msgid.link/20260506064854.2207105-3-maoyixie.tju@gmail.com`,
  `Signed-off-by: Johannes Berg`. No `Fixes`, `Reported-by`, `Tested-
  by`, `Reviewed-by`, `Acked-by`, or `Cc: stable`.
- Step 1.3 Record: The committed message says first dump invocation
  validates via `__cfg80211_wdev_from_attrs()`, but later invocations
  recover the wiphy by global index and lacked a netns check. The v3
  mailing-list patch further states the failure mode: BSS scan data can
  continue being copied from a wiphy after it moved to another netns.
- Step 1.4 Record: This is a hidden security/correctness fix, not a
  cleanup. It fixes a namespace isolation race in a multi-call netlink
  dump.

**Phase 2: Diff Analysis**
- Step 2.1 Record: One file changed, `net/wireless/nl80211.c`; commit
  stat is 12 insertions. One function changed:
  `nl80211_prepare_wdev_dump()`. Scope is single-file surgical.
- Step 2.2 Record: Before, continuation path did
  `wiphy_idx_to_wiphy(cb->args[0] - 1)`, accepted the wiphy, then
  searched `wdev_list`. After, it returns `-ENODEV` if
  `!net_eq(wiphy_net(wiphy), sock_net(cb->skb->sk))`.
- Step 2.3 Record: Bug category is race / namespace isolation /
  information disclosure. A wiphy can move netns between dumpit calls
  via `NL80211_CMD_SET_WIPHY_NETNS`.
- Step 2.4 Record: Fix quality is high: one predicate and clean error
  return before taking `wiphy.mtx`. Regression risk is low; it only
  rejects a continuation whose object no longer belongs to the caller’s
  netns.

**Phase 3: Git History**
- Step 3.1 Record: Current checkout is shallow; `git blame` attributed
  the region to a shallow boundary, so that blame is not reliable.
  Pickaxe history found the continuation-by-global-wiphy-index pattern
  in old history, including `c319d50bfcf67` (`nl80211: fix another
  nl80211_fam.attrbuf race`), contained by `v3.11-rc6`. Netns support
  for cfg80211/nl80211 was introduced by `463d018323851`, contained by
  `v2.6.32-rc1`.
- Step 3.2 Record: No `Fixes:` tag, so no tagged introducer to follow.
- Step 3.3 Record: Fetched wireless history shows the candidate
  immediately follows companion commit `15994bb0cbb8f` (`wifi: nl80211:
  require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS`). No
  intermediate commit between them.
- Step 3.4 Record: Author has only these two fetched wireless commits.
  Committer is Johannes Berg, the nl80211/cfg80211 maintainer.
- Step 3.5 Record: No compile dependency on the companion commit, but
  logical/security context is stronger if `15994bb0cbb8f` is backported
  too.

**Phase 4: Mailing List / External Research**
- Step 4.1 Record: `b4 dig -c 79240f3f6d766...` found the v3 patch at
  the provided `patch.msgid.link` URL. `b4 dig -a` found v1 and v3; `b4
  am` showed v1, v2, v3. v3 cover says no code changes since v2 and that
  Johannes review caused comment/trailer cleanup.
- Step 4.2 Record: `b4 dig -w` shows Johannes Berg, `linux-wireless`,
  and `linux-kernel` were included.
- Step 4.3 Record: No syzbot/bugzilla report. The series cover and patch
  body provide the bug explanation and patch 1 includes a mac80211_hwsim
  reproducer for the related `SET_WIPHY_NETNS` privilege path.
- Step 4.4 Record: This is patch 2/2 in a series. Patch 1 hardens
  target-netns capability checks; patch 2 fixes dump continuation
  filtering.
- Step 4.5 Record: Lore WebFetch was blocked by Anubis; WebSearch did
  not find stable-specific discussion.

**Phase 5: Code Semantic Analysis**
- Step 5.1 Record: Modified function is `nl80211_prepare_wdev_dump()`.
- Step 5.2 Record: Exact callers are `nl80211_dump_station()`,
  `nl80211_dump_mpath()`, `nl80211_dump_mpp()`, `nl80211_dump_scan()`,
  and `nl80211_dump_survey()`.
- Step 5.3 Record: Key callees are `__cfg80211_wdev_from_attrs()`,
  `wiphy_idx_to_wiphy()`, `wiphy_net()`, `sock_net()`, `net_eq()`,
  `wiphy_to_rdev()`, and list walk over `wiphy.wdev_list`.
- Step 5.4 Record: `NL80211_CMD_GET_SCAN` maps to `nl80211_dump_scan()`
  and has no admin flag in the ops entry; `NL80211_CMD_SET_WIPHY_NETNS`
  maps to `nl80211_wiphy_netns()` with `GENL_UNS_ADMIN_PERM`.
- Step 5.5 Record: Similar dump paths `nl80211_dump_wiphy()` and
  `nl80211_dump_interface()` already filter by `net_eq(wiphy_net(...),
  sock_net(skb->sk))` each iteration.

**Phase 6: Stable Tree Analysis**
- Step 6.1 Record: The affected continuation code exists in checked tags
  `v6.19`, `v6.18`, `v6.12`, `v6.6`, `v6.1`, `v5.15`, `v5.10`, `v5.4`,
  `v4.19`, and `v4.14`.
- Step 6.2 Record: Modern stable trees have the same helper shape. Older
  trees such as `v5.4` and `v4.14` have different function
  signatures/locking, so they may need small backport adjustment.
- Step 6.3 Record: Searches in checked stable tags did not find this
  candidate or the companion commit already present.

**Phase 7: Subsystem Context**
- Step 7.1 Record: Subsystem is wireless cfg80211/nl80211, an important
  networking control-plane subsystem.
- Step 7.2 Record: `net/wireless/nl80211.c` is actively maintained;
  fetched wireless history shows this series was taken through Johannes
  Berg’s wireless tree.

**Phase 8: Impact / Risk**
- Step 8.1 Record: Affected users are systems using wireless devices
  with nl80211 netns movement support, including delegated/container
  wireless setups and mac80211_hwsim.
- Step 8.2 Record: Trigger requires a multi-call dump and a wiphy netns
  move between invocations. The related series verifies an unprivileged
  userns path when the caller has a delegated `WIPHY_FLAG_NETNS_OK`
  wiphy.
- Step 8.3 Record: Failure mode is namespace isolation breach / cross-
  netns scan-result exposure, not a crash. Severity: HIGH due
  security/isolation impact.
- Step 8.4 Record: Benefit is high for isolation correctness; risk is
  very low because the patch adds one local validation and returns an
  existing error code.

**Phase 9: Final Synthesis**
- Step 9.1 Record: Evidence for backporting: real namespace isolation
  bug, old code present across stable trees, small surgical fix,
  maintainer-applied, aligns with existing dump filtering. Evidence
  against: companion patch should also be considered, and older trees
  may require minor backport edits. Unresolved: no independent `Tested-
  by`; stable-specific lore discussion could not be fetched.
- Step 9.2 Record: Stable rules: obviously correct yes; fixes real bug
  yes; important issue yes due namespace isolation/security; small and
  contained yes; no new API/feature yes; applies cleanly or with minor
  adjustment depending on tree.
- Step 9.3 Record: No exception category applies.
- Step 9.4 Record: Backport is warranted, preferably together with
  `15994bb0cbb8f` for the complete netns hardening series.

## Verification
- Phase 1: Parsed `git show 79240f3f6d766...` and b4 v3 patch text;
  verified tags and commit body.
- Phase 2: Verified diff is one hunk in `nl80211_prepare_wdev_dump()`
  with 12 insertions.
- Phase 3: Ran `git blame`, pickaxe history, `git show` for
  `c319d50bfcf67`, `463d018323851`, companion `15994bb0cbb8f`, and
  fetched wireless history.
- Phase 4: Ran `b4 dig`, `b4 dig -a`, `b4 dig -w`, `b4 am` for v1/v2/v3,
  saved/read mbox; WebFetch to lore was blocked by Anubis.
- Phase 5: Verified callers and relevant ops entries in
  `net/wireless/nl80211.c`.
- Phase 6: Used `git grep` across stable tags to confirm affected code
  exists and checked stable logs for absence of the candidate.
- Phase 8: Severity is based on verified patch text plus code paths; no
  build or runtime test was run.

**YES**

 net/wireless/nl80211.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b94231c8441c4..ce3121b1c3319 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1146,6 +1146,18 @@ static int nl80211_prepare_wdev_dump(struct netlink_callback *cb,
 			rtnl_unlock();
 			return -ENODEV;
 		}
+
+		/*
+		 * The first invocation validated the wdev's netns against
+		 * the caller via __cfg80211_wdev_from_attrs(). The wiphy
+		 * may have moved netns between dumpit invocations (via
+		 * NL80211_CMD_SET_WIPHY_NETNS), so re-check here.
+		 */
+		if (!net_eq(wiphy_net(wiphy), sock_net(cb->skb->sk))) {
+			rtnl_unlock();
+			return -ENODEV;
+		}
+
 		*rdev = wiphy_to_rdev(wiphy);
 		*wdev = NULL;
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] KVM: arm64: nv: Consider the DS bit when translating TCR_EL2

[Sasha Levin]

From: Wei-Lin Chang <weilin.chang@arm.com>

[ Upstream commit 8d9b9d985ad3a81c751a6b97edaf1d3c0780af7c ]

When running an nVHE L1, TCR_EL2 is mapped to TCR_EL1. Writes to the
register are trapped and written to TCR_EL1 after a translation.
Booting an nVHE L1 with 52-bit VA isn't working because the translation
was ignoring the DS bit set by the guest, hence causing repeating level
0 faults. Add it in the translation function.

Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
Link: https://patch.msgid.link/20260505144735.1496530-1-weilin.chang@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Stable Backport Analysis

### Phase 1: Commit Message Forensics

Step 1.1 Record: Subsystem is `KVM: arm64: nv`; action verb is
“Consider”; intent is to preserve the `DS` bit when translating
`TCR_EL2` into `TCR_EL1` for nested virtualization.

Step 1.2 Record: Tags present are:
- `Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>`
- `Link: https://patch.msgid.link/20260505144735.1496530-1-
  weilin.chang@arm.com`
- `Signed-off-by: Marc Zyngier <maz@kernel.org>`

No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
or `Cc: stable@vger.kernel.org` tags are present.

Step 1.3 Record: The bug is that an nVHE L1 guest using 52-bit VA cannot
boot because trapped writes to `TCR_EL2` are translated to `TCR_EL1`
without carrying over the guest’s `DS` bit. The recorded failure mode is
repeated level 0 faults. No affected kernel version is stated in the
message. Root cause is an incomplete EL2-to-EL1 TCR translation.

Step 1.4 Record: This is not hidden as cleanup; it is a direct
correctness fix for guest boot failure.

### Phase 2: Diff Analysis

Step 2.1 Record: One file changed:
`arch/arm64/include/asm/kvm_nested.h`, 1 insertion, 0 deletions.
Function modified: `translate_tcr_el2_to_tcr_el1()`. Scope is a single-
file surgical fix.

Step 2.2 Record: Before, `translate_tcr_el2_to_tcr_el1()` preserved
`TBI`, physical size, granule, cacheability, shareability, and `T0SZ`,
but ignored `TCR_EL2_DS`. After, it adds `TCR_DS` to the EL1 value when
`TCR_EL2_DS` is set. This affects the normal path where KVM programs the
physical EL1 `TCR` while running an nVHE L1.

Step 2.3 Record: Bug category is logic/correctness. The specific
mechanism is a missing architectural bit translation: `TCR_EL2_DS` is
bit 32, while `TCR_EL1.DS` is bit 59, so it cannot be preserved by the
existing mask-copy operations and must be explicitly mapped.

Step 2.4 Record: The fix is obviously correct and minimal. Regression
risk is very low: it only sets `TCR_EL1.DS` when the guest already set
the corresponding `TCR_EL2.DS` bit.

### Phase 3: Git History Investigation

Step 3.1 Record: `git blame` shows `translate_tcr_el2_to_tcr_el1()` was
introduced by `3606e0b2e46216` (“KVM: arm64: nv: Add non-VHE-EL2->EL1
translation helpers”), first contained in `v6.8-rc1`. The buggy omission
is long-lived relative to current stable trees.

Step 3.2 Record: No `Fixes:` tag is present, so there is no tagged
introducer to follow. The blame commit above is the practical introducer
of the incomplete translation.

Step 3.3 Record: Recent history of `arch/arm64/include/asm/kvm_nested.h`
shows active nested-virt development, including 52-bit PA/LPA2 related
work. No prerequisite patch for this one-line change was identified
beyond the existing definitions already present in stable tags checked.

Step 3.4 Record: Wei-Lin Chang has multiple recent `KVM: arm64`/nested-
virt commits. Marc Zyngier, listed in `MAINTAINERS` as a KVM/arm64
maintainer, committed the patch.

Step 3.5 Record: `git log --grep=translate_tcr_el2_to_tcr_el1` found no
other commits mentioning the helper. The patch applies cleanly to the
current checked-out stable tree with `git apply --check`.

### Phase 4: Mailing List And External Research

Step 4.1 Record: `b4 dig -c 8d9b9d985ad3a81c751a6b97edaf1d3c0780af7c`
found the original submission at the provided patch link. `b4 dig -a`
found only v1. The thread includes Marc Zyngier’s “Applied to fixes”
reply and no objections.

Step 4.2 Record: `b4 dig -w` shows the patch was sent to `linux-arm-
kernel`, `kvmarm`, `linux-kernel`, and KVM/arm64 maintainers/reviewers
including Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, and Will Deacon.

Step 4.3 Record: No separate bug report or syzbot report was found in
the commit tags or b4 thread. The commit message itself gives the
observed boot failure.

Step 4.4 Record: The patch is standalone, single-patch v1; no multi-
patch series dependency was found.

Step 4.5 Record: No stable-specific discussion was found. WebFetch to
lore was blocked by Anubis, but b4 successfully retrieved the thread.

### Phase 5: Code Semantic Analysis

Step 5.1 Record: Modified function: `translate_tcr_el2_to_tcr_el1()`.

Step 5.2 Record: Callers found:
- `locate_register()` maps `TCR_EL2` to `TCR_EL1` with this translation
  for loaded nVHE hyp context.
- `__sysreg_restore_vel2_state()` restores nVHE virtual EL2 state by
  translating guest `TCR_EL2` before writing physical `SYS_TCR`.

Step 5.3 Record: Key callees are `tcr_el2_ps_to_tcr_el1_ips()` and the
bit definitions/macros for `TCR_EL2_*` and `TCR_*`. The function has no
allocation, locking, or complex side effects; it returns a composed
register value.

Step 5.4 Record: Reachability is verified through guest sysreg traps:
`ESR_ELx_EC_SYS64` goes to `kvm_handle_sys_reg()`, then
`perform_access()`, then the `TCR_EL2` descriptor with `access_rw()`,
then `vcpu_write_sys_reg()`, which applies `loc.xlate()` when the mapped
register is loaded. This is reachable by an L1 guest using EL2.

Step 5.5 Record: Similar translation helpers exist for `SCTLR_EL2`,
`CPTR_EL2`, and `TTBR0_EL2`; this patch fixes the missing special-case
bit in the TCR helper. `TCR_EL1.DS` and `TCR_EL2.DS` are at different
bit positions, so the existing mask copying cannot handle it.

### Phase 6: Stable Tree Analysis

Step 6.1 Record: The helper commit is present in checked tags `v6.12`,
`v6.18`, `v6.19`, and `v7.0`. The LPA2 DS field definitions are also
present in those tags. The 52-bit PA helper commit checked is present in
`v6.18`, `v6.19`, and `v7.0`, but not `v6.12`.

Step 6.2 Record: Expected backport difficulty is low for trees with this
helper. `b4 am` reported “Base: applies clean to current tree”, and `git
apply --check` succeeded on the current `v7.0.9` checkout.

Step 6.3 Record: No related fix for “Consider the DS bit” is in `v7.0`
or `v7.0.9`; `git merge-base --is-ancestor` returned absent for the
candidate in those tags.

### Phase 7: Subsystem And Maintainer Context

Step 7.1 Record: Subsystem is KVM/arm64 nested virtualization.
Criticality is IMPORTANT: it affects ARM64 KVM users running nested
virtualization with nVHE L1 guests and 52-bit VA.

Step 7.2 Record: Subsystem is actively maintained; recent
`arch/arm64/kvm` history contains multiple KVM/arm64 fixes, and
`MAINTAINERS` marks KVM/arm64 as maintained by Marc Zyngier and Oliver
Upton.

### Phase 8: Impact And Risk Assessment

Step 8.1 Record: Affected population is platform/config-specific: ARM64
KVM users with nested virtualization and an nVHE L1 using 52-bit VA.

Step 8.2 Record: Trigger is booting or running such an nVHE L1 with
`TCR_EL2.DS` set. The path is guest-triggerable through EL2 sysreg
writes, but only for VMs configured with nested virtualization support.

Step 8.3 Record: Failure mode is repeated level 0 faults and failed L1
boot. Severity is HIGH for affected users because the guest hypervisor
cannot boot correctly.

Step 8.4 Record: Benefit is high for affected nested virtualization
users. Risk is very low: one line, no API change, no locking, no data
structure change, and only changes behavior when the guest sets
`TCR_EL2_DS`.

### Phase 9: Final Synthesis

Step 9.1 Record:
Evidence for backporting:
- Fixes a real boot failure for nVHE L1 guests with 52-bit VA.
- One-line, contained architectural bit translation.
- Existing definitions verify this is a required bit-position mapping,
  not a feature addition.
- Maintainer applied it to the KVM/arm64 fixes branch.
- Applies cleanly to the current stable checkout.
- Buggy helper exists in active stable-era tags checked.

Evidence against backporting:
- No `Fixes:`, `Reported-by:`, `Tested-by:`, or explicit stable tag.
- Affected population is narrower than core KVM users.
- Exact user-visible 52-bit VA nested scenario was not fully proven for
  every older stable branch, especially `v6.12`.

Unresolved:
- I did not build-test or boot-test.
- I did not verify clean application to every stable branch
  individually.
- WebFetch could not read lore directly due Anubis, though b4 retrieved
  the thread.

Step 9.2 Stable rules:
1. Obviously correct and tested? Obviously correct by code inspection;
   no explicit Tested-by found.
2. Fixes a real bug? Yes, commit message and code path verify a missing
   required register bit translation causing L1 boot failure.
3. Important issue? Yes, boot failure/repeated translation faults for
   affected nested virtualization guests.
4. Small and contained? Yes, 1 line in one helper.
5. No new features/APIs? Yes.
6. Can apply to stable trees? Yes for current checked stable tree;
   likely straightforward for trees containing this helper.

Step 9.3 Exception category: None. This is not a device ID, quirk, DT,
build, or documentation exception; it is a direct bug fix.

Step 9.4 Decision: Backport. The fix is small, technically clear, and
corrects an architectural register translation bug that prevents a
supported nested-virtualization configuration from booting.

## Verification

- Phase 1: Parsed `git show` for candidate
  `8d9b9d985ad3a81c751a6b97edaf1d3c0780af7c`; confirmed subject, body,
  and tags.
- Phase 2: Inspected exact diff; confirmed 1 insertion in
  `translate_tcr_el2_to_tcr_el1()`.
- Phase 2: Verified `TCR_EL2_DS` is bit 32 in
  `arch/arm64/include/asm/kvm_arm.h`.
- Phase 2: Verified `TCR_EL1.DS` is bit 59 in `arch/arm64/tools/sysreg`
  and `TCR_DS` aliases it in `arch/arm64/include/asm/pgtable-hwdef.h`.
- Phase 3: `git blame` identified `3606e0b2e46216` as introducer of the
  helper.
- Phase 3: `git describe --contains 3606e0b2e46216` reported first
  containment at `v6.8-rc1`.
- Phase 3: `git log` on affected files found related nested-virt/LPA2
  activity and no required adjacent patch.
- Phase 4: `b4 dig -c` found the original patch by patch-id.
- Phase 4: `b4 dig -a` found only v1.
- Phase 4: `b4 dig -w` confirmed KVM/arm64 maintainers and lists were
  included.
- Phase 4: `b4 mbox -c -o -` retrieved Marc Zyngier’s applied-to-fixes
  reply.
- Phase 5: `rg` found callers in `sys_regs.c` and `hyp/vhe/sysreg-sr.c`.
- Phase 5: Read trap path from `handle_exit.c`, `sys_regs.c`, and
  `arm.c`; verified guest sysreg traps can reach the translation.
- Phase 6: `git merge-base --is-ancestor` confirmed the helper and DS
  definitions are present in `v6.12`, `v6.18`, `v6.19`, and `v7.0`.
- Phase 6: `git apply --check` succeeded on the current stable checkout.
- Phase 7: Read `MAINTAINERS`; confirmed Marc Zyngier and Oliver Upton
  maintain KVM/arm64.
- Phase 8: Failure mode verified from commit message and code path;
  exact boot reproduction was not run.
- UNVERIFIED: No build or boot test was performed.
- UNVERIFIED: Clean application to every individual stable branch was
  not tested.
- UNVERIFIED: Exact impact on older stable trees lacking later 52-bit PA
  helper work was not fully established.

**YES**

 arch/arm64/include/asm/kvm_nested.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h
index 091544e6af442..dc2957662ff20 100644
--- a/arch/arm64/include/asm/kvm_nested.h
+++ b/arch/arm64/include/asm/kvm_nested.h
@@ -23,6 +23,7 @@ static inline u64 tcr_el2_ps_to_tcr_el1_ips(u64 tcr_el2)
 static inline u64 translate_tcr_el2_to_tcr_el1(u64 tcr)
 {
 	return TCR_EPD1_MASK |				/* disable TTBR1_EL1 */
+	       ((tcr & TCR_EL2_DS) ? TCR_DS : 0) |
 	       ((tcr & TCR_EL2_TBI) ? TCR_TBI0 : 0) |
 	       tcr_el2_ps_to_tcr_el1_ips(tcr) |
 	       (tcr & TCR_EL2_TG0_MASK) |
-- 
2.53.0

[PATCH AUTOSEL 7.0] docs: hwmon: sy7636a: fix temperature sysfs attribute name

[Sasha Levin]

From: Chen-Shi-Hong <eric039eric@gmail.com>

[ Upstream commit 51f57607e30bee282a1d40845f89a311cbb26481 ]

The hwmon sysfs naming convention uses
temp[1-*]_input for temperature channels.

Documentation/hwmon/sy7636a-hwmon.rst currently documents
temp0_input, while the driver uses the standard hwmon
temperature channel interface.

Update the documentation to use temp1_input.

Signed-off-by: Chen-Shi-Hong <eric039eric@gmail.com>
Link: https://lore.kernel.org/r/20260514154108.1937-1-eric039eric@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record: Subsystem is `docs: hwmon: sy7636a`. Action verb is `fix`.
Claimed intent is to correct the documented temperature sysfs attribute
name from `temp0_input` to `temp1_input`.

Record: Tags present: `Signed-off-by: Chen-Shi-Hong
<eric039eric@gmail.com>`, `Link:
https://lore.kernel.org/r/20260514154108.1937-1-eric039eric@gmail.com`,
`Signed-off-by: Guenter Roeck <linux@roeck-us.net>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.

Record: The commit describes a documentation bug: the sy7636a hwmon
document names `temp0_input`, while hwmon temperature channels are named
`temp[1-*]_input`. No crash, data corruption, or runtime bug is claimed.

Record: This is not a hidden runtime bug fix. It is an explicit
documentation correctness fix.

## Phase 2: Diff Analysis
Record: One file changed: `Documentation/hwmon/sy7636a-hwmon.rst`, 1
insertion and 1 deletion. No functions modified. Scope is a single-file
documentation-only surgical fix.

Record: Before, the document told users to read `temp0_input`. After, it
tells users to read `temp1_input`. No normal/error/init runtime path
changes.

Record: Bug category is documentation/API-description correctness.
Verified against `Documentation/hwmon/sysfs-interface.rst`, which
documents `temp[1-*]_input`, and `drivers/hwmon/hwmon.c`, where
temperature attributes use `temp%d_input` with base index `1`.

Record: Fix quality is obviously correct and minimal. Runtime regression
risk is zero because no code changes.

## Phase 3: Git History Investigation
Record: `git blame` shows `temp0_input` was introduced by
`de34a40532507` when the sy7636a hwmon driver/doc was added. Ancestry
checks show that commit is not in `v5.17` but is in `v5.18`, so the
documentation bug exists from v5.18 onward where the driver exists.

Record: No `Fixes:` tag is present, so there was no Fixes target to
follow.

Record: Related file history on `origin/master`: `51f57607e30be` doc
attribute fix, `2f88425ef590b` regulator-enable leak fix,
`68c2a8b59d231` sensor description doc fix, `80038a758b7fc` alias
addition, `5b5d8ae019543` constification, `a96f688b4e446` underline
warning fix, `de34a40532507` driver addition. This patch is standalone
for trees with the current doc context.

Record: Author history under hwmon/doc paths shows only this commit from
Chen-Shi-Hong in the checked history. Guenter Roeck, the hwmon
maintainer, committed/applied it.

Record: No functional dependencies. For older stable trees that do not
contain `68c2a8b59d231`, the exact patch context differs and needs a
trivial manual backport.

## Phase 4: Mailing List And External Research
Record: `b4 dig -c 51f57607e30be` found the original submission at
`https://patch.msgid.link/20260514154108.1937-1-eric039eric@gmail.com`.

Record: `b4 dig -a` found only v1 of a single-patch series. No newer
unapplied revision found.

Record: `b4 dig -w` showed recipients included Chen-Shi-Hong, Guenter
Roeck, Jonathan Corbet, Shuah Khan, `linux-hwmon`, `linux-doc`, and
`linux-kernel`.

Record: The b4-fetched thread contains Guenter Roeck replying “Applied.”
No NAKs, objections, or stable-specific nomination were found in that
thread. Lore `WebFetch` was blocked by Anubis, but `b4` successfully
retrieved the thread.

## Phase 5: Code Semantic Analysis
Record: No code functions are modified.

Record: Manual code tracing verified the documentation claim:
`drivers/hwmon/sy7636a-hwmon.c` registers `HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT)`. `drivers/hwmon/hwmon.c` formats temperature attributes
with `temp%d_input`, and `hwmon_attr_base()` returns `1` for temperature
sensors. Therefore the first temperature channel is `temp1_input`.

Record: Callers/callees are not applicable to the patch because it
changes documentation only. The affected “path” is users reading the
hwmon documentation.

Record: Similar pattern check found the generic hwmon documentation and
many hwmon docs use `temp1_input`, supporting the correction.

## Phase 6: Stable Tree Analysis
Record: `v5.15` does not contain `Documentation/hwmon/sy7636a-hwmon.rst`
or `drivers/hwmon/sy7636a-hwmon.c`, so the patch is not applicable
there.

Record: `v6.1`, `v6.6`, and `v6.12` contain the sy7636a driver and the
wrong `temp0_input` documentation. `v7.0` contains the wrong attribute
name with the newer “external NTC” text.

Record: The exact patch applies cleanly to the current
`stable/linux-7.0.y` checkout. It does not apply cleanly to `v6.1` or
`v6.6` because the surrounding description text differs before the later
doc description fix; a trivial one-line context-adjusted backport is
needed there.

Record: No alternate fix for this exact documentation bug was found in
local stable history.

## Phase 7: Subsystem Context
Record: Subsystem is hwmon documentation. Criticality is low for
runtime, but it documents a userspace-visible sysfs ABI path for sy7636a
hardware users.

Record: The sy7636a hwmon files have low churn and only a handful of
targeted fixes since introduction.

## Phase 8: Impact And Risk
Record: Affected population is sy7636a hardware users and anyone writing
scripts or instructions based on
`Documentation/hwmon/sy7636a-hwmon.rst`.

Record: Trigger is reading/following the documentation. If followed
literally, users look for a non-existent `temp0_input` instead of the
actual `temp1_input`.

Record: Failure severity is LOW: documentation/user guidance bug, not a
kernel crash or data corruption issue.

Record: Benefit is modest but real: correct stable documentation for a
userspace-visible hwmon attribute. Risk is effectively zero: one
documentation line, no code, no ABI change.

## Phase 9: Final Synthesis
Evidence for backporting: verified documentation is wrong; verified
driver/core generate `temp1_input`; patch is one-line documentation-
only; hwmon maintainer applied it; documentation fixes are an allowed
stable exception with no runtime regression risk.

Evidence against backporting: it is not a serious runtime bug, security
issue, crash, or data corruption fix. Older stable trees before the
sensor-description doc change need a trivial context adjustment.

Stable rules checklist: obviously correct, yes; fixes a real
documentation bug, yes; important runtime issue, no; small and
contained, yes; no new feature/API, yes; stable applicability, yes for
v7.0 cleanly and older applicable with minor backport adjustment.
Exception category: documentation fix.

Verification:
- [Phase 1] Parsed exact commit `51f57607e30be` from `origin/master` and
  confirmed tags/message.
- [Phase 2] Inspected exact diff: one doc line changes `temp0_input` to
  `temp1_input`.
- [Phase 3] `git blame` confirmed `temp0_input` came from
  `de34a40532507`; ancestry checks place it first in v5.18.
- [Phase 4] `b4 dig` found the original patch; `b4 dig -a` showed v1
  only; `b4 dig -w` showed appropriate hwmon/doc recipients; b4 mbox
  showed Guenter replied “Applied.”
- [Phase 5] Read sy7636a driver and hwmon core; confirmed first
  temperature channel is named `temp1_input`.
- [Phase 6] Checked `v5.15`, `v6.1`, `v6.6`, `v6.12`, and `v7.0`
  content; exact patch applies to current 7.0 stable, not directly to
  v6.1/v6.6 due context.
- [Phase 8] Confirmed no runtime code changes, so regression risk is
  zero.

This should be backported where the sy7636a documentation exists, with
trivial context adjustment for older trees as needed.

**YES**

 Documentation/hwmon/sy7636a-hwmon.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/hwmon/sy7636a-hwmon.rst b/Documentation/hwmon/sy7636a-hwmon.rst
index 0143ce0e5db76..03d866aba6e81 100644
--- a/Documentation/hwmon/sy7636a-hwmon.rst
+++ b/Documentation/hwmon/sy7636a-hwmon.rst
@@ -22,5 +22,5 @@ The following sensors are supported
 sysfs-Interface
 ---------------
 
-temp0_input
+temp1_input
 	- Temperature of external NTC (milli-degree C)
-- 
2.53.0

[PATCH AUTOSEL 7.0] ALSA: hda/realtek: ALC269 fixup for Lenovo Yoga Pro 7 15ASH111 audio

[Sasha Levin]

From: Jackie Dong <xy-jackie@139.com>

[ Upstream commit 83dca2530fb3ba63f47bad339d890bc30aa06ab5 ]

Volume control for the speakers on the Lenovo Yoga Pro 7 15ASH11 laptop
doesn't work.
The DAC routing is the same as on the ThinkPad X1 Gen7 function, so reuse
the alc285_fixup_thinkpad_x1_gen7 to get it working.

Signed-off-by: Jackie Dong <xy-jackie@139.com>
Link: https://patch.msgid.link/20260514153940.7320-1-xy-jackie@139.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
Phase 1 Record:
1. Subject: subsystem `ALSA: hda/realtek`; action `fixup`; intent is to
   fix Lenovo Yoga Pro 7 15ASH11 speaker volume control.
2. Tags: `Signed-off-by: Jackie Dong`, `Link:
   https://patch.msgid.link/20260514153940.7320-1-xy-jackie@139.com`,
   `Signed-off-by: Takashi Iwai`. No `Fixes`, `Reported-by`, `Tested-
   by`, `Reviewed-by`, or stable Cc tag.
3. Body: the reported bug is that speaker volume control does not work
   on Lenovo Yoga Pro 7 15ASH11. Root cause explanation given: DAC
   routing matches the ThinkPad X1 Gen7 routing case, so the existing
   routing fixup is reused.
4. Hidden bug fix: yes. Although phrased as a “fixup”, this is a
   hardware-specific quirk correcting broken speaker mixer/routing
   behavior.

Phase 2 Record:
1. Inventory: one file, `sound/hda/codecs/realtek/alc269.c`; one line
   added to `alc269_fixup_tbl`; single-file surgical hardware quirk.
2. Hunk behavior: before, PCI SSID `17aa:38fc` had no matching Realtek
   fixup entry. After, it maps to `ALC245_FIXUP_BASS_HP_DAC`.
3. Bug mechanism: hardware workaround / audio codec quirk. Verified
   `ALC245_FIXUP_BASS_HP_DAC` calls `alc285_fixup_thinkpad_x1_gen7`,
   which overrides DAC routing for NID `0x17`, sets preferred DAC pairs,
   and renames confusing volume controls.
4. Fix quality: obviously small and contained. Regression risk is very
   low because matching is limited to Lenovo PCI SSID `17aa:38fc`.

Phase 3 Record:
1. Blame: the added line is from candidate commit `83dca2530fb3b`;
   adjacent Lenovo quirk-table entries mostly come from earlier Realtek
   table history. Candidate is contained in `v7.1-rc4`.
2. Fixes tag: none, so no introducing commit to follow.
3. Related file history: recent `alc269.c` history is dominated by
   similar Realtek laptop quirk fixes. Related Lenovo Yoga Pro 7 quirks
   exist for 14IMH9 and 14IAH10.
4. Author history: Jackie Dong has this one Realtek commit in the
   checked history. Takashi Iwai committed it; `MAINTAINERS` lists
   Takashi Iwai as SOUND maintainer.
5. Dependencies: `ALC245_FIXUP_BASS_HP_DAC` was introduced by
   `e347430182492` in mainline and exists in `stable/linux-7.0.y`;
   `stable/linux-6.19.y` has an equivalent backport `3c756e813f212`.
   Older checked stable branches lack that symbol and need a
   dependency/backport adjustment.

Phase 4 Record:
1. `b4 dig -c 83dca2530fb3b` found the original thread at the supplied
   patch URL.
2. `b4 dig -a` found v1 and v2; v2 is the committed version. The v2
   change was “Use `ALC245_FIXUP_BASS_HP_DAC` instead of creating a new
   quirk.”
3. `b4 dig -w` showed ALSA maintainers/lists and Lenovo contact were
   included.
4. Saved thread shows Takashi Iwai replied “Applied now”, with only a
   minor subject-line modification. No NAKs or risk objections were
   present in the matched thread.
5. Lore WebFetch searches were blocked by Anubis; WebSearch found
   related Yoga Pro audio issues but no additional specific 15ASH11
   report. Stable-list WebFetch was also blocked.

Phase 5 Record:
1. Modified object: `alc269_fixup_tbl` static quirk table.
2. Callers: `alc269_probe()` calls `snd_hda_pick_fixup()` with
   `alc269_fixup_tbl`; `alc269_probe()` is installed via
   `alc269_codec_ops`; ALC245 is listed in `snd_hda_id_alc269`.
3. Callees/effects: `snd_hda_pick_fixup()` matches PCI SSID first, then
   selects the fixup ID. `snd_hda_apply_fixup(...PRE_PROBE)` applies it
   before auto-parse.
4. Reachability: reachable during HDA codec probe on systems with
   Realtek ALC245/compatible hardware and PCI SSID `17aa:38fc`; normal
   boot/device initialization path.
5. Similar patterns: the table contains many Lenovo and other laptop
   Realtek quirks; `ALC245_FIXUP_BASS_HP_DAC` is already used for
   Minisforum V3 SE.

Phase 6 Record:
1. Stable presence: `stable/linux-7.0.y` and `stable/linux-6.19.y`
   contain the generic fixup but lack the new `17aa:38fc` entry.
   `stable/linux-6.18.y` and older checked branches lack
   `ALC245_FIXUP_BASS_HP_DAC`, though they do have ALC245 support and
   the underlying ThinkPad routing helper.
2. Backport difficulty: clean/simple for 7.0.y and 6.19.y. Older
   branches need either the generic fixup dependency or a small
   equivalent backport, and 6.12.y/older use
   `sound/pci/hda/patch_realtek.c` rather than the split path.
3. Related stable fixes: searches of 7.0.y and 6.19.y found no existing
   15ASH11 quirk.

Phase 7 Record:
1. Subsystem: ALSA HDA Realtek codec driver, driver-specific but common
   laptop audio path; criticality is important for affected hardware,
   not core-wide.
2. Activity: recent history shows many similar Realtek laptop quirk
   fixes, so this fits active subsystem practice.

Phase 8 Record:
1. Affected users: owners of Lenovo Yoga Pro 7 15ASH11 with PCI SSID
   `17aa:38fc`.
2. Trigger: normal audio use after codec probe; users see speaker volume
   control not working. No verified security or crash trigger.
3. Severity: medium functional regression/hardware enablement issue; not
   a panic/corruption bug.
4. Risk-benefit: benefit is high for the affected laptop; risk is very
   low because the change is a single SSID-scoped quirk using an
   existing fixup.

Phase 9 Record:
1. Evidence for: real user-visible audio control failure, hardware-
   specific quirk exception, one-line scoped change, existing fixup
   reused, ALSA maintainer applied, v2 incorporated review feedback.
2. Evidence against: not a crash/security/data-corruption fix; older
   stable branches may need prerequisite/backport adjustment.
3. Stable rules: obviously correct yes; fixes real user-visible bug yes;
   important issue yes under hardware quirk/workaround policy; small and
   contained yes; no new API yes; applies cleanly to trees with existing
   `ALC245_FIXUP_BASS_HP_DAC`, otherwise needs minor dependency
   handling.
4. Exception category: hardware-specific audio codec quirk. Decision:
   backport.

## Verification
- [Phase 1] `git show --format=fuller 83dca2530fb3b` verified subject,
  body, tags, author, committer, and one-line diff.
- [Phase 2] Diff verified one insertion in `alc269_fixup_tbl`:
  `SND_PCI_QUIRK(0x17aa, 0x38fc, ..., ALC245_FIXUP_BASS_HP_DAC)`.
- [Phase 3] `git blame origin/master -L 7762,7768` verified the
  candidate line attribution.
- [Phase 3] `git describe --contains 83dca2530fb3b` verified inclusion
  in `v7.1-rc4`.
- [Phase 3] `git log -S"ALC245_FIXUP_BASS_HP_DAC"` verified the generic
  fixup came from `e347430182492`.
- [Phase 4] `b4 dig -c`, `-a`, `-w`, and saved mbox verified the v1/v2
  thread, recipients, and Takashi’s “Applied now” reply.
- [Phase 5] Reads of `alc269.c` and `auto_parser.c` verified probe-time
  PCI SSID matching and fixup application.
- [Phase 6] Stable branch checks verified 7.0.y and 6.19.y have the
  generic fixup and lack `17aa:38fc`; older checked branches lack the
  generic fixup symbol.
- [Phase 8] Failure mode is verified from the commit body: speaker
  volume control does not work. No crash/security impact was verified.

This should be backported, with dependency/backport adjustment for trees
that do not yet have `ALC245_FIXUP_BASS_HP_DAC`.

**YES**

 sound/hda/codecs/realtek/alc269.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 7e0289a1a1ca7..4e0885c1fc496 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7722,6 +7722,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x38df, "Y990 YG DUAL", ALC287_FIXUP_TAS2781_I2C),
 	SND_PCI_QUIRK(0x17aa, 0x38f9, "Thinkbook 16P Gen5", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
 	SND_PCI_QUIRK(0x17aa, 0x38fa, "Thinkbook 16P Gen5", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
+	SND_PCI_QUIRK(0x17aa, 0x38fc, "Lenovo Yoga Pro 7 15ASH11", ALC245_FIXUP_BASS_HP_DAC),
 	SND_PCI_QUIRK(0x17aa, 0x38fd, "ThinkBook plus Gen5 Hybrid", ALC287_FIXUP_TAS2781_I2C),
 	SND_PCI_QUIRK(0x17aa, 0x3902, "Lenovo E50-80", ALC269_FIXUP_DMIC_THINKPAD_ACPI),
 	SND_PCI_QUIRK(0x17aa, 0x390d, "Lenovo Yoga Pro 7 14ASP10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] ipv6: Implement limits on extension header parsing

[Sasha Levin]

From: Daniel Borkmann <daniel@iogearbox.net>

[ Upstream commit 3744b0964d5267c0b651bcd8f8c25db6bf4ccbac ]

ipv6_{skip_exthdr,find_hdr}() and ip6_{tnl_parse_tlv_enc_lim,
protocol_deliver_rcu}() iterate over IPv6 extension headers until they
find a non-extension-header protocol or run out of packet data. The
loops have no iteration counter, relying solely on the packet length
to bound them. For a crafted packet with 8-byte extension headers
filling a 64KB jumbogram, this means a worst case of up to ~8k
iterations with a skb_header_pointer call each. ipv6_skip_exthdr(),
for example, is used where it parses the inner quoted packet inside
an incoming ICMPv6 error:

  - icmpv6_rcv
    - checksum validation
    - case ICMPV6_DEST_UNREACH
      - icmpv6_notify
        - pskb_may_pull()       <- pull inner IPv6 header
        - ipv6_skip_exthdr()    <- iterates here
        - pskb_may_pull()
        - ipprot->err_handler() <- sk lookup

The per-iteration cost of ipv6_skip_exthdr itself is generally
light, but skb_header_pointer becomes more costly on reassembled
packets: the first ~1232 bytes of the inner packet are in the skb's
linear area, but the remaining ~63KB are in the frag_list where
skb_copy_bits is needed to read data.

Initially, the idea was to add a configurable limit via a new
sysctl knob with default 8, in line with knobs from commit
47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination
options"), but two reasons eventually argued against it:

- It adds to UAPI that needs to be maintained forever, and
  upcoming work is restricting extension header ordering anyway,
  leaving little reason for another sysctl knob
- exthdrs_core.c is always built-in even when CONFIG_IPV6=n,
  where struct net has no .ipv6 member, so the read site would
  need an ifdef'd fallback to a constant anyway

Therefore, just use a constant (IP6_MAX_EXT_HDRS_CNT). All four
extension header walking functions are now bound by this limit.

Note that the check in ip6_protocol_deliver_rcu() happens right
before the goto resubmit, such that we don't have to have a test
for ipv6_ext_hdr() in the fast-path.

There's an ongoing IETF draft-iurman-6man-eh-occurrences to enforce
IPv6 extension headers ordering and occurrence. The latter also
discusses security implications. As per RFC8200 section 4.1, the
occurrence rules for extension headers provide a practical upper
bound which is 8. In order to be conservative, let's define
IP6_MAX_EXT_HDRS_CNT as 12 to leave enough room for quirky setups.
In the unlikely event that this is still not enough, then we might
need to reconsider a sysctl.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
Link: https://patch.msgid.link/20260429154648.809751-1-daniel@iogearbox.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
This should be backported. It is a small IPv6 networking hardening/fix
for a reachable CPU-exhaustion path: several IPv6 extension-header
walkers were bounded only by packet length, allowing crafted packets
with many minimal 8-byte extension headers to force thousands of
iterations. The patch caps traversal at 12 headers, avoids new UAPI, and
was reviewed by IPv6/networking reviewers. Risk is mainly dropping
extremely exotic packets with more than 12 extension headers; the review
discussion explicitly considered that and settled on 12 as a
conservative compromise.

## Phase Walkthrough
Phase 1: Commit Message Forensics

Record 1.1: Subsystem `ipv6`; action verb `Implement limits`; claimed
intent is to bound IPv6 extension-header parsing loops.

Record 1.2: Tags found: `Signed-off-by: Daniel Borkmann`, `Reviewed-by:
Ido Schimmel`, `Reviewed-by: Eric Dumazet`, `Reviewed-by: Justin
Iurman`, `Link:
https://patch.msgid.link/20260429154648.809751-1-daniel@iogearbox.net`,
`Signed-off-by: Jakub Kicinski`. No `Fixes:`, no `Reported-by:`, no `Cc:
stable`.

Record 1.3: The body describes crafted 64KB packets with 8-byte
extension headers causing up to about 8k iterations, with costly
`skb_header_pointer()`/`skb_copy_bits()` on reassembled packets. Symptom
is CPU work amplification/DoS potential, not memory corruption or crash.
It identifies `icmpv6_rcv -> icmpv6_notify -> ipv6_skip_exthdr()` as a
concrete path.

Record 1.4: This is not disguised cleanup. It is a direct
correctness/security hardening fix: add a bound to previously unbounded
loops.

Phase 2: Diff Analysis

Record 2.1: Five files changed, 25 insertions: `include/net/dropreason-
core.h` +6, `include/net/ipv6.h` +3, `net/ipv6/exthdrs_core.c` +7,
`net/ipv6/ip6_input.c` +5, `net/ipv6/ip6_tunnel.c` +4. Modified
functions: `ipv6_skip_exthdr()`, `ipv6_find_hdr()`,
`ip6_protocol_deliver_rcu()`, `ip6_tnl_parse_tlv_enc_lim()`.

Record 2.2: Before, these loops stopped only at non-extension-header,
`NEXTHDR_NONE`, malformed/truncated packet data, fragment handling, or
protocol handler completion. After, each loop also stops/drops once
`IP6_MAX_EXT_HDRS_CNT` is exceeded.

Record 2.3: Bug category is logic/performance DoS hardening: missing
iteration bound in packet parser. It does not fix UAF/leak/race, but it
prevents attacker-controlled excessive parsing work.

Record 2.4: Fix quality is good: small, local counters, no locking or
lifetime changes, no new sysctl/API. Regression risk is limited to
rejecting packets with more than 12 traversed extension headers.

Phase 3: Git History Investigation

Record 3.1: `git blame` shows the relevant loops are old:
`ipv6_skip_exthdr()` loop traces to initial/early history with later
signature changes; `ipv6_find_hdr()` to v3.8-era code;
`ip6_protocol_deliver_rcu()` resubmit logic to v4.x/v5.0-era changes;
`ip6_tnl_parse_tlv_enc_lim()` exists from initial/older tunnel code with
later cleanups.

Record 3.2: No `Fixes:` tag, so no introducing commit to follow. I did
inspect referenced commit `47d3d7ac656a`, which added limits for Hop-by-
Hop/Destination TLV parsing and described similar DoS behavior.

Record 3.3: Recent file history shows related commit `076b8cad77aa9`
capped TLV scanning in `ip6_tnl_parse_tlv_enc_lim()`. This commit is
related but not a hard dependency for the outer extension-header-count
limit.

Record 3.4: Daniel Borkmann has recent related IPv6 limit work in the
same area. Commit was applied by Jakub Kicinski, and reviewed by Eric
Dumazet, Ido Schimmel, and Justin Iurman.

Record 3.5: No functional prerequisite was found for the core idea.
Older stable trees before `dropreason-core.h` will need a small backport
adjustment for the new drop reason, or can use an existing generic
reason.

Phase 4: Mailing List And External Research

Record 4.1: `b4 dig -c 3744b0964d5267c0b651bcd8f8c25db6bf4ccbac` found
`[PATCH net v5]` at the provided lore/patch.msgid link.

Record 4.2: `b4 dig -a` found v1 through v5. v1 added a sysctl and was
NAKed by Justin Iurman; v4 switched to a hard-coded limit; v5 reduced
the limit from 32 to 12.

Record 4.3: No `Reported-by` or bug-report link exists. Web/lore stable
search did not find a stable-specific request or objection.

Record 4.4: Related series context: review discussion referenced IETF
extension-header occurrence work; v5 was the latest and accepted
version.

Record 4.5: No stable mailing-list-specific discussion found. WebFetch
to lore was blocked/timed out, but `b4` successfully retrieved the
thread.

Phase 5: Code Semantic Analysis

Record 5.1: Key functions are `ipv6_skip_exthdr()`, `ipv6_find_hdr()`,
`ip6_protocol_deliver_rcu()`, `ip6_tnl_parse_tlv_enc_lim()`.

Record 5.2: `git grep` found many callers of `ipv6_skip_exthdr()` across
netfilter, XFRM/ESP, drivers, audit/security hooks, ICMPv6, and tunnel
code. `ipv6_find_hdr()` is used by netfilter/nftables, BPF, OVS, IPVS,
SRv6, drivers, and TC. `ip6_protocol_deliver_rcu()` is called from IPv6
input and UDP encapsulation resubmission. `ip6_tnl_parse_tlv_enc_lim()`
is called from GRE/tunnel paths.

Record 5.3: Key callees are `skb_header_pointer()`, `pskb_pull()`,
`pskb_may_pull()`, `raw6_local_deliver()`, `inet6_protos[]` dispatch,
and protocol handlers.

Record 5.4: Reachability is verified from IPv6 receive paths:
`ip6_input_finish()` calls `ip6_protocol_deliver_rcu()`, and
`icmpv6_notify()` calls `ipv6_skip_exthdr()` on quoted inner packets.
These are network packet processing paths.

Record 5.5: Similar prior pattern exists in `47d3d7ac656a` for TLV
count/length limits and in `076b8cad77aa9` for tunnel TLV scanning.

Phase 6: Stable Tree Analysis

Record 6.1: The four key functions exist in checked tags `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, and `v6.19`. Thus the affected code
shape exists across active LTS/stable ranges.

Record 6.2: Expected backport difficulty: clean or minor for newer
trees; minor rework for pre-`dropreason-core.h` trees because
`include/net/dropreason-core.h` is absent in `v5.10`, `v5.15`, and
`v6.1`.

Record 6.3: No alternate stable-specific fix for this exact extension-
header traversal count was found. Related TLV-limiting commits address
adjacent, not identical, loops.

Phase 7: Subsystem Context

Record 7.1: Subsystem is IPv6 networking, criticality IMPORTANT to CORE
for IPv6-enabled systems because packet receive, ICMPv6, netfilter,
tunnel, and driver offload paths call these helpers.

Record 7.2: Subsystem is active; recent history shows multiple
IPv6/tunnel/drop-reason changes, but the unbounded parsing loops
themselves are longstanding.

Phase 8: Impact And Risk

Record 8.1: Affected users are IPv6-enabled systems, especially systems
exposed to crafted IPv6 traffic or using IPv6 tunnels/netfilter paths.

Record 8.2: Trigger is a crafted IPv6 packet chain with many small
extension headers, especially costly when parsed from
fragmented/reassembled skb data. Network reachability depends on
filtering and IPv6 deployment.

Record 8.3: Failure mode is CPU work amplification/DoS risk, not crash
or corruption. Severity: HIGH for exposed IPv6 hosts because it is
remote packet-triggered parser amplification; not CRITICAL because no
verified panic, data loss, or privilege escalation was found.

Record 8.4: Benefit is high: caps an attacker-controlled loop in common
networking code. Risk is low-to-medium: packets with more than 12
traversed extension headers may now be rejected, but reviewers
explicitly judged 12 conservative relative to RFC/IETF occurrence
expectations.

Phase 9: Final Synthesis

Record 9.1: Evidence for backporting: small 25-line fix; real attacker-
controlled parser amplification; network receive reachability verified;
reviewed by networking experts; v1 concerns were resolved; no new UAPI.
Evidence against: behavior change for extreme extension-header chains;
older trees need minor drop-reason backport adjustment; no syzbot/user
report/CVE. Unresolved: no benchmark for this exact v5 patch was found,
and no stable-specific discussion was found.

Record 9.2: Stable rules: obviously correct and reviewed, yes; fixes a
real bug, yes; important issue, yes as network DoS/performance
amplification; small and contained, yes; no new feature/API, yes; stable
apply, likely clean for newer trees and minor adjustment for older
trees.

Record 9.3: No automatic exception category applies. This is not a
device ID, quirk, DT, build, or documentation fix.

Record 9.4: The risk-benefit balance favors backporting.

## Verification
- [Phase 1] Parsed `git show 3744b0964d5267c0b651bcd8f8c25db6bf4ccbac`:
  verified subject, tags, message, and 25-line diff.
- [Phase 2] Read local code in `net/ipv6/exthdrs_core.c`,
  `net/ipv6/ip6_input.c`, `net/ipv6/ip6_tunnel.c`, and
  `include/net/ipv6.h`: verified loops were unbounded before the patch.
- [Phase 3] Ran `git blame` on changed regions: verified long-lived code
  and relevant commit ancestry.
- [Phase 3] Inspected `47d3d7ac656a` and `076b8cad77aa9`: verified
  similar prior DoS-limit work.
- [Phase 4] Ran `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and `b4 mbox`:
  verified v1-v5 history, reviewers, NAK of sysctl approach, and v5
  acceptance.
- [Phase 5] Ran caller searches for all four functions: verified broad
  IPv6/netfilter/tunnel/driver call surface.
- [Phase 6] Checked `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`:
  verified the affected functions exist; verified `dropreason-core.h` is
  absent before v6.6.
- [Phase 8] Verified reachable call paths in `icmpv6_notify()`,
  `ip6_input_finish()`, `udpv6_queue_rcv_skb()`, and `ip6_gre` tunnel
  code.
- UNVERIFIED: exact exploitability impact across real networks and exact
  CPU-cost benchmark for this specific v5 patch.
- UNVERIFIED: clean application to every currently maintained stable
  branch; older trees likely need minor drop-reason context adjustment.

**YES**

 include/net/dropreason-core.h | 6 ++++++
 include/net/ipv6.h            | 3 +++
 net/ipv6/exthdrs_core.c       | 7 +++++++
 net/ipv6/ip6_input.c          | 5 +++++
 net/ipv6/ip6_tunnel.c         | 4 ++++
 5 files changed, 25 insertions(+)

diff --git a/include/net/dropreason-core.h b/include/net/dropreason-core.h
index a7b7abd66e215..0b674a02665ab 100644
--- a/include/net/dropreason-core.h
+++ b/include/net/dropreason-core.h
@@ -102,6 +102,7 @@
 	FN(FRAG_TOO_FAR)		\
 	FN(TCP_MINTTL)			\
 	FN(IPV6_BAD_EXTHDR)		\
+	FN(IPV6_TOO_MANY_EXTHDRS)	\
 	FN(IPV6_NDISC_FRAG)		\
 	FN(IPV6_NDISC_HOP_LIMIT)	\
 	FN(IPV6_NDISC_BAD_CODE)		\
@@ -513,6 +514,11 @@ enum skb_drop_reason {
 	SKB_DROP_REASON_TCP_MINTTL,
 	/** @SKB_DROP_REASON_IPV6_BAD_EXTHDR: Bad IPv6 extension header. */
 	SKB_DROP_REASON_IPV6_BAD_EXTHDR,
+	/**
+	 * @SKB_DROP_REASON_IPV6_TOO_MANY_EXTHDRS: Number of IPv6 extension
+	 * headers in the packet exceeds IP6_MAX_EXT_HDRS_CNT.
+	 */
+	SKB_DROP_REASON_IPV6_TOO_MANY_EXTHDRS,
 	/** @SKB_DROP_REASON_IPV6_NDISC_FRAG: invalid frag (suppress_frag_ndisc). */
 	SKB_DROP_REASON_IPV6_NDISC_FRAG,
 	/** @SKB_DROP_REASON_IPV6_NDISC_HOP_LIMIT: invalid hop limit. */
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 53c5056508be5..ec95c11b8e434 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -90,6 +90,9 @@ struct ip_tunnel_info;
 #define IP6_DEFAULT_MAX_DST_OPTS_LEN	 INT_MAX /* No limit */
 #define IP6_DEFAULT_MAX_HBH_OPTS_LEN	 INT_MAX /* No limit */
 
+/* Hard limit on traversed IPv6 extension headers */
+#define IP6_MAX_EXT_HDRS_CNT		 12
+
 /*
  *	Addr type
  *	
diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c
index 49e31e4ae7b7f..9d06d487e8b10 100644
--- a/net/ipv6/exthdrs_core.c
+++ b/net/ipv6/exthdrs_core.c
@@ -73,6 +73,7 @@ int ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp,
 		     __be16 *frag_offp)
 {
 	u8 nexthdr = *nexthdrp;
+	int exthdr_cnt = 0;
 
 	*frag_offp = 0;
 
@@ -82,6 +83,8 @@ int ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp,
 
 		if (nexthdr == NEXTHDR_NONE)
 			return -1;
+		if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT))
+			return -1;
 		hp = skb_header_pointer(skb, start, sizeof(_hdr), &_hdr);
 		if (!hp)
 			return -1;
@@ -190,6 +193,7 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
 {
 	unsigned int start = skb_network_offset(skb) + sizeof(struct ipv6hdr);
 	u8 nexthdr = ipv6_hdr(skb)->nexthdr;
+	int exthdr_cnt = 0;
 	bool found;
 
 	if (fragoff)
@@ -216,6 +220,9 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
 			return -ENOENT;
 		}
 
+		if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT))
+			return -EBADMSG;
+
 		hp = skb_header_pointer(skb, start, sizeof(_hdr), &_hdr);
 		if (!hp)
 			return -EBADMSG;
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 2bcb981c91aa8..bbad1d4e6b854 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -363,6 +363,7 @@ INDIRECT_CALLABLE_DECLARE(int tcp_v6_rcv(struct sk_buff *));
 void ip6_protocol_deliver_rcu(struct net *net, struct sk_buff *skb, int nexthdr,
 			      bool have_final)
 {
+	int exthdr_cnt = IP6CB(skb)->flags & IP6SKB_HOPBYHOP ? 1 : 0;
 	const struct inet6_protocol *ipprot;
 	struct inet6_dev *idev;
 	unsigned int nhoff;
@@ -447,6 +448,10 @@ void ip6_protocol_deliver_rcu(struct net *net, struct sk_buff *skb, int nexthdr,
 				nexthdr = ret;
 				goto resubmit_final;
 			} else {
+				if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT)) {
+					SKB_DR_SET(reason, IPV6_TOO_MANY_EXTHDRS);
+					goto discard;
+				}
 				goto resubmit;
 			}
 		} else if (ret == 0) {
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 0b53488a92290..c1ca9b2806359 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -400,11 +400,15 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff *skb, __u8 *raw)
 	unsigned int nhoff = raw - skb->data;
 	unsigned int off = nhoff + sizeof(*ipv6h);
 	u8 nexthdr = ipv6h->nexthdr;
+	int exthdr_cnt = 0;
 
 	while (ipv6_ext_hdr(nexthdr) && nexthdr != NEXTHDR_NONE) {
 		struct ipv6_opt_hdr *hdr;
 		u16 optlen;
 
+		if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT))
+			break;
+
 		if (!pskb_may_pull(skb, off + sizeof(*hdr)))
 			break;
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] net: usb: cdc_ncm: add Apple Mac USB-C direct networking quirk

[Sasha Levin]

From: Alex Cheema <alex@exolabs.net>

[ Upstream commit a5148bc2fa27092862ac4b9e7b5c8340d60cff34 ]

Apple Silicon Macs expose two CDC NCM "private" data interfaces over
USB-C with VID:PID 0x05ac:0x1905 and product string "Mac". This is the
same protocol Apple already ships on iPhone (0x05ac:0x12a8) and iPad
(0x05ac:0x12ab) for RemoteXPC since iOS 17 -- both data interfaces lack
an interrupt status endpoint, so they rely on the FLAG_LINK_INTR-
conditional bind path introduced in commit 3ec8d7572a69 ("CDC-NCM: add
support for Apple's private interface").

The id_table currently has entries for iPhone and iPad but not for the
Mac. Without a match, cdc_ncm falls through to the generic CDC NCM
class-match entry, which uses the FLAG_LINK_INTR-having cdc_ncm_info
struct, so bind_common() fails on the missing status endpoint and no
netdev appears.

Add id_table entries for both interface numbers (0 and 2) of the Mac,
bound to the existing apple_private_interface_info driver_info.

Verified empirically on a Mac Studio M3 Ultra running macOS 26.5: when
a Mac is connected via USB-C, ioreg shows VID 0x05ac, PID 0x1905,
product string "Mac", with two NCM data interfaces at numbers 0 and 2.
The same PID is presented by all current Apple Silicon Mac models
(MacBook Pro/Air, Mac mini, Mac Studio across the M-series), mirroring
Apple's single-PID-per-family pattern from iPhone/iPad.

After this patch, plugging a Mac into a Linux host running the patched
kernel produces two enx... interfaces (one per data interface),
"ip -br link" lists them as UP, and standard userspace networking
(DHCP, NetworkManager shared mode, etc.) works without any modprobe
overrides or out-of-tree modules.

Signed-off-by: Alex Cheema <alex@exolabs.net>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260429175739.34426-1-alex@exolabs.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record: Subsystem is `net: usb: cdc_ncm`; action verb is `add`; intent
is to add an Apple Mac USB-C direct networking quirk/device match.

Record: Tags verified from `git show a5148bc2fa27` and `b4`:
`Signed-off-by: Alex Cheema <alex@exolabs.net>`, `Reviewed-by: Simon
Horman <horms@kernel.org>`, `Link:
https://patch.msgid.link/20260429175739.34426-1-alex@exolabs.net`,
`Signed-off-by: Jakub Kicinski <kuba@kernel.org>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, or `Cc: stable@vger.kernel.org`.

Record: The body describes a real functional failure: Apple Silicon Macs
with VID:PID `05ac:1905` expose private CDC NCM interfaces without
interrupt status endpoints. Without specific IDs, they match the generic
CDC NCM entry, use `cdc_ncm_info` with `FLAG_LINK_INTR`, fail endpoint
collection in `cdc_ncm_bind_common()`, and no netdev appears. The author
reports empirical testing on Mac Studio M3 Ultra.

Record: This is not a hidden memory-safety bug; it is an explicit
hardware ID/quirk fix for already-supported Apple private CDC NCM
handling.

### Phase 2: Diff Analysis
Record: One file changed: `drivers/net/usb/cdc_ncm.c`, 8 insertions, 0
deletions. No functions modified; only `cdc_devs[]` gets two entries.
Scope is single-file, surgical, device-ID style.

Record: Before: Mac interfaces could fall through to the generic CDC NCM
class entry using `cdc_ncm_info`. After: interface numbers `0` and `2`
for `05ac:1905` bind to existing `apple_private_interface_info`.

Record: Bug category is hardware quirk/device ID addition. The local
code verifies `apple_private_interface_info` omits `FLAG_LINK_INTR`,
while `cdc_ncm_info` includes it, and `cdc_ncm_bind_common()` rejects
devices with no status endpoint when `FLAG_LINK_INTR` is set.

Record: Fix quality is high: two exact USB interface-number matches,
reused existing driver_info, no new code path beyond selecting an
existing quirk. Regression risk is very low and limited to Apple VID:PID
`05ac:1905` interfaces `0` and `2`.

### Phase 3: Git History
Record: `git blame` shows `apple_private_interface_info` and the
iPhone/iPad Apple table entries were introduced by `3ec8d7572a69` in
2024.

Record: No `Fixes:` tag is present, but the commit body references
`3ec8d7572a69`; `git show` confirms that commit introduced Apple private
support and the conditional missing-status-endpoint handling.

Record: Recent `cdc_ncm.c` history shows unrelated
bounds/filtering/refactor changes; no prerequisite besides the
referenced Apple private support was found.

Record: `git log --author="Alex Cheema" -10 -- drivers/net/usb` found no
prior local subsystem commits by the author. The patch was reviewed by
Simon Horman and committed by Jakub Kicinski.

Record: Dependency found: stable trees must already contain
`3ec8d7572a69` or an equivalent `apple_private_interface_info`; older
trees without that support will not take this patch standalone.

### Phase 4: Mailing List And External Research
Record: `b4 dig -c a5148bc2fa27` found the original submission at the
patch.msgid.link URL.

Record: `b4 dig -c a5148bc2fa27 -a` found only v1; no later revision.

Record: `b4 dig -c a5148bc2fa27 -w` showed the right net/USB maintainers
and lists were included, including Oliver Neukum, Bjørn Mork, Jakub
Kicinski, netdev, and linux-usb.

Record: Full thread via `b4 mbox` had three messages: the patch, Simon
Horman’s `Reviewed-by`, and patchwork-bot saying Jakub applied it to
`netdev/net.git` as `a5148bc2fa27`. No NAKs or concerns observed.

Record: WebFetch of lore/stable was blocked by Anubis, so stable-
specific web discussion could not be independently checked. No stable
nomination appeared in the fetched thread.

### Phase 5: Code Semantic Analysis
Record: Modified object is `cdc_devs[]`; no function body changed.

Record: Call/reachability path verified: `cdc_ncm_driver.id_table =
cdc_devs`, `.probe = usbnet_probe`; `usbnet_probe()` reads
`prod->driver_info`, sets `dev->driver_info`, then calls `info->bind`,
which is `cdc_ncm_bind()`, which calls `cdc_ncm_bind_common()`.

Record: Key callees are endpoint discovery and bind setup in
`cdc_ncm_bind_common()`, especially the verified endpoint check
requiring status only when `FLAG_LINK_INTR` is set.

Record: User reachability is USB device enumeration/probe when an
affected Mac is connected to a Linux host. This is not syscall-triggered
by an unprivileged local user; it is hardware-triggered.

Record: Similar pattern found: existing iPhone/iPad Apple entries
already bind private interfaces to `apple_private_interface_info`.

### Phase 6: Stable Tree Analysis
Record: `git merge-base --is-ancestor 3ec8d7572a69 <tag>` verified
`3ec8d7572a69` is absent from `v5.15`, `v6.1`, `v6.6`, `v6.9`, and
`v6.10`, but present in `v6.11`, `v6.12`, and `v7.0`.

Record: `git show <tag>:drivers/net/usb/cdc_ncm.c | rg ...` verified
`v6.11+` have `apple_private_interface_info` and iPhone/iPad Apple
entries, but not the Mac `0x1905` entries.

Record: `git apply --check` succeeded against the current `7.0.5` tree.
Backport should be clean for trees with the same Apple-private support;
older trees need the prerequisite and are not standalone targets.

Record: No alternate related stable fix was found locally.

### Phase 7: Subsystem Context
Record: Subsystem is USB networking driver code, under
`drivers/net/usb`. Criticality is important for users of this hardware,
not core/universal.

Record: `scripts/get_maintainer.pl -f drivers/net/usb/cdc_ncm.c`
confirmed the patch was sent to the relevant USB CDC Ethernet and
networking maintainers/lists. Recent `drivers/net/usb` history shows
active maintenance.

### Phase 8: Impact And Risk
Record: Affected users are Linux hosts connecting to Apple Silicon Macs
via USB-C direct CDC NCM networking.

Record: Trigger is plugging in the matching Mac USB device. The failure
is likely whenever the unsupported `05ac:1905` private interfaces are
exposed and lack the interrupt status endpoint, based on the commit body
and verified bind logic.

Record: Failure mode is functional loss: no netdev appears. Severity is
medium by generic bug severity, but it fits the stable exception for new
device IDs/hardware quirks.

Record: Benefit is high for affected hardware users: direct networking
works without overrides/out-of-tree modules. Risk is very low: two
exact-match USB ID entries selecting existing behavior.

### Phase 9: Final Synthesis
Evidence for backporting: it is a classic stable-acceptable hardware
quirk/device ID addition; it fixes a verified bind failure mechanism; it
is tiny and contained; it reuses existing Apple private CDC NCM support;
it was reviewed and applied by netdev maintainership; it applies cleanly
to the current stable-style tree.

Evidence against backporting: it is not a crash/security/data-corruption
fix, and it is not standalone for stable trees older than `v6.11` unless
`3ec8d7572a69` is also present.

Stable rules checklist:
1. Obviously correct and tested: yes; exact ID entries, author-tested,
   reviewer accepted.
2. Fixes a real bug: yes; no netdev appears for matching hardware.
3. Important issue: yes under hardware support/quirk exception, though
   not critical severity.
4. Small and contained: yes, 8 insertions in one table.
5. No new APIs/features: yes, no API or new driver; only IDs for
   existing behavior.
6. Applies to stable: yes for trees with Apple private support; older
   trees need prerequisite handling.

Exception category: new USB device ID / hardware quirk for an existing
driver path.

## Verification
- [Phase 1] Parsed `git show a5148bc2fa27`: confirmed subject, body,
  trailers, reviewed-by, link, and maintainer signoff.
- [Phase 2] Read `drivers/net/usb/cdc_ncm.c`: confirmed `cdc_ncm_info`
  has `FLAG_LINK_INTR`, `apple_private_interface_info` does not, and
  `cdc_ncm_bind_common()` fails missing status endpoints when
  `FLAG_LINK_INTR` is set.
- [Phase 3] `git blame` confirmed Apple private support and existing
  Apple IDs came from `3ec8d7572a69`.
- [Phase 3] `git show 3ec8d7572a69` confirmed it introduced Apple
  private CDC NCM support and the conditional endpoint check.
- [Phase 4] `b4 dig -c a5148bc2fa27`: found the original lore
  submission.
- [Phase 4] `b4 dig -a`: only v1 found.
- [Phase 4] `b4 dig -w`: confirmed relevant maintainers/lists were
  included.
- [Phase 4] `b4 mbox`: confirmed Simon Horman review and patchwork
  application by Jakub Kicinski.
- [Phase 5] `rg` and `ReadFile` traced `cdc_devs[]` to `usbnet_probe()`
  to `cdc_ncm_bind()` to `cdc_ncm_bind_common()`.
- [Phase 6] Tag ancestry checks confirmed prerequisite exists in
  `v6.11+` but not `v6.10` and older checked tags.
- [Phase 6] `git apply --check` confirmed clean apply to current tree.
- UNVERIFIED: Independent confirmation that all current Apple Silicon
  Macs use PID `0x1905`; this is author-stated in the patch, not
  independently verified here.
- UNVERIFIED: Stable mailing-list search via WebFetch was blocked by
  Anubis; no stable-specific discussion was visible in the fetched `b4`
  thread.

This should be backported to stable trees that already contain the Apple
private CDC NCM support, because it is a low-risk hardware ID/quirk fix
that restores networking for real hardware.

**YES**

 drivers/net/usb/cdc_ncm.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index bb9929727eb93..0223a172851ec 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -2012,6 +2012,14 @@ static const struct usb_device_id cdc_devs[] = {
 		.driver_info = (unsigned long)&apple_private_interface_info,
 	},
 
+	/* Mac */
+	{ USB_DEVICE_INTERFACE_NUMBER(0x05ac, 0x1905, 0),
+		.driver_info = (unsigned long)&apple_private_interface_info,
+	},
+	{ USB_DEVICE_INTERFACE_NUMBER(0x05ac, 0x1905, 2),
+		.driver_info = (unsigned long)&apple_private_interface_info,
+	},
+
 	/* Ericsson MBM devices like F5521gw */
 	{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
 		| USB_DEVICE_ID_MATCH_VENDOR,
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] net: usb: r8152: add TRENDnet TUC-ET2G v2.0

[Sasha Levin]

From: Aleksander Jan Bajkowski <olek2@wp.pl>

[ Upstream commit f93836b236773862e9ee268a82e3614caf77ea01 ]

The TRENDnet TUC-ET2G V2.0 is an RTL8156B based 2.5G Ethernet controller.

Add the vendor and product ID values to the driver. This makes Ethernet
work with the adapter.

Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Birger Koblitz <mail@birger-koblitz.de>
Link: https://patch.msgid.link/20260430213435.21821-1-olek2@wp.pl
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `net: usb: r8152`; action verb `add`; claimed
intent: add TRENDnet TUC-ET2G v2.0 USB device ID so the existing `r8152`
driver binds to the adapter.

Step 1.2 Record: Tags present:
- `Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>`
- `Reviewed-by: Andrew Lunn <andrew@lunn.ch>`
- `Reviewed-by: Birger Koblitz <mail@birger-koblitz.de>`
- `Link: https://patch.msgid.link/20260430213435.21821-1-olek2@wp.pl`
- `Signed-off-by: Jakub Kicinski <kuba@kernel.org>`

No `Fixes:`, `Reported-by:`, `Tested-by:`, or `Cc:
stable@vger.kernel.org` tag was present. Absence of those tags is not a
negative signal here.

Step 1.3 Record: The body describes a real hardware support failure:
TRENDnet TUC-ET2G V2.0 is RTL8156B-based, but without its USB
vendor/product ID in `rtl8152_table`, Ethernet does not work with that
adapter. No affected kernel versions are named.

Step 1.4 Record: This is not a hidden memory/synchronization bug. It is
an explicit new USB device ID addition to an existing driver, which is a
stable exception category.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `drivers/net/usb/r8152.c`, `+1/-0`.
No function body changed. The modified object is `rtl8152_table`. Scope:
single-file surgical device-ID addition.

Step 2.2 Record: Before the change, the table contained TRENDnet
`0xe02b` but not `0xe02c`, so USB matching would not select `r8152` for
`20f4:e02c`. After the change, `USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02c)`
is matched by the driver table used by both `rtl8152_driver.id_table`
and `rtl8152_cfgselector_driver.id_table`.

Step 2.3 Record: Bug category is hardware enablement / USB device ID
addition. It does not touch error paths, locking, reference counts,
memory safety, or public APIs.

Step 2.4 Record: The fix is obviously correct if the ID maps to RTL8156B
hardware. I verified the device identity externally: WikiDevi lists TUC-
ET2G v2.0R as USB ID `20f4:e02c` with Realtek RTL8156B, and TRENDnet’s
own support page confirms the TUC-ET2G v2 product. Regression risk is
very low; existing devices are unaffected unless another incompatible
device uses the same exact USB ID.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` around the table showed the existing
TRENDnet `0xe02b` entry came from `15fba71533bc` and the new `0xe02c`
line comes from `f93836b23677`. The table terminator dates back to
`ac718b69301c`. The “bug” is not introduced by a code commit; it is the
absence of a product-specific ID for existing supported silicon.

Step 3.2 Record: No `Fixes:` tag, so there is no introducing commit to
follow.

Step 3.3 Record: Recent related history includes `15fba71533bc` adding
the first TRENDnet TUC-ET2G ID and `dc9c67820f81` adding a TP-Link ID.
The candidate is standalone on trees that already have
`VENDOR_ID_TRENDNET`.

Step 3.4 Record: The author has at least one prior `r8152` device-ID
commit, `848b09d53d92` for Dell Alienware AW1022z. The patch was
reviewed by Andrew Lunn and Birger Koblitz and applied by Jakub
Kicinski.

Step 3.5 Record: Dependency found: `VENDOR_ID_TRENDNET` was introduced
by `15fba71533bc`, and `git merge-base --is-ancestor` confirms that
commit is an ancestor of `f93836b23677`. Mainline release tags `v5.15`,
`v6.1`, `v6.6`, `v6.12`, and `v6.19` lack `VENDOR_ID_TRENDNET`, while
`v7.0-rc3` has it. Older stable backports therefore need either
`15fba71533bc` first or a small backport adjustment adding `#define
VENDOR_ID_TRENDNET 0x20f4`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f93836b23677` found the original patch
submission by patch-id. `b4 dig -a` reported the accepted one-patch
submission at `20260430213435.21821-1-olek2@wp.pl`; `b4` also found an
earlier identical submission from
`20260426214909.3426105-1-olek2@wp.pl`. The earlier thread had Andrew
Lunn asking for repost after netdev opened and giving his `Reviewed-by`.
No NAK or technical objection found.

Step 4.2 Record: `b4 dig -w` showed the patch was sent to netdev
maintainers/lists and USB networking lists, including Andrew Lunn, David
Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Realtek contacts,
`linux-usb`, `netdev`, and `linux-kernel`. `MAINTAINERS` confirms those
netdev maintainers for `NETWORKING DRIVERS`, and `drivers/net/usb/` is
under `USB NETWORKING DRIVERS`.

Step 4.3 Record: No separate bug report or `Reported-by` tag. External
hardware verification found TUC-ET2G v2.0R as `20f4:e02c` / RTL8156B.

Step 4.4 Record: This is a single-patch submission, not a multi-patch
fix series. The only practical dependency for older trees is the
TRENDnet vendor define from the prior TUC-ET2G ID commit.

Step 4.5 Record: WebFetch to lore was blocked by Anubis. WebSearch did
not find stable-specific discussion for `f93836b23677` or the patch
message ID. No stable objection found.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: No functions modified. Modified data structure:
`rtl8152_table`.

Step 5.2 Record: `rtl8152_table` is referenced by
`MODULE_DEVICE_TABLE(usb, rtl8152_table)`, `rtl8152_driver.id_table`,
and `rtl8152_cfgselector_driver.id_table`. Matching devices enter the
normal USB probe path via `rtl8152_probe`.

Step 5.3 Record: The relevant probe path checks vendor-specific
interface class, `rtl_check_vendor_ok`, `rtl8152_get_version`, then
calls `rtl8152_probe_once`. The config selector uses `__rtl_get_hw_ver`.
This patch adds no new calls.

Step 5.4 Record: Reachability is USB device enumeration: plugging in or
booting with the adapter attached. It is not a remote or syscall-
triggered security issue.

Step 5.5 Record: Similar pattern exists throughout the same table for
Realtek, Lenovo, TP-Link, D-Link, Dell, ASUS, and earlier TRENDnet IDs.
`git log -S'0xe02c'` found no prior `0xe02c` entry in the checked
history.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked mainline release tags `v5.15`, `v6.1`, `v6.6`,
`v6.12`, and `v6.19`: all contain `0x8156` and RTL8156B version
handling, but not the TRENDnet `0xe02c` ID. This means the supported
chipset path exists in those releases, but the product-specific match is
missing.

Step 6.2 Record: Backport difficulty is low. It applies cleanly to trees
with `VENDOR_ID_TRENDNET` / `0xe02b`; older bases need a minor
context/define adjustment or the prior TRENDnet ID patch.

Step 6.3 Record: No alternate local fix for `0xe02c` was found. No
stable-specific replacement fix was verified.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is `drivers/net/usb`, USB Ethernet networking
driver. Criticality: driver-specific, important for users of this
hardware, not core-kernel-wide.

Step 7.2 Record: The file is active, with recent `r8152` feature and fix
commits, but this change is isolated to the USB ID table and does not
depend on recent functional refactoring except the vendor
define/backport context noted above.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems with TRENDnet TUC-ET2G V2.0
and `CONFIG_USB_RTL8152`.

Step 8.2 Record: Trigger is common for affected users: adapter insertion
or boot with the adapter connected. Not remotely triggerable; physical
USB access is needed.

Step 8.3 Record: Failure mode is device non-binding / Ethernet
unavailable. Severity is not crash/security-critical, but it is a real
user-visible hardware functionality failure.

Step 8.4 Record: Benefit is high for affected stable users because it
makes the adapter work with an already-supported RTL8156B driver. Risk
is very low: one table entry, no behavior change for existing IDs.

## Phase 9: Final Synthesis
Evidence for backporting:
- New USB device ID for existing driver and already-supported RTL8156B
  silicon.
- Fixes a real user-visible failure: Ethernet does not work with this
  adapter.
- One-line, single-file, no API or behavior change for existing
  hardware.
- Reviewed by Andrew Lunn and Birger Koblitz; applied by Jakub Kicinski.
- Hardware identity verified as TRENDnet `20f4:e02c` / RTL8156B.

Evidence against backporting:
- Not a crash, data corruption, security, or deadlock fix.
- Older stable bases may need the prior `VENDOR_ID_TRENDNET` definition
  or a tiny backport adjustment.

Unresolved:
- I did not verify every active stable branch state directly; I verified
  mainline release tags and the dependency relationship. Lore WebFetch
  was blocked, but `b4` successfully fetched the thread.

Stable rules checklist:
1. Obviously correct and tested? Yes, one matching-table entry;
   reviewed; hardware ID verified.
2. Fixes a real bug affecting users? Yes, adapter does not bind/work
   without the ID.
3. Important issue? Yes under the stable “new device IDs” exception,
   though not crash/security.
4. Small and contained? Yes, one insertion in one file.
5. No new features/APIs? Yes, no API or behavioral change except
   matching this USB device.
6. Can apply to stable trees? Yes with low difficulty; older trees may
   need `VENDOR_ID_TRENDNET`.

Exception category: New USB device ID for an existing driver. This is a
standard stable-appropriate exception.

## Verification
- [Phase 1] Parsed commit `f93836b236773862e9ee268a82e3614caf77ea01`
  with `git show`; confirmed subject, body, tags, and `+1/-0` diff.
- [Phase 2] Compared `git diff f938^..f938`; confirmed only `{
  USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02c) }` is added.
- [Phase 3] Ran `git blame` around `rtl8152_table`; confirmed existing
  `0xe02b` from `15fba71533bc` and new `0xe02c` from `f93836b23677`.
- [Phase 3] Ran `git merge-base --is-ancestor 15fba71533bc
  f93836b23677`; confirmed the vendor define dependency is in the
  candidate’s ancestry.
- [Phase 3] Checked release tags `v5.15`, `v6.1`, `v6.6`, `v6.12`,
  `v6.19`, `v7.0-rc3`, `v7.1-rc3`; confirmed older release tags have
  RTL8156/RTL_VER_13 support but lack TRENDnet IDs until `v7.0-rc3`.
- [Phase 4] Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; confirmed
  patch-id match, one-patch submission, recipients, and
  review/application thread.
- [Phase 4] Read full `b4 mbox` threads; confirmed Andrew Lunn review on
  repost request, Birger Koblitz review, and patchwork notification that
  Jakub applied it.
- [Phase 4] WebFetch to lore was blocked by Anubis; external GitHub
  commit fetch confirmed the commit metadata and diff.
- [Phase 4] WebFetch of WikiDevi and TRENDnet pages verified TUC-ET2G v2
  hardware identity; WikiDevi specifically listed USB ID `20f4:e02c` and
  RTL8156B.
- [Phase 5] Searched `rtl8152_table` references; confirmed use by
  `MODULE_DEVICE_TABLE`, `rtl8152_driver.id_table`, and
  `rtl8152_cfgselector_driver.id_table`.
- [Phase 5] Read `rtl8152_probe` and config selector code; confirmed
  affected path is USB enumeration/probe, with no changed runtime logic.
- [Phase 7] Checked `MAINTAINERS`; confirmed netdev maintainers and
  `drivers/net/usb/` list coverage.
- [Phase 8] Checked `drivers/net/usb/Kconfig`; confirmed affected
  configuration is `CONFIG_USB_RTL8152`.

This is exactly the kind of low-risk new USB ID addition stable trees
normally take.

**YES**

 drivers/net/usb/r8152.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0c83bbbea2e7c..0ac2b079e435c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -10055,6 +10055,7 @@ static const struct usb_device_id rtl8152_table[] = {
 	{ USB_DEVICE(VENDOR_ID_DELL,    0xb097) },
 	{ USB_DEVICE(VENDOR_ID_ASUS,    0x1976) },
 	{ USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02b) },
+	{ USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02c) },
 	{}
 };
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl

[Sasha Levin]

From: Mingyu Wang <25181214217@stu.xidian.edu.cn>

[ Upstream commit 617eb7c0961a8dfcfc811844a6396e406b2923ea ]

While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong
timeout value` warning was observed, accompanied by SMBus controller
state machine corruption.

The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of
10 ms. The user argument is checked against INT_MAX, but it is
subsequently multiplied by 10 before being passed to msecs_to_jiffies().

A malicious user can pass a large value (e.g., 429496729) that passes
the `arg > INT_MAX` check but overflows when multiplied by 10. This
results in a truncated 32-bit unsigned value that bypasses the
internal `(int)m < 0` check in `msecs_to_jiffies()`.

The truncated value is then assigned to `client->adapter->timeout`
(a signed 32-bit int), which is reinterpreted as a negative number.
When passed to wait_for_completion_timeout(), this negative value
undergoes sign extension to a 64-bit unsigned long, triggering the
`schedule_timeout` warning and causing premature returns. This leaves
the SMBus state machine in an unrecoverable state, constituting a
local Denial of Service (DoS).

Fix this by bounding the user argument to `INT_MAX / 10`.

Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
[wsa: move the comment as well]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `i2c: dev`; action verb `prevent`; intent is
to prevent integer overflow in the userspace `I2C_TIMEOUT` ioctl.

Step 1.2 Record: Tags are `Signed-off-by: Mingyu Wang
<25181214217@stu.xidian.edu.cn>` and `Signed-off-by: Wolfram Sang
<wsa+renesas@sang-engineering.com>` with maintainer edit note `[wsa:
move the comment as well]`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Reviewed-by:`, `Link:`, or `Cc: stable` tags were present.

Step 1.3 Record: The body describes a Syzkaller-found `schedule_timeout:
wrong timeout value` warning and SMBus state machine corruption after a
large userspace timeout causes overflow/truncation before storing into
signed `adapter->timeout`. Symptom is local DoS through bad timeout
behavior; root cause is validating `arg` before multiplying by 10.

Step 1.4 Record: This is not hidden cleanup; it is an explicit integer
overflow and local DoS fix.

### Phase 2: Diff Analysis
Step 2.1 Record: One file changed, `drivers/i2c/i2c-dev.c`; committed
diff is 5 insertions and 4 deletions due comment movement. Modified
function: `i2cdev_ioctl()`. Scope: single-file surgical fix.

Step 2.2 Record: Before, `I2C_TIMEOUT` accepted any `arg <= INT_MAX`,
then used `msecs_to_jiffies(arg * 10)`. After, it accepts only `arg <=
INT_MAX / 10`, so the 10 ms unit conversion cannot exceed signed 32-bit
range before assignment to `adapter->timeout`.

Step 2.3 Record: Bug category is integer overflow/truncation and type-
range validation. Broken mechanism: userspace-controlled timeout is
range-checked before scaling, but stored in `struct
i2c_adapter.timeout`, which is `int`.

Step 2.4 Record: Fix quality is high: one validation bound change, no
new API, no refactor. Regression risk is low; it rejects only extreme
timeout values that cannot be represented safely after the documented 10
ms scaling.

### Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the existing `arg > INT_MAX` guard
came from `6ebec961d59b` and the `arg * 10` timeout assignment/comment
came from `cd97f39b7cdf`. `git describe` places them at
`v5.0-rc2~14^2~1` and `v2.6.29-rc7~62^2~2`, respectively.

Step 3.2 Record: No `Fixes:` tag, so no tagged introducing commit to
follow. I still inspected `6ebec961d59b`, which originally fixed
negative retry/timeout values and was itself stable-tagged.

Step 3.3 Record: Recent upstream `drivers/i2c/i2c-dev.c` history shows
this candidate plus unrelated cleanup/fix commits; no prerequisite
series was identified.

Step 3.4 Record: `Mingyu Wang` has this one upstream `drivers/i2c`
commit in the checked history. Wolfram Sang committed it and is the I2C
maintainer in the patch flow.

Step 3.5 Record: No dependent commit found. The patch assumes the long-
existing `I2C_TIMEOUT` case and applies cleanly to the current `v7.0.5`
checkout.

### Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 617eb7c0961a8` found the original submission
at `https://patch.msgid.link/20260427025745.1100768-1-
25181214217@stu.xidian.edu.cn`. `b4 dig -a` found only v1. The submitted
patch was a one-line bound change; the committed version is the
maintainer-adjusted version with comment movement.

Step 4.2 Record: `b4 dig -w` shows recipients: Mingyu Wang, Wolfram
Sang, `linux-i2c@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.

Step 4.3 Record: No `Link:` or `Reported-by:` tag exists. Public web
searches did not find a syzkaller bug page for this exact issue; the
Syzkaller finding is verified only from the commit/patch text.

Step 4.4 Record: No multi-patch series found; standalone patch.

Step 4.5 Record: Stable-list WebFetch was blocked by lore Anubis, and
web search did not find stable-specific discussion. No evidence of
objections or NAKs was found in the b4-fetched mbox.

### Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `i2cdev_ioctl()`.

Step 5.2 Record: Call path is userspace ioctl on `/dev/i2c-*` through
`i2cdev_fops.unlocked_ioctl = i2cdev_ioctl`; compat ioctls fall back to
`i2cdev_ioctl()` for commands not handled specially, including
`I2C_TIMEOUT`.

Step 5.3 Record: Key callee is `msecs_to_jiffies()`, whose runtime
helper treats negative `unsigned int` values as infinite timeout. The
result is assigned to `struct i2c_adapter.timeout`, verified as `int`.

Step 5.4 Record: Buggy path is reachable from userspace with access to
an i2c-dev node. The corrupted timeout is then used by core retry loops
and many bus drivers, including paths using
`wait_for_completion_timeout()`.

Step 5.5 Record: Similar timeout use is widespread in `drivers/i2c`, but
this specific unchecked userspace scaling pattern was found in
`i2c-dev`.

### Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and
`v7.0`; all contain the vulnerable `arg > INT_MAX` plus
`msecs_to_jiffies(arg * 10)` pattern.

Step 6.2 Record: Expected backport difficulty is clean or trivial. `git
apply --check` succeeded on current `v7.0.5`; checked stable snippets
have matching context.

Step 6.3 Record: No alternate stable fix found by subject/phrase
searches in local git history.

### Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is I2C userspace character-device interface,
`drivers/i2c/i2c-dev.c`. Criticality: important, because it exposes bus
control to userspace and affects any system using `i2c-dev`.

Step 7.2 Record: Subsystem is mature but actively maintained. The
affected ioctl path is long-standing.

### Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems exposing `/dev/i2c-*` to
userspace, including embedded, hardware-management, and sensor-control
systems.

Step 8.2 Record: Trigger is setting `I2C_TIMEOUT` to a large value
through ioctl, then using affected I2C/SMBus transfer paths. It requires
access to the device node; no capability check is present in the ioctl
path itself.

Step 8.3 Record: Failure mode is at least a kernel `schedule_timeout:
wrong timeout value` warning and broken timeout behavior; commit text
reports SMBus controller state machine corruption and local DoS.
Severity: HIGH.

Step 8.4 Record: Benefit is high because it blocks a fuzzed, userspace-
reachable DoS class bug in maintained stable trees. Risk is very low
because the patch is one range check in one ioctl case.

### Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: real integer overflow,
Syzkaller-reported in commit text, userspace-reachable with i2c-dev
access, high-severity timeout corruption/DoS, tiny fix, maintainer-
applied, vulnerable code present in checked stable trees, clean apply to
`v7.0.5`. Evidence against: no public syzkaller link, no `Reported-
by`/`Tested-by`, and exact SMBus unrecoverable-state details were not
independently reproduced.

Step 9.2 Record: Stable rules: obviously correct yes; fixes real bug
yes; important issue yes, local DoS/bad kernel timeout path; small and
contained yes; no new features/APIs yes; stable applicability yes for
checked trees.

Step 9.3 Record: No exception category needed; this is a normal bug fix,
not device ID/quirk/DT/build/doc.

Step 9.4 Record: The technical merits strongly support stable
backporting.

## Verification
- Phase 1: Parsed `git show 617eb7c0961a8`; confirmed tags and absence
  of `Fixes:`, `Reported-by:`, `Link:`, and stable tag.
- Phase 2: Inspected committed diff; confirmed one-file change in
  `i2cdev_ioctl()`.
- Phase 3: `git blame` identified `6ebec961d59b` and `cd97f39b7cdf`;
  `git describe` placed them before all checked maintained stable trees.
- Phase 3: `git show 6ebec961d59b` confirmed prior timeout/retry
  negative-value fix and stable nomination.
- Phase 4: `b4 dig`, `b4 dig -a`, `b4 dig -w`, and mbox read found one
  v1 patch, proper I2C recipients, and no visible objections.
- Phase 4: WebFetch of lore was blocked by Anubis; stable-list
  discussion and public syzkaller report remain unverified.
- Phase 5: `rg` and file reads confirmed ioctl file operations, compat
  fallback, `msecs_to_jiffies()`, `adapter->timeout` as `int`, and
  downstream timeout uses.
- Phase 6: Checked `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`
  snippets; all contain the vulnerable pattern.
- Phase 6: `git apply --check` confirmed the upstream diff applies to
  current `v7.0.5`.
- Phase 8: `schedule_timeout()` source confirms negative timeout emits
  `wrong timeout value` and returns 0.

**YES**

 drivers/i2c/i2c-dev.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/i2c-dev.c b/drivers/i2c/i2c-dev.c
index 7bbe0263411eb..ccaac5e29f906 100644
--- a/drivers/i2c/i2c-dev.c
+++ b/drivers/i2c/i2c-dev.c
@@ -487,12 +487,13 @@ static long i2cdev_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
 		client->adapter->retries = arg;
 		break;
 	case I2C_TIMEOUT:
-		if (arg > INT_MAX)
+		/*
+		 * For historical reasons, user-space sets the timeout value in
+		 * units of 10 ms.
+		 */
+		if (arg > INT_MAX / 10)
 			return -EINVAL;
 
-		/* For historical reasons, user-space sets the timeout
-		 * value in units of 10 ms.
-		 */
 		client->adapter->timeout = msecs_to_jiffies(arg * 10);
 		break;
 	default:
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] powerpc/vmx: avoid KASAN instrumentation in enter_vmx_ops() for kexec

[Sasha Levin]

From: Sourabh Jain <sourabhjain@linux.ibm.com>

[ Upstream commit 38e989d504fc52900a3786b7144fb53cd67e0389 ]

The kexec sequence invokes enter_vmx_ops() via copy_page() with the MMU
disabled. In this context, code must not rely on normal virtual address
translations or trigger page faults.

With KASAN enabled, functions get instrumented and may access shadow
memory using regular address translation. When executed with the MMU
off, this can lead to page faults (bad_page_fault) from which the
kernel cannot recover in the kexec path, resulting in a hang.

The kexec path sets preempt_count to HARDIRQ_OFFSET before entering
the MMU-off copy sequence.

current_thread_info()->preempt_count = HARDIRQ_OFFSET
  kexec_sequence(..., copy_with_mmu_off = 1)
    -> kexec_copy_flush(image)
         copy_segments()
           -> copy_page(dest, addr)
	         bl enter_vmx_ops()
                   if (in_interrupt())
                     return 0
	         beq .Lnonvmx_copy

Since kexec sets preempt_count to HARDIRQ_OFFSET, in_interrupt()
evaluates to true and enter_vmx_ops() returns early.

As in_interrupt() (and preempt_count()) are always inlined, mark
enter_vmx_ops() with __no_sanitize_address to avoid KASAN
instrumentation and shadow memory access with MMU disabled, helping
kexec boot fine with KASAN enabled.

Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260407124349.1698552-2-sourabhjain@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record: subsystem `powerpc/vmx`; action verb `avoid`; intent is to
prevent KASAN instrumentation of `enter_vmx_ops()` when it is reached
from the kexec MMU-off copy path.

Record: tags parsed from the candidate message:
- `Reported-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Reviewed-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>`
- `Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>`
- `Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>`
- `Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>`
- `Link: https://patch.msgid.link/20260407124349.1698552-2-
  sourabhjain@linux.ibm.com`
- No `Fixes:` tag in this commit. Absence is not a negative signal.

Record: bug description from the message: `kexec_sequence()` may call
`copy_page()` with the MMU disabled; on PowerPC Book3S this can enter
`copypage_power7.S`, which calls `enter_vmx_ops()`. If KASAN instruments
`enter_vmx_ops()`, the instrumentation may access shadow memory using
normal virtual translation, which is invalid with MMU off and can cause
an unrecoverable `bad_page_fault`/hang in kexec.

Record: hidden bug fix: yes. Although phrased as “avoid
instrumentation,” this fixes a real boot/hang failure in the kexec/kdump
path under KASAN.

## Phase 2: Diff Analysis
Record: one file changed: `arch/powerpc/lib/vmx-helper.c`, with 8
insertions and 1 deletion in the fetched v3 patch. The only functional
change is changing `int enter_vmx_ops(void)` to `int
__no_sanitize_address enter_vmx_ops(void)`; the remaining additions are
explanatory comments.

Record: modified function: `enter_vmx_ops()`.

Record: before behavior: `enter_vmx_ops()` could be KASAN-instrumented.
During kexec with MMU off, the function first checks `in_interrupt()`
and should return `0`, but KASAN prologue/body instrumentation can run
before or around normal code and touch shadow memory.

Record: after behavior: `__no_sanitize_address` suppresses KASAN
instrumentation for this function, preserving the intended early return
path when `preempt_count` contains `HARDIRQ_OFFSET`.

Record: bug category: sanitizer/real-mode correctness bug causing kexec
hang. This is a crash/hang class fix, not a cleanup.

Record: fix quality: small, surgical, and low risk. It does not alter
normal logic, public API, data structures, or userspace-visible
behavior. The only behavioral effect is disabling KASAN instrumentation
for one helper that can run in an MMU-off path.

## Phase 3: Git History Investigation
Record: local `HEAD` is a stable release commit, not the candidate. `git
log --grep` on current history, `master`, and `power-next` did not find
the candidate commit locally, so there was no commit hash available for
`b4 dig -c`.

Record: `git blame` on current `arch/powerpc/lib/vmx-helper.c` shows the
unannotated `enter_vmx_ops()` present in the local tree; due this
repository’s history shape, blame attributes the original lines to a
merge/root history point, so the exact original introduction commit was
not verifiable locally.

Record: no candidate `Fixes:` tag to follow. The companion patch in the
same series has `Fixes: 2ab2d5794f14 ("powerpc/kasan: Disable address
sanitization in kexec paths")`; `git show` confirms that commit disabled
sanitization for PowerPC kexec real-mode paths in 2022.

Record: related recent local history: `6bc9c0a905228` changed VMX
usercopy flow and added export context around the same file. That
affects hunk context for older stable trees, but not the actual one-line
fix.

Record: author context: `git log --author="Sourabh Jain" --
arch/powerpc/...` shows multiple PowerPC kexec/crash/fadump commits.
`MAINTAINERS` lists Madhavan Srinivasan and Michael Ellerman as PowerPC
maintainers; Madhavan signed off the candidate.

Record: dependencies: no source-level prerequisite for the annotation
itself. Function `enter_vmx_ops()` and `__no_sanitize_address` exist in
checked stable tags. Functional completeness is best with the companion
patch fixing `KASAN_SANITIZE_core_$(BITS).o`, because review/test
discussion says both patches together make KASAN kexec succeed.

## Phase 4: Mailing List And External Research
Record: `b4 am` for message id
`20260407124349.1698552-2-sourabhjain@linux.ibm.com` fetched a v3 two-
patch series. It reported total patches: 2, current tree apply clean,
and DKIM signature valid for patch 2.

Record: `b4 am -c` checked for newer revisions and did not report a
newer v4. v3 appears to be the latest fetched revision.

Record: `b4 mbox` fetched the v3 thread. Patch 2 was addressed to
`linuxppc-dev` and CC’d PowerPC/kexec stakeholders including Michael
Ellerman, Madhavan Srinivasan, Mahesh Salgaonkar, Hari Bathini, Daniel
Axtens, Venkat Rao Bagalkote, Aboorva Devarajan, and Ritesh Harjani.

Record: `WebFetch` of lore URLs was blocked by Anubis, but `b4` and the
`yhbt.net` lore mirror provided the thread content.

Record: v2 review discussion verified:
- Ritesh Harjani reviewed patch 2 and said “LGTM,” granting `Reviewed-
  by`.
- Aboorva Devarajan reported an actual KASAN-enabled kexec hang on
  pseries PowerVM: system reached “kexec: Starting switchover sequence”
  and then hung.
- Aboorva tested that “with both the patches applied, kexec completes
  successfully with KASAN enabled.”
- v1 annotated both `enter_vmx_ops()` and `exit_vmx_ops()`; v2 removed
  `exit_vmx_ops()` annotation and added the explanatory comment. This
  shows review-driven narrowing of the fix.

Record: stable-specific discussion: Ritesh explicitly suggested `Cc:
stable@vger.kernel.org` for patch 1. I did not find a direct stable
nomination for patch 2, but patch 2 was reviewed and tested as part of
the same two-patch functional fix.

## Phase 5: Code Semantic Analysis
Record: modified function: `enter_vmx_ops()`.

Record: callers found by exact search:
- `arch/powerpc/lib/copypage_power7.S`
- `arch/powerpc/lib/memcpy_power7.S`
- `arch/powerpc/lib/memcmp_64.S`

Record: relevant kexec call chain verified in code:
`reboot(LINUX_REBOOT_CMD_KEXEC)` -> `kernel_kexec()` ->
`machine_kexec()` -> `default_machine_kexec()` -> `kexec_sequence()` ->
`kexec_copy_flush()` -> `copy_segments()` -> `copy_page()` ->
`copypage_power7.S` -> `enter_vmx_ops()`.

Record: key callees/logic in `enter_vmx_ops()`: `in_interrupt()`,
`preempt_disable()`, and `enable_kernel_altivec()`. In the kexec MMU-off
path, `default_machine_kexec()` sets
`current_thread_info()->preempt_count = HARDIRQ_OFFSET`, and
`include/linux/preempt.h` defines `in_interrupt()` via `irq_count()`,
which observes the hardirq bits.

Record: reachability: reachable from privileged kexec/kdump paths. It is
not unprivileged-user reachable, but kdump reliability is operationally
important.

Record: similar patterns: PowerPC already disables KASAN for sensitive
real-mode/interrupt code in multiple Makefiles and uses
`__no_sanitize_address` in PowerPC interrupt/stack code, so the
attribute is consistent with local practice.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Record: buggy code exists in stable tags checked: `v5.4`, `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.18`, `v6.19`, and `v7.0` all have
`enter_vmx_ops()` without `__no_sanitize_address`.

Record: the kexec `copy_segments()` -> `copy_page()` path and
`preempt_count = HARDIRQ_OFFSET` were verified in `v5.4`, `v5.10`,
`v5.15`, `v6.1`, and current/v7.0-era code.

Record: `copypage_power7.S` calls `enter_vmx_ops()` in `v5.4`, `v5.10`,
`v5.15`, and current code.

Record: `__no_sanitize_address` exists in compiler headers in checked
stable tags, including `v5.4`, `v5.10`, `v6.1`, `v6.6`, and current.

Record: backport difficulty: clean on current `7.0.y` per `git apply
--check` and `b4`. Older stable trees may need a tiny context adjustment
because `EXPORT_SYMBOL(exit_vmx_usercopy)` is not present in older
versions, but the actual function signature is present and the backport
is straightforward.

Record: related fixes already in stable: not verified as already
present; local stable tags checked do not contain the candidate
annotation.

## Phase 7: Subsystem And Maintainer Context
Record: subsystem is PowerPC architecture library/kexec path:
`arch/powerpc/lib` and `arch/powerpc/kexec`.

Record: criticality: important/platform-specific. It affects PowerPC
systems using kexec/kdump with KASAN enabled, especially pseries/PowerVM
cases verified in review. It is not universal across all architectures.

Record: subsystem activity: local history shows recent PowerPC VMX
usercopy and kexec/crash/fadump activity, and the patch was handled
through the PowerPC maintainer path.

## Phase 8: Impact And Risk Assessment
Record: affected users: PowerPC Book3S/PowerVM-style systems using
kexec/kdump with KASAN-enabled kernels and VMX copy paths.

Record: trigger conditions: kexec/kdump switchover, MMU-off copy path,
KASAN enabled, and `copy_page()` selecting the Power7 VMX copy path. The
triggering operation is privileged, but the failure impacts crash dump
capture and reboot into the new kernel.

Record: failure mode: system hang during kexec/kdump. Review discussion
includes an observed hang after “kexec: Starting switchover sequence,”
and the commit message explains unrecoverable `bad_page_fault` risk with
MMU off. Severity: HIGH to CRITICAL for affected debug/crash-dump
deployments.

Record: benefit: high for affected PowerPC KASAN/kdump users because it
prevents a hard hang and restores kexec completion.

Record: risk: very low. One function annotation plus comment; no logic
change. The main concern is that stable maintainers should also take the
companion Makefile fix for full KASAN/kexec coverage.

## Phase 9: Final Synthesis
Record: evidence for backporting:
- Fixes a real, reviewed, and tested kexec hang with KASAN enabled.
- Aboorva Devarajan reported and tested the failure/fix.
- Ritesh Harjani reviewed the final approach.
- The fix is one function attribute and explanatory comment.
- It affects a serious operational path: kexec/kdump boot into a
  new/capture kernel.
- The buggy code and call path exist across active stable versions
  checked.
- Backport is clean for current `7.0.y` and trivial for older stable
  trees.

Record: evidence against backporting:
- The issue is config/platform specific: PowerPC plus KASAN plus
  kexec/kdump plus VMX copy path.
- Older stable trees may require minor context adjustment.
- The commit is part of a two-patch series; the companion Makefile KASAN
  fix should be included for the tested complete fix.

Record: unresolved questions:
- Exact original introduction commit for `enter_vmx_ops()` could not be
  verified from local history.
- Direct lore `WebFetch` was blocked by Anubis; I used `b4` and a lore
  mirror instead.
- I did not build-test the backport.

Stable rules checklist:
1. Obviously correct and tested: yes. The annotation directly suppresses
   KASAN instrumentation on the one helper that can execute with MMU
   off; tested-by is present.
2. Fixes a real bug: yes. Review discussion reports an actual kexec hang
   with KASAN.
3. Important issue: yes. Failure mode is kexec/kdump hang.
4. Small and contained: yes. One file, one function annotation.
5. No new features/APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; older trees may need
   trivial context adjustment.

Exception category: not a device ID/quirk/build/doc exception. It is a
normal stability fix.

## Verification
- [Phase 1] Parsed the supplied commit message and fetched patch mbox;
  confirmed tags, no `Fixes:` tag in patch 2, and the linked message id.
- [Phase 2] Inspected fetched v3 diff; confirmed `arch/powerpc/lib/vmx-
  helper.c` has 8 insertions and 1 deletion, changing only
  `enter_vmx_ops()`.
- [Phase 3] Ran `git log --grep` on current history, `master`, and
  `power-next`; candidate not present locally.
- [Phase 3] Ran `git blame` around `enter_vmx_ops()`; local history
  could not identify true original introduction beyond repository
  history shape.
- [Phase 3] Ran `git show 2ab2d5794f14`; confirmed related PowerPC kexec
  KASAN sanitization commit from 2022.
- [Phase 4] Ran `b4 am` and `b4 am -c`; fetched v3 two-patch series, no
  newer revision reported, patch 2 DKIM valid.
- [Phase 4] Ran `b4 mbox`; confirmed original recipients and patch
  content.
- [Phase 4] Used lore mirror for v2 thread; confirmed Ritesh review,
  Aboorva tested-by/reported hang, and v1-to-v2 narrowing.
- [Phase 5] Searched call sites; confirmed `copypage_power7.S`,
  `memcpy_power7.S`, and `memcmp_64.S` call `enter_vmx_ops()`.
- [Phase 5] Read kexec and assembly code; confirmed kexec path reaches
  `copy_page()` with MMU-off logic and `preempt_count = HARDIRQ_OFFSET`.
- [Phase 6] Checked stable tags `v5.4` through `v7.0`; confirmed
  `enter_vmx_ops()` exists without the annotation and the relevant
  kexec/copy path exists in checked trees.
- [Phase 6] Ran `git apply --check` on current tree for patch 2 and the
  series; clean on current `7.0.y`.
- [Phase 7] Checked `MAINTAINERS`; confirmed PowerPC maintainers and
  that Madhavan Srinivasan is listed for PowerPC.
- [Phase 8] Verified failure mode from review discussion: KASAN-enabled
  kexec hangs after switchover; with both patches applied, kexec
  completes.

This should be backported, ideally together with the companion
`powerpc/kdump: fix KASAN sanitization flag for core_$(BITS).o` patch
for the tested complete KASAN/kexec fix.

**YES**

 arch/powerpc/lib/vmx-helper.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/lib/vmx-helper.c b/arch/powerpc/lib/vmx-helper.c
index 554b248002b4f..57e897b60db86 100644
--- a/arch/powerpc/lib/vmx-helper.c
+++ b/arch/powerpc/lib/vmx-helper.c
@@ -52,7 +52,14 @@ int exit_vmx_usercopy(void)
 }
 EXPORT_SYMBOL(exit_vmx_usercopy);
 
-int enter_vmx_ops(void)
+/*
+ * Can be called from kexec copy_page() path with MMU off. The kexec
+ * code sets preempt_count to HARDIRQ_OFFSET so we return early here.
+ * Since in_interrupt() is always inline, __no_sanitize_address on this
+ * function is sufficient to avoid KASAN shadow memory accesses in real
+ * mode.
+ */
+int __no_sanitize_address enter_vmx_ops(void)
 {
 	if (in_interrupt())
 		return 0;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] ALSA: usb-audio: add min_mute quirk for Razer Nommo V2 X

[Sasha Levin]

From: Pauli Virtanen <pav@iki.fi>

[ Upstream commit ad39a189bfebb3de580f390bc000f9e121c6aca3 ]

ID 1532:055e Razer USA, Ltd Razer Nommo V2 X
is tested to have muted min playback volume. Apply quirk for that.

Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/5235
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Link: https://patch.msgid.link/94449577332d14d7974864903825f27e5824ddbc.1777579951.git.pav@iki.fi
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `ALSA: usb-audio`; action verb `add`; intent:
add a playback-minimum-is-mute quirk for USB ID `1532:055e`, Razer Nommo
V2 X.

Step 1.2 Record: tags in supplied message: `Link` to PipeWire work item,
`Signed-off-by: Pauli Virtanen`, `Link` to patch msgid, `Signed-off-by:
Takashi Iwai`. No `Fixes`, `Reported-by`, `Tested-by`, `Reviewed-by`,
`Acked-by`, or `Cc: stable`. The lore patch mbox verifies the Pauli SOB
and PipeWire link; Takashi replied “Applied now.”

Step 1.3 Record: bug description is device-specific: Razer Nommo V2 X
has muted minimum playback volume. Symptom: userspace may expose the
minimum playback volume as a normal low audible volume even though
hardware treats it as mute. Version info: none in commit message. Root
cause: device has nonstandard mixer semantics.

Step 1.4 Record: yes, hidden bug/hardware workaround. It is a quirk for
incorrect USB-audio volume semantics on real hardware.

## Phase 2: Diff Analysis
Step 2.1 Record: `sound/usb/quirks.c`, `+2/-0`, in
`quirk_flags_table[]`. Scope: single-file surgical hardware quirk.

Step 2.2 Record: before, USB ID `1532:055e` had no built-in quirk flag.
After, matching that device sets `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE`.
Affected path is USB-audio device initialization and mixer control
construction.

Step 2.3 Record: bug category is hardware workaround / quirk table
entry. Mechanism: `snd_usb_init_quirk_flags_table()` ORs the flag into
`chip->quirk_flags`; `snd_usb_mixer_fu_apply_quirk()` sees that flag on
Playback controls and sets `cval->min_mute = 1`;
`snd_usb_mixer_vol_tlv()` then reports `SNDRV_CTL_TLVT_DB_MINMAX_MUTE`.

Step 2.4 Record: fix is obviously correct for kernels with this quirk
infrastructure: one ID-specific table entry, no public API, no locking
or lifetime changes. Regression risk is very low and limited to this
VID:PID.

## Phase 3: Git History Investigation
Step 3.1 Record: blame around the insertion area shows the surrounding
quirk table is longstanding, with the nearby `NeuralDSP Quad Cortex`
exception from `bc5b4e5ae1a67` and Denon entries from older Takashi Iwai
commits. The common min-mute quirk infrastructure comes from
`2c3ca8cc55a3` and follow-ups.

Step 3.2 Record: no `Fixes:` tag, so no introducing commit to follow.

Step 3.3 Record: recent `sound/usb/quirks.c` history contains many
similar device-specific quirk fixes. Related min-mute commits include
`2b929b6eec0c7` Logitech H390, `9af61fc91486c` MS LifeChat, and
`b98b69c38512c` SteelSeries Arctis.

Step 3.4 Record: Pauli Virtanen has prior USB-audio quirk commits in
this exact area, including Logitech H390, MS LifeChat, and SteelSeries
Arctis min-mute quirks.

Step 3.5 Record: dependency is the min-mute quirk infrastructure.
Present in current `7.0.y`; present in `v6.18` with
`QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE`; `v6.17` has older
`QUIRK_FLAG_MIXER_MIN_MUTE`; `v6.16`/`v6.12` did not show the generic
flag.

## Phase 4: Mailing List And External Research
Step 4.1 Record: no local commit hash was found, so `b4 dig -c` could
not be used successfully. `b4 am` and `b4 mbox` by message-id found a
single-patch thread at the supplied msgid. Thread has patch plus Takashi
Iwai reply: “Applied now.” No NAKs or concerns found in fetched thread.

Step 4.2 Record: original patch To/Cc from mbox: `linux-
sound@vger.kernel.org`, Pauli Virtanen, Jaroslav Kysela, Takashi Iwai,
`linux-kernel@vger.kernel.org`. Appropriate sound maintainers/lists were
included.

Step 4.3 Record: PipeWire link was blocked by Anubis via WebFetch, so
details could not be verified. GitHub OpenRazer issue independently
verifies device name and VID:PID `1532:055E`, but it is not the PipeWire
volume bug report.

Step 4.4 Record: thread is a standalone one-patch submission. Similar
prior min-mute quirk patches exist, but this patch does not depend on a
same-series patch.

Step 4.5 Record: lore stable search via WebFetch was blocked by Anubis;
local stable branch searches found no existing Razer Nommo V2 X commit.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified data object is `quirk_flags_table[]`; affected
functions are `snd_usb_init_quirk_flags_table()`,
`snd_usb_init_quirk_flags()`, `snd_usb_audio_create()`,
`snd_usb_mixer_fu_apply_quirk()`, and `snd_usb_mixer_vol_tlv()`.

Step 5.2 Record: `snd_usb_audio_create()` calls
`snd_usb_init_quirk_flags()` during USB audio card creation; that calls
`snd_usb_init_quirk_flags_table()`. `build_feature_ctl()` calls
`snd_usb_mixer_fu_apply_quirk()` while building mixer controls.

Step 5.3 Record: key callees/side effects are table lookup, setting
`chip->quirk_flags`, setting `cval->min_mute`, and TLV reporting through
`copy_to_user()`.

Step 5.4 Record: reachable when the specific USB audio device is
connected and its mixer controls are created. This is device-specific,
not universal.

Step 5.5 Record: many existing `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE`
entries exist for similar USB audio devices, confirming this is an
established local pattern.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: current `7.0.y` lacks the Razer entry and contains the
necessary infrastructure. `v6.18`/`v6.19` contain the named playback
min-mute flag. `v6.17` has the older generic
`QUIRK_FLAG_MIXER_MIN_MUTE`; `v6.16`/`v6.12` did not show the generic
flag.

Step 6.2 Record: `git apply --check` succeeds on current `7.0.y`. Older
trees may need minor contextual adjustment; `v6.17` would need the older
flag name. Older LTS trees without the common quirk infrastructure would
need a nontrivial backport or prerequisite series.

Step 6.3 Record: no related Razer Nommo V2 X fix found in local
`stable/linux-7.0.y`.

## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is ALSA USB audio driver under `sound/usb`;
criticality is driver-specific/peripheral, but real hardware user-
visible behavior.

Step 7.2 Record: USB-audio quirks are active, with recent commits
adding/fixing device-specific quirks and min-mute behavior.

## Phase 8: Impact And Risk
Step 8.1 Record: affected population is users of Razer Nommo V2 X using
USB audio.

Step 8.2 Record: trigger is normal volume-control use on that device.
Unprivileged audio clients can read/use ALSA mixer metadata, but no
security impact was verified.

Step 8.3 Record: failure mode is functional audio control
misrepresentation: minimum playback volume is mute. Severity: medium for
affected hardware, not crash/corruption.

Step 8.4 Record: benefit is high for affected device users and low
system-wide; risk is very low because the change is a two-line VID:PID-
scoped quirk.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: real tested hardware quirk,
established USB-audio pattern, two-line scoped change, maintainer
applied, clean on `7.0.y`, no global behavior change. Evidence against:
not a crash/security/data-corruption fix; older stable trees may need
adjustment or prerequisites. Unresolved: PipeWire bug details
unavailable due Anubis; no upstream commit hash found locally for `b4
dig`.

Step 9.2 Record: stable rules: obviously correct: yes for trees with
infrastructure; fixes real user-visible hardware bug: yes; important
enough: yes under hardware-quirk exception; small/contained: yes, 2
lines; no new APIs/features: yes; applies to stable: clean on current
`7.0.y`, minor/unknown adjustments for older trees.

Step 9.3 Record: exception category applies: hardware quirk/workaround
for an existing driver and existing quirk mechanism.

Step 9.4 Record: decision is to backport to stable trees that contain
the min-mute quirk infrastructure, especially `7.0.y`/`6.19.y`/`6.18.y`;
older trees should only take it with the appropriate small backport
adjustment or prerequisites.

Verification: performed semantic search; inspected current HEAD and
branch state; read `sound/usb/quirks.c`, `usbaudio.h`, `mixer_quirks.c`,
`mixer.c`, and `card.c`; used `rg` for quirk usage/callers; used `git
blame`, `git log`, `git show`, `git merge-base`, and `git apply
--check`; fetched lore thread with `b4 am`/`b4 mbox`; attempted `b4 dig`
but no commit hash/local commit match was available; attempted WebFetch
for PipeWire/lore search but Anubis blocked; verified device VID:PID via
OpenRazer/WebSearch.

**YES**

 sound/usb/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 4cfa24c06fcdf..148bf7e4e4d72 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2307,6 +2307,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_IGNORE_CTL_ERROR),
 	DEVICE_FLG(0x152a, 0x880a, /* NeuralDSP Quad Cortex */
 		   0), /* Doesn't have the vendor quirk which would otherwise apply */
+	DEVICE_FLG(0x1532, 0x055e, /* Razer Nommo V2 X */
+		   QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE),
 	DEVICE_FLG(0x154e, 0x1002, /* Denon DCD-1500RE */
 		   QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY),
 	DEVICE_FLG(0x154e, 0x1003, /* Denon DA-300USB */
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] wifi: libertas: fix integer underflow in process_cmdrequest()

[Sasha Levin]

From: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>

[ Upstream commit 3994b4afd521d60e47e012fe2ed7b606aaec370b ]

The existing validation only checks if recvlength exceeds
LBS_CMD_BUFFER_SIZE, but doesn't check the lower bound. When a
USB device sends a response shorter than MESSAGE_HEADER_LEN, the
subtraction (recvlength - MESSAGE_HEADER_LEN) wraps to a huge
value, causing memcpy to corrupt the heap.
Add the same lower bound check that libertas_tf already has.

Signed-off-by: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>
Link: https://patch.msgid.link/20260418004247.368944-1-a.jahangirzad@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `wifi: libertas`; action verb is `fix`;
claimed intent is to prevent integer underflow in
`process_cmdrequest()`.

Step 1.2 Record: Tags present are `Signed-off-by: Amir Mohammad
Jahangirzad`, `Link: https://patch.msgid.link/20260418004247.368944-1-
a.jahangirzad@gmail.com`, and `Signed-off-by: Johannes Berg`. No
`Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by`, or
`Cc: stable` tag was present in the supplied commit message or original
posted patch.

Step 1.3 Record: The commit body describes a concrete memory corruption
bug: `recvlength` is only checked against the upper bound, then
`recvlength - MESSAGE_HEADER_LEN` is stored in `priv->resp_len[i]` and
used as the `memcpy()` length. If a USB device supplies fewer than 4
bytes, the subtraction becomes negative and is converted to a huge
unsigned copy length. Symptom/failure mode: heap/driver memory
corruption from `memcpy()`. Version information: none in the message.
Root cause: missing lower-bound validation.

Step 1.4 Record: This is not hidden; it is explicitly a memory-safety
fix. It matches the same already-present guard in `libertas_tf`.

### Phase 2: Diff Analysis
Step 2.1 Record: One file changed:
`drivers/net/wireless/marvell/libertas/if_usb.c`, 3 insertions and 2
deletions. Modified function: `process_cmdrequest()`. Scope: single-file
surgical fix.

Step 2.2 Record: Before, `process_cmdrequest()` rejected only
`recvlength > LBS_CMD_BUFFER_SIZE`; lengths `1..3` passed and produced
`recvlength - MESSAGE_HEADER_LEN`. After, it rejects `recvlength <
MESSAGE_HEADER_LEN` as well as overlarge responses. This affects the USB
command-response receive path.

Step 2.3 Record: Bug category is memory safety, specifically integer
underflow leading to oversized `memcpy()`. Verified details:
`MESSAGE_HEADER_LEN` is 4, `resp_len` is `u32`, `resp_buf` is `u8
resp_buf[2][LBS_UPLD_SIZE]`, and `LBS_UPLD_SIZE` is 2312. A negative
subtraction assigned to `u32` becomes a huge length, far beyond the
destination buffer.

Step 2.4 Record: Fix quality is high: minimal bounds check, no API
change, no new behavior except rejecting malformed command responses.
Regression risk is very low; valid command responses must already
include the 4-byte command type/header.

### Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the upper-bound check came from
`ddac452680a516` in the v2.6.25-rc1 era, and the `resp_len = recvlength
- MESSAGE_HEADER_LEN` plus `memcpy()` flow came from `7919b89c8276` in
the v2.6.26-rc1 era. This code is old and widely present.

Step 3.2 Record: No `Fixes:` tag is present in the candidate, so there
is no specific tagged introducing commit to follow. Blame nevertheless
identifies the relevant old code.

Step 3.3 Record: Recent file history includes unrelated cleanup/fix
commits such as `3968e81ba644` changing skb free placement and
`d66676e6ca96` fixing a warning in `usb_tx_block()`. I found no
prerequisite commit needed for this bounds check.

Step 3.4 Record: `git log --author='Amir Mohammad Jahangirzad'` found no
prior local commits in this Marvell wireless subtree. The final signoff
is from Johannes Berg; `MAINTAINERS` lists Johannes Berg as wireless
maintainer, while the Libertas driver itself is marked orphaned under
`linux-wireless` and `libertas-dev`.

Step 3.5 Record: Dependencies found: none. The patch uses existing local
constants and mirrors the already-existing `libertas_tf` check.

### Phase 4: Mailing List And External Research
Step 4.1 Record: No commit hash was available in local history, so `b4
dig -c` could not be used successfully; `b4 dig -c
20260418004247.368944-1-a.jahangirzad@gmail.com` failed because it
expects a commit. Fallback `b4 mbox` and the lore mirror found the
original patch at `https://yhbt.net/lore/lkml/20260418004247.368944-1-
a.jahangirzad@gmail.com/T/`. The thread has one message and no replies.
`b4 mbox -c` found no newer revision in the thread.

Step 4.2 Record: Original recipients included Johannes Berg, Kees Cook,
Ingo Molnar, Johan Hovold, `linux-wireless`, `libertas-dev`, and `linux-
kernel`. No reviewer replies, NAKs, or explicit stable nominations were
present in the fetched thread.

Step 4.3 Record: No `Reported-by` or bug-report link was present. I
found no separate public bug report for this exact issue. The message
itself provides the failure mechanism.

Step 4.4 Record: Related precedent exists: commit `3348ef6a6a126` fixed
the identical underflow in `libertas_tf: process_cmdrequest()`, with
message “If recvlength is less than MESSAGE_HEADER_LEN (4) we would end
up corrupting memory.” That analogous fix was later carried in stable
review postings for 4.19 and 3.16.

Step 4.5 Record: Web searches found the exact candidate posting and
stable history for the analogous `libertas_tf` fix, but no exact stable
discussion for this new `libertas` patch.

### Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `process_cmdrequest()`.

Step 5.2 Record: Caller is `if_usb_receive()`, reached as the receive
URB completion callback installed by `usb_fill_bulk_urb()` through
`if_usb_submit_rx_urb()`.

Step 5.3 Record: Key callees are `memcpy()`, `dev_kfree_skb_irq()`, and
`lbs_notify_command_response()`. The command response is later consumed
by the main thread through `lbs_process_command_response()`.

Step 5.4 Record: Reachability is verified through USB receive
completion: a Libertas USB device response with type `CMD_TYPE_REQUEST`
reaches `process_cmdrequest()`. The triggering input is device-
controlled USB receive data, so this is reachable with affected hardware
or a malicious/faulty USB device.

Step 5.5 Record: Similar pattern found in `libertas_tf`; that sibling
driver already has the exact lower-bound check. `if_sdio` and `if_spi`
use different response formats and do not subtract `MESSAGE_HEADER_LEN`
in the same way.

### Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: Representative tags `v3.16`, `v4.14`, `v4.19`, `v5.4`,
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, and newer `v6.13` through
`v6.17` all contain the buggy `process_cmdrequest()` pattern without the
lower-bound check. The bug dates back to at least the v2.6.26-rc1 era.

Step 6.2 Record: Expected backport difficulty is low for modern stable
trees: the same context is present in representative stable tags, and
`git apply --check` succeeds against the current tree. Very old trees
before the Marvell directory move may need path/context adjustment, as
verified by older tags using `drivers/net/wireless/libertas/if_usb.c`.

Step 6.3 Record: No exact related fix for `libertas` was found in local
history. The sibling `libertas_tf` fix exists and was stable-backported.

### Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is wireless driver code under
`drivers/net/wireless/marvell/libertas`. Criticality: driver-specific,
but memory corruption in a kernel USB receive path is high severity for
affected systems.

Step 7.2 Record: Subsystem activity is low-to-moderate; recent history
shows occasional fixes and cleanups. `MAINTAINERS` marks Marvell
Libertas as orphaned, with `linux-wireless` and `libertas-dev` lists.

### Phase 8: Impact And Risk Assessment
Step 8.1 Record: Affected population is config- and hardware-specific:
systems with `CONFIG_LIBERTAS_USB` and Marvell Libertas 8388 USB
devices, or systems exposed to a malicious USB device matching the
driver IDs.

Step 8.2 Record: Trigger condition is a USB command response shorter
than `MESSAGE_HEADER_LEN` but with `CMD_TYPE_REQUEST` dispatch. This is
device-controlled. I did not verify an unprivileged software-only
trigger; physical or device-level control is the verified trigger model.

Step 8.3 Record: Failure mode is heap/driver memory corruption from
oversized `memcpy()`. Severity: HIGH to CRITICAL, because kernel memory
corruption can crash the system and can have security implications.

Step 8.4 Record: Benefit is high for affected systems: prevents kernel
memory corruption from malformed USB responses. Risk is very low: 3-line
effective validation change in one driver function, with precedent in
sibling driver.

### Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: real memory corruption bug;
old code present across many stable release tags; tiny surgical fix; no
new API or feature; exact validation already used by `libertas_tf`;
analogous `libertas_tf` fix was stable-backported. Evidence against:
driver-specific and no external bug report or tested-by tag. Unresolved:
exact final upstream commit hash was not present in local history, so
`b4 dig -c <commit_hash>` could not be completed.

Step 9.2 Record:
1. Obviously correct and tested? Obviously correct by code inspection;
   no explicit `Tested-by`.
2. Fixes a real bug? Yes, verified underflow into oversized `memcpy()`.
3. Important issue? Yes, kernel memory corruption.
4. Small and contained? Yes, one function in one file.
5. No new features/APIs? Yes.
6. Can apply to stable trees? Yes for modern representative tags with
   likely clean/minor context; old pre-directory-move trees may need
   path adjustment.

Step 9.3 Record: No exception category such as device ID, quirk, DT,
build, or docs applies. This is a direct memory-safety bug fix.

Step 9.4 Record: Stable backport decision is YES. The fix prevents
kernel memory corruption in an old, stable-present USB driver path with
extremely low regression risk.

## Verification
- Phase 1: Parsed supplied tags and fetched original patch thread with
  `b4 mbox`; confirmed no `Fixes`, `Reported-by`, `Tested-by`,
  `Reviewed-by`, `Acked-by`, or stable tag.
- Phase 2: Read `drivers/net/wireless/marvell/libertas/if_usb.c`,
  `dev.h`, and `defs.h`; confirmed `MESSAGE_HEADER_LEN`, `resp_len`,
  `resp_buf`, and `memcpy()` behavior.
- Phase 3: Ran `git blame` on `process_cmdrequest()`; identified old
  introducing history around `ddac452680a516` and `7919b89c8276`.
- Phase 3: Ran `git describe --contains`; confirmed relevant code dates
  to v2.6.25/v2.6.26-era history.
- Phase 4: `b4 dig` with the message-id failed because no local commit
  hash was available; recorded as unresolved.
- Phase 4: `b4 mbox` fetched the patch thread; `b4 mbox -c` found one
  message and no newer revision.
- Phase 4: Fetched lore mirror and stable archive pages; confirmed
  analogous `libertas_tf` fix and stable review postings.
- Phase 5: Traced callers from `if_usb_receive()` through
  `usb_fill_bulk_urb()` and `if_usb_submit_rx_urb()`.
- Phase 6: Checked release tags from `v3.16` through representative
  active v6 tags; confirmed the buggy code exists broadly.
- Phase 6: Ran `git apply --check` against the current tree; patch
  applies cleanly there.
- Phase 7: Checked `MAINTAINERS`; confirmed Libertas is orphaned under
  wireless lists and Johannes Berg is listed for wireless maintenance.
- Phase 8: Verified trigger is USB device-controlled receive data; no
  unprivileged software-only trigger was verified.

**YES**

 drivers/net/wireless/marvell/libertas/if_usb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
index 8a6bf1365cfab..42d3fd32ece28 100644
--- a/drivers/net/wireless/marvell/libertas/if_usb.c
+++ b/drivers/net/wireless/marvell/libertas/if_usb.c
@@ -625,9 +625,10 @@ static inline void process_cmdrequest(int recvlength, uint8_t *recvbuff,
 	unsigned long flags;
 	u8 i;
 
-	if (recvlength > LBS_CMD_BUFFER_SIZE) {
+	if (recvlength < MESSAGE_HEADER_LEN ||
+	    recvlength > LBS_CMD_BUFFER_SIZE) {
 		lbs_deb_usbd(&cardp->udev->dev,
-			     "The receive buffer is too large\n");
+			     "The receive buffer is invalid: %d\n", recvlength);
 		kfree_skb(skb);
 		return;
 	}
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] HID: mcp2221: fix OOB write in mcp2221_raw_event()

[Sasha Levin]

From: Florian Pradines <florian.pradines@gmail.com>

[ Upstream commit f097d246677b03db814c5862f368cea341b76a00 ]

mcp2221_raw_event() copies device-supplied data into mcp->rxbuf at
offset rxbuf_idx without checking that the copy fits within the
destination buffer. A device responding with up to 60 bytes to a
small I2C/SMBus read can overflow the buffer.

Add a rxbuf_size field to struct mcp2221, set it alongside rxbuf in
mcp_i2c_smbus_read(), and check rxbuf_idx + data[3] <= rxbuf_size
before the memcpy.

Reported-by: Benoît Sevens <bsevens@google.com>
Signed-off-by: Florian Pradines <florian.pradines@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `HID: mcp2221`; action verb `fix`; claimed
intent: prevent an out-of-bounds write in `mcp2221_raw_event()` when
copying device-supplied I2C read data into `mcp->rxbuf`.

Step 1.2 Record: tags found in upstream commit
`f097d246677b03db814c5862f368cea341b76a00`: `Reported-by: Benoît Sevens
<bsevens@google.com>`, `Signed-off-by: Florian Pradines
<florian.pradines@gmail.com>`, `Signed-off-by: Jiri Kosina
<jkosina@suse.com>`. No `Fixes:`, no `Cc: stable`, no `Link:` in the
commit message.

Step 1.3 Record: bug description is explicit: `mcp2221_raw_event()`
copies `data[3]` bytes into `mcp->rxbuf + rxbuf_idx` without checking
the destination buffer size. Failure mode is kernel memory corruption
via OOB write when a device returns up to 60 bytes for a smaller
requested read.

Step 1.4 Record: not hidden; this is a direct memory-safety fix.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed, `drivers/hid/hid-mcp2221.c`, 7
insertions. Modified areas: `struct mcp2221`, `mcp_i2c_smbus_read()`,
`mcp2221_raw_event()`. Scope: single-file surgical fix.

Step 2.2 Record: before, the driver tracked `rxbuf` and `rxbuf_idx` but
not the destination size. After, it stores `rxbuf_size` when setting
`rxbuf`, and rejects `rxbuf_idx + data[3] > rxbuf_size` before
`memcpy()`.

Step 2.3 Record: bug category is memory safety, specifically OOB write
from device-controlled length and cumulative receive offset. The earlier
`data[3] > 60` check only capped a single MCP2221 report, not the
destination buffer size.

Step 2.4 Record: fix is minimal and locally correct for the upstream
parent, but direct stable backports need care because older stable
branches still have two manual `mcp_smbus_xfer()` paths that set
`mcp->rxbuf` directly.

## Phase 3: Git History
Step 3.1 Record: `git blame` showed `rxbuf`, `rxbuf_idx`,
`mcp_i2c_smbus_read()`, and the `memcpy()` path originated in
`67a95c21463d0`, first contained in `v5.7-rc1`. The partial-read
handling came from `2682468671aa0`, first contained in `v6.8-rc1`. The
prior per-report `data[3] > 60` guard came from `b56cc41a3ae73`, first
contained in `v6.17-rc4` and backported to stable equivalents.

Step 3.2 Record: no `Fixes:` tag, so no tagged introducing commit to
follow.

Step 3.3 Record: recent related commits include `b56cc41a3ae73` for the
60-byte report cap, `e31b556c0ba21` for read-error cancellation, and
`ab05515757fcb` for using `mcp_i2c_smbus_read()` for block reads.
`ab05515757fcb` is an important context dependency for the exact
upstream diff.

Step 3.4 Record: author Florian Pradines had no other local commits
found in `drivers/hid`; Jiri Kosina, the HID maintainer,
committed/applied the patch.

Step 3.5 Record: upstream parent contains `ab05515757fcb`; stable
branches checked from `5.10.y` through `7.0.y` do not. A stable backport
should either adapt the patch to set `rxbuf_size` in the two remaining
manual `mcp_smbus_xfer()` paths or include an appropriate
prerequisite/backport.

## Phase 4: Mailing List / External Research
Step 4.1 Record: `b4 dig -c f097d246677b03db814c5862f368cea341b76a00`
found the lore thread: `https://patch.msgid.link/20260509094517.2691246-
1-florian.pradines@gmail.com`. `b4 dig -a` showed only v1.

Step 4.2 Record: `b4 dig -w` showed recipients included Florian
Pradines, Rishi Gupta, Jiri Kosina, Benjamin Tissoires, `linux-i2c`, and
`linux-input`.

Step 4.3 Record: reporter Benoît Sevens previously submitted a similar
heap-buffer-overflow patch. Jiri replied that Benoît’s patch was mangled
and that Florian’s patch would be taken with Benoît added as `Reported-
by`. Benoît then noted the missing `mcp_smbus_xfer()` assignments, which
is relevant for older stable bases.

Step 4.4 Record: not part of a multi-patch series. Related patches exist
for report-size validation, but Jiri questioned the “MCP2221 always
sends 64-byte reports” assumption in that separate thread.

Step 4.5 Record: direct lore/stable WebFetch was blocked by Anubis, but
web search found related stable discussion for prior mcp2221 fixes, not
an exact stable request for `f097d246677b`.

## Phase 5: Semantic Analysis
Step 5.1 Record: changed function is `mcp_i2c_smbus_read()`; changed
callback is `mcp2221_raw_event()`.

Step 5.2 Record: callers of `mcp_i2c_smbus_read()` are `mcp_i2c_xfer()`
and `mcp_smbus_xfer()`, wired into `mcp_i2c_algo`. `mcp2221_raw_event()`
is called from HID core before normal raw report processing, via
`hid_input_report()` / `__hid_input_report()`.

Step 5.3 Record: affected callees include `mcp_send_data_req_status()`,
`mcp_send_report()`, `wait_for_completion_timeout()`, and the vulnerable
`memcpy()`.

Step 5.4 Record: reachability is real: USB HID interrupt input reaches
`mcp2221_raw_event()`, and I2C/SMBus transfers reach
`mcp_i2c_smbus_read()` through the registered I2C adapter.
Triggerability by an unprivileged local user was not verified; trigger
by a malicious or buggy MCP2221-side device response is verified by the
code path.

Step 5.5 Record: similar pattern found in stable branches: two manual
`mcp_smbus_xfer()` receive-buffer assignments remain in stable branches
and must be handled in backports.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: the driver was introduced in `v5.7-rc1`; local stable
refs `5.10.y`, `5.15.y`, `6.1.y`, `6.6.y`, `6.12.y`, `6.18.y`, `6.19.y`,
and `7.0.y` contain the vulnerable `rxbuf`/`memcpy()` pattern. `5.4.y`
does not contain the driver.

Step 6.2 Record: `git apply --check` against current
`stable/linux-7.0.y` succeeds syntactically, but semantic backport work
is needed because stable lacks `ab05515757fcb`.

Step 6.3 Record: prior stable branches already contain the earlier
60-byte cap fix or its backported equivalent, but that does not fix
cumulative overflow into smaller destination buffers.

## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is HID driver for the Microchip MCP2221 USB-
to-I2C/SMBus bridge. Criticality: driver-specific, but memory corruption
from USB/HID device input is high severity for affected systems.

Step 7.2 Record: file history shows active recent maintenance and
multiple security/correctness fixes in this driver.

## Phase 8: Impact And Risk
Step 8.1 Record: affected population is users of MCP2221 hardware or
systems exposed to such USB HID devices.

Step 8.2 Record: trigger is an I2C/SMBus read where the MCP2221-side
response reports more bytes than the destination buffer can hold.
Physical/malicious-device trigger is verified; unprivileged local
trigger depends on device-node permissions and was not verified.

Step 8.3 Record: failure mode is OOB write into kernel memory, severity
HIGH to CRITICAL due to memory corruption/crash/security risk.

Step 8.4 Record: benefit is high. Risk is low for the upstream parent
and for correctly adapted stable backports. Risk is medium for blind
cherry-picks into older stable branches because `rxbuf_size` would not
be set in all stable receive-buffer paths.

## Phase 9: Final Synthesis
Evidence for backporting: real OOB write, explicit reporter, small
patch, maintainer-applied, affects stable-supported code since `5.10.y`,
fixes a memory-corruption class bug.

Evidence against or concerns: no `Fixes:`/`Cc: stable`; exact upstream
diff assumes `ab05515757fcb`, absent from checked stable branches; blind
cherry-pick is not sufficient for older stable trees.

Stable rules checklist: obviously correct on its upstream base: yes.
Fixes a real user-affecting bug: yes. Important issue: yes, kernel
memory corruption. Small and contained: yes, 7 insertions. No new
feature/API: yes. Applies to stable: syntactically yes on `7.0.y`, but
older stable needs a branch-specific backport adjustment.

Exception category: none; this is a memory-safety fix, not a device
ID/quirk/doc/build exception.

## Verification
- Phase 1: fetched and inspected upstream commit
  `f097d246677b03db814c5862f368cea341b76a00`.
- Phase 2: verified exact diff is 7 insertions in `drivers/hid/hid-
  mcp2221.c`.
- Phase 3: ran `git blame`, `git describe --contains`, and targeted `git
  log` without `--all`; identified `67a95c21463d0`, `2682468671aa0`,
  `b56cc41a3ae73`, and `ab05515757fcb`.
- Phase 4: ran `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and fetched mboxes
  with `b4 mbox`; verified Jiri’s “Applied, thanks” and Benoît’s earlier
  report/backport-relevant concern.
- Phase 5: used code search and file reads to verify HID and I2C/SMBus
  call paths.
- Phase 6: used `git grep` against stable refs to verify vulnerable
  patterns in `5.10.y` through `7.0.y`, and absence from `5.4.y`.
- Phase 6: verified exact patch syntactically applies to current
  `stable/linux-7.0.y`, but `ab05515757fcb` is not an ancestor of
  checked stable refs.
- Phase 8: severity is based on verified device-controlled `memcpy()`
  into kernel buffer without destination-size check.
- UNVERIFIED: no runtime reproducer was executed; no build test was run;
  unprivileged local triggerability was not verified.

This should be backported, but stable maintainers should not blindly
cherry-pick it into pre-`ab05515757fcb` trees without adding
`rxbuf_size` initialization to every remaining `mcp->rxbuf` assignment.

**YES**

 drivers/hid/hid-mcp2221.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/hid/hid-mcp2221.c b/drivers/hid/hid-mcp2221.c
index ef3b5c77c38e3..badd4958bc12c 100644
--- a/drivers/hid/hid-mcp2221.c
+++ b/drivers/hid/hid-mcp2221.c
@@ -121,6 +121,7 @@ struct mcp2221 {
 	u8 *rxbuf;
 	u8 txbuf[64];
 	int rxbuf_idx;
+	int rxbuf_size;
 	int status;
 	u8 cur_i2c_clk_div;
 	struct gpio_chip *gc;
@@ -323,12 +324,14 @@ static int mcp_i2c_smbus_read(struct mcp2221 *mcp,
 		mcp->txbuf[3] = (u8)(msg->addr << 1);
 		total_len = msg->len;
 		mcp->rxbuf = msg->buf;
+		mcp->rxbuf_size = msg->len;
 	} else {
 		mcp->txbuf[1] = smbus_len;
 		mcp->txbuf[2] = 0;
 		mcp->txbuf[3] = (u8)(smbus_addr << 1);
 		total_len = smbus_len;
 		mcp->rxbuf = smbus_buf;
+		mcp->rxbuf_size = smbus_len;
 	}
 
 	ret = mcp_send_data_req_status(mcp, mcp->txbuf, 4);
@@ -912,6 +915,10 @@ static int mcp2221_raw_event(struct hid_device *hdev,
 					mcp->status = -EINVAL;
 					break;
 				}
+				if (mcp->rxbuf_idx + data[3] > mcp->rxbuf_size) {
+					mcp->status = -EINVAL;
+					break;
+				}
 				buf = mcp->rxbuf;
 				memcpy(&buf[mcp->rxbuf_idx], &data[4], data[3]);
 				mcp->rxbuf_idx = mcp->rxbuf_idx + data[3];
-- 
2.53.0

[PATCH AUTOSEL 7.0] io_uring/wait: honour caller's time namespace for IORING_ENTER_ABS_TIMER

[Sasha Levin]

From: Maoyi Xie <maoyixie.tju@gmail.com>

[ Upstream commit 45d2b37a37ab98484693533496395c610a2cab96 ]

io_uring_enter() with IORING_ENTER_ABS_TIMER takes an absolute
timespec from the caller via ext_arg->ts. It arms an ABS mode
hrtimer in __io_cqring_wait_schedule(). The conversion path in
io_uring/wait.c parses ext_arg->ts inline rather than going
through io_parse_user_time(). It therefore does not pick up the
time namespace conversion added by the previous patch.

Apply timens_ktime_to_host() to the parsed time on the
IORING_ENTER_ABS_TIMER branch. This mirrors the IORING_TIMEOUT_ABS
fix in io_parse_user_time(). Use ctx->clockid as the clock id.
ctx->clockid is set either at ring creation or via
IORING_REGISTER_CLOCK.

timens_ktime_to_host() is a no-op for clocks not affected by time
namespaces. It is also a no-op for callers in the initial time
namespace. The fast path is unchanged.

Reproducer: in unshare --user --time, with a -10s monotonic
offset, call io_uring_enter with min_complete=1,
IORING_ENTER_ABS_TIMER, and ts = now + 1s. The call returns
-ETIME after <1ms instead of after the expected ~1s.

Suggested-by: Pavel Begunkov <asml.silence@gmail.com>
Suggested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260504153755.1293932-3-maoyi.xie@ntu.edu.sg
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record: Subsystem `io_uring/wait`; action verb `honour`; intent is to
make `IORING_ENTER_ABS_TIMER` interpret caller absolute times in the
caller’s time namespace.

Record: Tags present:
`Suggested-by: Pavel Begunkov`, `Suggested-by: Jens Axboe`, author
`Signed-off-by: Maoyi Xie`, `Link:
https://patch.msgid.link/20260504153755.1293932-3-maoyi.xie@ntu.edu.sg`,
maintainer `Signed-off-by: Jens Axboe`. No `Fixes:`, `Reported-by:`,
`Tested-by:`, `Reviewed-by`, `Acked-by`, or `Cc: stable`.

Record: The commit describes a real userspace-visible bug:
`io_uring_enter()` with `IORING_ENTER_ABS_TIMER` parses `ext_arg->ts`
directly, then arms an absolute hrtimer without converting from the
caller’s time namespace to host time. The supplied reproducer in
`unshare --user --time` with a `-10s` monotonic offset returns `-ETIME`
in under 1 ms instead of about 1 second.

Record: This is not hidden cleanup. It is a direct correctness fix for
absolute timeout interpretation in time namespaces.

### Phase 2: Diff Analysis
Record: One file changed, `io_uring/wait.c`, 5 insertions and 1
deletion. Function modified: `io_cqring_wait()`. Scope: single-file
surgical fix.

Record: Before, `ext_arg->ts` was converted with
`timespec64_to_ktime()`. If `IORING_ENTER_ABS_TIMER` was unset, the code
added `start_time`; if set, it used the raw caller value as a host
absolute deadline. After, the absolute branch calls
`timens_ktime_to_host(ctx->clockid, iowq.timeout)`, while the relative
branch remains unchanged.

Record: Bug category is logic/correctness in time namespace handling.
The broken mechanism is that a namespaced absolute
`CLOCK_MONOTONIC`/`CLOCK_BOOTTIME` timestamp was fed to a host hrtimer
as if it were already in host time.

Record: Fix quality is strong: minimal, local, uses existing kernel
helper, and no new API. Regression risk is very low because
`timens_ktime_to_host()` is verified as a no-op for the initial time
namespace, for unsupported clocks, and when `CONFIG_TIME_NS` is
disabled.

### Phase 3: Git History Investigation
Record: `git blame` on the changed wait lines points to `0105b0562a5e`
(`io_uring: split out CQ waiting code into wait.c`) for the current file
location. The same logic predates the split; `2b8e976b9842` (`io_uring:
user registered clockid for wait timeouts`) shows this absolute-wait
path using `ctx->clockid` and is contained by `v6.12-rc1`.

Record: No `Fixes:` tag is present, so there was no tagged introducing
commit to follow. I inspected the companion parent commit instead:
`9cc6bac1bebf` fixes the same time-namespace issue for
`IORING_TIMEOUT_ABS`.

Record: Recent related history shows this is patch 2/2 after
`9cc6bac1bebf`. The candidate’s parent is exactly `9cc6bac1bebf`, but
this wait fix compiles independently as long as `timens_ktime_to_host()`
and `ctx->clockid` exist.

Record: Author history in `io_uring` before this commit only showed the
companion timeout fix. Jens Axboe applied the patch, and Pavel/Jens were
suggested-by/review participants.

Record: Dependencies: affected stable trees need `ctx->clockid` and
`timens_ktime_to_host()`. I verified both exist in local `for-
greg/6.12-100`; the same `IORING_ENTER_ABS_TIMER` buggy line exists in
`6.12`, `6.18`, `6.19`, and `7.0` local stable branches, but not in
`5.10`, `5.15`, `6.1`, or `6.6`.

### Phase 4: Mailing List And External Research
Record: `b4 dig -c 45d2b37a37ab...` found the original submission at `ht
tps://patch.msgid.link/20260504153755.1293932-3-maoyi.xie@ntu.edu.sg`.

Record: `b4 dig -a` found only v1 of the series. The thread shows Jens
applied both patches with commit IDs `9cc6bac1bebf` and `45d2b37a37ab`.

Record: `b4 dig -w` shows the right people/lists were included: Maoyi
Xie, Jens Axboe, Pavel Begunkov, `io-uring@vger.kernel.org`, and `linux-
kernel@vger.kernel.org`.

Record: Reviewer feedback was positive: Pavel wrote “both look good” and
requested a liburing test; Jens replied “+1” for the test and later
applied the series. No NAKs or objections found.

Record: No separate bug-report link exists beyond the patch
thread/reproducer. Stable-specific WebFetch was blocked by Anubis, and
local thread search found no stable nomination.

### Phase 5: Code Semantic Analysis
Record: Modified function: `io_cqring_wait()`.

Record: Callers: `io_uring_enter(2)` reaches `io_cqring_wait()` when
`IORING_ENTER_GETEVENTS` is set, after `io_get_ext_arg()` copies/parses
the userspace getevents argument. This is directly syscall-reachable.

Record: Key callees: `timespec64_to_ktime()`, `timens_ktime_to_host()`,
`ktime_add()`, `io_get_time()`, `io_cqring_schedule_timeout()`, and
hrtimer setup/start helpers.

Record: Call chain: userspace `io_uring_enter()` -> `io_get_ext_arg()`
-> `io_cqring_wait()` -> `io_cqring_wait_schedule()` ->
`__io_cqring_wait_schedule()` -> `io_cqring_schedule_timeout()` ->
absolute hrtimer. The buggy path is reachable from userspace with
`IORING_ENTER_GETEVENTS | IORING_ENTER_EXT_ARG |
IORING_ENTER_ABS_TIMER`.

Record: Similar patterns: the companion commit fixes
`io_parse_user_time()` for `IORING_TIMEOUT_ABS`; POSIX timers,
`clock_nanosleep`, alarm timers, and `timerfd` already use
`timens_ktime_to_host()` for absolute timers.

### Phase 6: Stable Tree Analysis
Record: Local stable-branch grep found the buggy
`IORING_ENTER_ABS_TIMER` code in `for-greg/6.12-100`, `for-
greg/6.18-100`, `for-greg/6.19-200`, and `for-greg/7.0-100`. It was
absent from `5.10`, `5.15`, `6.1`, and `6.6`.

Record: Backport difficulty: current `7.0.y` apply check succeeds
cleanly. `6.12`/`7.0` have `io_uring/wait.c`; `6.18`/`6.19` local
branches have the same logic in `io_uring/io_uring.c`, so those need a
path/context backport but not semantic rework.

Record: No related fix with this subject was found in the checked stable
candidate branches.

### Phase 7: Subsystem Context
Record: Subsystem is `io_uring`, a core async I/O syscall subsystem.
Criticality: IMPORTANT, not universal core MM/VFS, but directly
userspace-facing and widely used.

Record: Subsystem activity is high; recent `io_uring` history has many
fixes and feature changes. This specific change is small despite the
active subsystem.

### Phase 8: Impact And Risk
Record: Affected population: users of `io_uring_enter()` absolute CQ
wait timeouts inside non-initial time namespaces, especially container-
like environments. Branch-limited to stable trees that contain
`IORING_ENTER_ABS_TIMER`.

Record: Trigger: userspace can trigger via `io_uring_enter()` with
`IORING_ENTER_ABS_TIMER` and a timespec from a shifted time namespace.
The provided reproducer uses `unshare --user --time`; whether fully
unprivileged depends on system user-namespace policy.

Record: Failure mode: incorrect timeout behavior. With the reproduced
negative offset, the wait returns `-ETIME` immediately; with other
offsets, absolute waits can be delayed incorrectly. Severity: MEDIUM to
HIGH user-visible correctness bug, potential application timeout/hang
behavior, but not a kernel crash, memory corruption, or security fix.

Record: Benefit is moderate/high for affected containerized users
because it restores syscall semantics. Risk is very low: one local
conditional change plus an include, using established helper semantics.

### Phase 9: Final Synthesis
Record: Evidence for backporting: real reproduced bug, syscall-
reachable, affects stable branches with the feature, tiny patch,
maintainer-applied, positive reviewer feedback, matches established
time-namespace behavior elsewhere.

Record: Evidence against backporting: not a crash/security/data-
corruption fix; affects a narrower feature combination; no explicit
stable nomination; older stable trees do not contain the affected
feature.

Record: Unresolved: I did not run the reproducer locally. Lore WebFetch
was blocked by Anubis, but `b4` successfully fetched the thread. Exact
first upstream introduction of `IORING_ENTER_ABS_TIMER` was not cleanly
reconstructed from local blame alone, but affected stable branches were
directly verified by grep.

Stable rules:
1. Obviously correct and tested: yes by code inspection, reproducer, and
   positive review; no formal `Tested-by`.
2. Fixes a real bug: yes, reproduced wrong timeout result.
3. Important issue: yes for affected users, because absolute waits can
   return immediately or at the wrong time.
4. Small and contained: yes, 6-line single-function change.
5. No new features/APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; minor path adjustment
   may be needed in some branches.

No automatic exception category applies.

## Verification
- [Phase 1] Parsed `git show` commit message and tags for
  `45d2b37a37ab98484693533496395c610a2cab96`.
- [Phase 2] Verified diff is one file, `io_uring/wait.c`, 5 insertions/1
  deletion in `io_cqring_wait()`.
- [Phase 3] Ran `git blame` on the changed lines; current file location
  comes from `0105b0562a5e`.
- [Phase 3] Inspected `2b8e976b9842`; verified `ctx->clockid`,
  `io_get_time(ctx)`, and selected-clock wait timeout support.
- [Phase 3] Inspected companion commit `9cc6bac1bebf`; verified same
  class of fix for `IORING_TIMEOUT_ABS`.
- [Phase 4] Ran `b4 dig`, `b4 dig -a`, `b4 dig -w`, and `b4 mbox`;
  verified v1-only series, correct recipients, positive feedback, and
  applied notice.
- [Phase 5] Read `io_uring_enter()` and `io_get_ext_arg()` call path;
  verified direct syscall reachability.
- [Phase 5] Verified `timens_ktime_to_host()` behavior in
  `include/linux/time_namespace.h` and `kernel/time/namespace.c`.
- [Phase 5] Verified similar established conversions in `kernel/time`
  and `fs/timerfd.c`.
- [Phase 6] Ran `git grep` on local stable branches; affected: `6.12`,
  `6.18`, `6.19`, `7.0`; unaffected: `5.10`, `5.15`, `6.1`, `6.6`.
- [Phase 6] Ran `git apply --check` for the candidate patch on current
  `7.0.y`; it applies cleanly.
- [Phase 8] Verified reproducer details from commit and mailing-list
  cover letter; did not execute it locally.

This should be backported to stable trees that contain
`IORING_ENTER_ABS_TIMER`, with the companion timeout patch strongly
recommended for complete io_uring absolute-timeout time-namespace
correctness.

**YES**

 io_uring/wait.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/io_uring/wait.c b/io_uring/wait.c
index 91df86ce0d18c..ec01e78a216d6 100644
--- a/io_uring/wait.c
+++ b/io_uring/wait.c
@@ -5,6 +5,7 @@
 #include <linux/kernel.h>
 #include <linux/sched/signal.h>
 #include <linux/io_uring.h>
+#include <linux/time_namespace.h>
 
 #include <trace/events/io_uring.h>
 
@@ -229,7 +230,10 @@ int io_cqring_wait(struct io_ring_ctx *ctx, int min_events, u32 flags,
 
 	if (ext_arg->ts_set) {
 		iowq.timeout = timespec64_to_ktime(ext_arg->ts);
-		if (!(flags & IORING_ENTER_ABS_TIMER))
+		if (flags & IORING_ENTER_ABS_TIMER)
+			iowq.timeout = timens_ktime_to_host(ctx->clockid,
+							    iowq.timeout);
+		else
 			iowq.timeout = ktime_add(iowq.timeout, start_time);
 	}
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] wifi: nl80211: require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS

[Sasha Levin]

From: Maoyi Xie <maoyi.xie@ntu.edu.sg>

[ Upstream commit 15994bb0cbb8fc4879da7552ddd08c1896261c39 ]

NL80211_CMD_SET_WIPHY_NETNS dispatches with GENL_UNS_ADMIN_PERM, which
verifies that the caller has CAP_NET_ADMIN for the source netns. It
doesn't verify that the caller has CAP_NET_ADMIN over the target netns
selected by NL80211_ATTR_NETNS_FD or NL80211_ATTR_PID.

This diverges from the convention enforced in
net/core/rtnetlink.c::rtnl_get_net_ns_capable():

    /* For now, the caller is required to have CAP_NET_ADMIN in
     * the user namespace owning the target net ns.
     */
    if (!sk_ns_capable(sk, net->user_ns, CAP_NET_ADMIN))
        return ERR_PTR(-EACCES);

A user with CAP_NET_ADMIN in their own user namespace can therefore
push a wiphy into an arbitrary netns (including init_net) over which
they have no privilege.

Mirror the rtnetlink convention by requiring CAP_NET_ADMIN in the
target netns before calling cfg80211_switch_netns().

Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260506064854.2207105-2-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record: `wifi: nl80211` subsystem; action verb `require`; intent is to
require `CAP_NET_ADMIN` over the target network namespace before
`NL80211_CMD_SET_WIPHY_NETNS` moves a wiphy.

Record: Tags in the provided commit message:
`Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>`, `Link: https://patch.
msgid.link/20260506064854.2207105-2-maoyixie.tju@gmail.com`, `Signed-
off-by: Johannes Berg <johannes.berg@intel.com>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, or `Cc: stable` tag was
present in the provided message.

Record: The described bug is an authorization gap. `GENL_UNS_ADMIN_PERM`
verifies `CAP_NET_ADMIN` for the netlink socket/source netns, but
`NL80211_ATTR_NETNS_FD` / `NL80211_ATTR_PID` selects a target netns that
was not separately checked. The b4-fetched cover letter includes a
concrete reproducer with `mac80211_hwsim`: a caller privileged only in
its own user namespace can move a delegated wiphy back into `init_net`.

Record: This is not a hidden cleanup fix; it is an explicit
security/permission bug fix.

### Phase 2: Diff Analysis
Record: One file changed, `net/wireless/nl80211.c`, with 13 insertions
in `nl80211_wiphy_netns()`. Scope is a single-function surgical fix.

Record: Before: after resolving the target netns and checking
`IS_ERR(net)`, the function directly called `cfg80211_switch_netns()` if
the wiphy was not already in that netns. After: it first checks
`ns_capable(net->user_ns, CAP_NET_ADMIN)`, drops the netns reference
with `put_net(net)`, and returns `-EPERM` on failure.

Record: Bug category is security authorization / logic correctness. The
missing check allowed a source-netns-capable caller to affect a
different target netns without privilege there.

Record: Fix quality is high: small, localized, follows the verified
rtnetlink convention in `rtnl_get_net_ns_capable()`, and preserves
reference cleanup. Regression risk is low and limited to denying
previously accepted unauthorized cross-netns moves.

### Phase 3: Git History Investigation
Record: `git blame` on the current stable checkout blamed the function
body to a repository snapshot-style commit, so it was not useful for
introduction history. `git log v2.6.29..v2.6.32 -S...` found the
command/function introduced by `463d018323851` (`cfg80211: make aware of
net namespaces`), first contained in `v2.6.32-rc1`.

Record: No `Fixes:` tag is present, so there was no tagged commit to
follow.

Record: Recent local `net/wireless/nl80211.c` history showed unrelated
wireless fixes/conversions and no existing equivalent target-netns
capability fix.

Record: No local prior `Maoyi Xie` commits were found under
`net/wireless`. `MAINTAINERS` verifies Johannes Berg as maintainer for
`802.11 (including CFG80211/NL80211)`, and the patch was addressed to
Johannes on linux-wireless.

Record: No code dependency was found for this patch. It is patch 1/2 in
the submitted series; patch 2 is related namespace hardening, but patch
1 is standalone for the direct permission bypass.

### Phase 4: Mailing List And External Research
Record: No commit hash was provided and the exact subject was not found
in local `master`, `wireless-next`, `net-next`, or `fixes-next`, so `b4
dig -c <commit>` was not applicable. I used the provided message-id with
`b4 am`/`b4 mbox`.

Record: `b4 am` found `[PATCH v3 0/2] wifi: nl80211: tighten netns
handling in SET_WIPHY_NETNS and dump continuation`, including this patch
as `v3 1/2`. `b4 am -c` did not report a newer revision. Attempts to
fetch v1/v2 directly with `b4 -v 1/-v 2` did not find those revisions,
but the v3 cover records that patch 1 was unchanged since v1.

Record: The full mbox contained three messages: cover, patch 1, patch 2.
It did not contain reviewer reply messages, but the cover records
Johannes review feedback about trailers/comment wording and says no code
changes since v2.

Record: Original recipients were Johannes Berg, `linux-
wireless@vger.kernel.org`, and `linux-kernel@vger.kernel.org`. No stable
nomination or NAK was found in the fetched mbox. Lore WebFetch searches
were blocked by Anubis, so stable-list discussion could not be
independently verified through WebFetch.

### Phase 5: Code Semantic Analysis
Record: Modified function: `nl80211_wiphy_netns()`.

Record: Caller surface: the only direct reference is the generic-netlink
op for `NL80211_CMD_SET_WIPHY_NETNS`; `genl_family_rcv_msg()` checks
`GENL_UNS_ADMIN_PERM` against `net->user_ns`, then
`genl_family_rcv_msg_doit()` calls `ops->doit()`, reaching
`nl80211_wiphy_netns()` from userspace netlink.

Record: Key callees: `get_net_ns_by_pid()`, `get_net_ns_by_fd()`, new
`ns_capable(net->user_ns, CAP_NET_ADMIN)`, `cfg80211_switch_netns()`,
and `put_net()`. `cfg80211_switch_netns()` moves associated wireless
netdevs with `dev_change_net_namespace()` and updates `wiphy_net_set()`.

Record: Reachability is verified by the op table and by the b4 cover’s
PoC. A userspace caller can trigger the path by sending
`NL80211_CMD_SET_WIPHY_NETNS` with target PID or netns fd.

Record: Similar convention verified in `rtnl_get_net_ns_capable()`,
which checks target `net->user_ns` before using another netns.

### Phase 6: Stable Tree Analysis
Record: The vulnerable handler/op shape exists in `v5.4`, `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and current `7.0.y`, with no
`ns_capable(net->user_ns, CAP_NET_ADMIN)` check in the handler.

Record: `v3.18` has `NL80211_CMD_SET_WIPHY_NETNS`, but uses
`GENL_ADMIN_PERM`, so the unprivileged-user-namespace aspect is not the
same there. For active modern stable trees, the issue is present.

Record: `git apply --check` of the fetched v3 mbox succeeds on the
current `7.0.y` checkout. Older stable trees have line offsets and minor
surrounding differences, but the same local hunk context exists at least
in `v5.4`; expected backport difficulty is clean or minor-context-only.

Record: No related local fix already present was found by subject/grep
searches.

### Phase 7: Subsystem Context
Record: Subsystem is cfg80211/nl80211 wireless configuration.
Criticality is IMPORTANT: it is not core-mm/VFS, but it is a userspace-
facing network configuration and permission boundary.

Record: The wireless subsystem is active in local history, with recent
cfg80211/nl80211-adjacent fixes.

### Phase 8: Impact And Risk
Record: Affected users are systems with cfg80211/nl80211, network
namespaces/user namespaces, and a `WIPHY_FLAG_NETNS_OK` wiphy. Verified
examples include `mac80211` and drivers setting the flag such as
`brcmfmac`, `mwifiex`, and `qtnfmac`.

Record: Trigger requires the caller to hold a movable wiphy in its own
netns and pass a target netns fd or pid. The b4 cover verifies this is
reachable from an unprivileged user namespace after legitimate admin
delegation using `mac80211_hwsim`.

Record: Failure mode is a security/namespace isolation violation:
unauthorized movement of a wiphy into a netns, including `init_net`,
where the caller lacks privilege. Severity is HIGH because it bypasses
kernel namespace permission boundaries.

Record: Benefit is high for stable users because it closes a concrete
privilege boundary bug. Risk is low: 13 lines, one function, no new API,
no data structure change, and only unauthorized operations change
behavior.

### Phase 9: Final Synthesis
Record: Evidence for backporting: real security/authorization bug,
concrete PoC in the submitted cover, reachable userspace netlink
command, vulnerable code present across modern stable trees, small
contained fix, and it mirrors an existing rtnetlink convention.

Record: Evidence against backporting: no `Fixes:`/stable tag, no fetched
reviewer reply carrying an explicit stable nomination, and the exact
applied commit hash was not present in local searched branches. These do
not outweigh the verified technical issue.

Record: Unresolved: I could not verify the final applied commit object
or run `b4 dig -c` because no commit hash was provided and local branch
searches did not find the subject. WebFetch to lore/stable was blocked
by Anubis. I did not run the runtime PoC or a kernel build.

Stable rules checklist:
1. Obviously correct and tested: yes by inspection; PoC result described
   in b4 cover, though not locally rerun.
2. Fixes a real bug affecting users: yes, verified missing target-netns
   authorization.
3. Important issue: yes, security/namespace permission bypass.
4. Small and contained: yes, one function, 13 added lines.
5. No new features or APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; older active stable
   trees likely clean/minor context based on matching code.

Exception category: none. This is not a device ID/quirk/build/doc fix;
it is a security permission fix.

## Verification
- [Phase 1] Parsed provided subject/tags and b4-fetched patch/cover;
  found no `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, or
  stable tag.
- [Phase 2] Compared provided diff and b4 mbox patch; confirmed 13 lines
  added to `nl80211_wiphy_netns()`.
- [Phase 3] `git blame -L` was not useful due snapshot-style history;
  `git log v2.6.29..v2.6.32 -S...` found `463d018323851`, first
  contained in `v2.6.32-rc1`.
- [Phase 3] `git log --author='Maoyi Xie' -- net/wireless` found no
  local prior commits.
- [Phase 3] `MAINTAINERS` confirms Johannes Berg maintains `802.11
  (including CFG80211/NL80211)`.
- [Phase 4] `b4 am` found v3 2-patch series and the supplied patch
  message-id.
- [Phase 4] `b4 am -c` found no newer revision.
- [Phase 4] `b4 mbox` saved the full 3-message thread; no stable
  nomination or NAK was present there.
- [Phase 5] `rg` confirmed `nl80211_wiphy_netns()` is reached via the
  `NL80211_CMD_SET_WIPHY_NETNS` generic-netlink op.
- [Phase 5] Read `genetlink.c`; confirmed `GENL_UNS_ADMIN_PERM` checks
  `net->user_ns` before calling `ops->doit()`.
- [Phase 5] Read `cfg80211_switch_netns()`; confirmed it moves wireless
  netdevs and changes the wiphy netns.
- [Phase 6] Checked `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
  `v6.19`, and current `7.0.y`; all have the handler/op without the
  target `ns_capable()` check.
- [Phase 6] `git apply --check` of the b4 mbox succeeded on current
  `7.0.y`.
- [Phase 8] `rg WIPHY_FLAG_NETNS_OK` verified affected mac80211 and
  several wireless drivers expose movable wiphys.
- UNVERIFIED: exact final commit SHA and final applied-object metadata,
  because the subject was not found in local searched branches.
- UNVERIFIED: stable-list discussion via WebFetch, because lore WebFetch
  returned Anubis anti-bot pages.
- UNVERIFIED: local runtime PoC/build; not performed.

This should be backported to stable kernel trees that contain the
`GENL_UNS_ADMIN_PERM` version of `NL80211_CMD_SET_WIPHY_NETNS`,
especially active v5.4+ stable/LTS trees.

**YES**

 net/wireless/nl80211.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ce3121b1c3319..13c2943ad3e4b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13568,6 +13568,19 @@ static int nl80211_wiphy_netns(struct sk_buff *skb, struct genl_info *info)
 	if (IS_ERR(net))
 		return PTR_ERR(net);
 
+	/*
+	 * The caller already has CAP_NET_ADMIN over the source netns
+	 * (enforced by GENL_UNS_ADMIN_PERM on the genl op). Mirror the
+	 * convention used by net/core/rtnetlink.c::rtnl_get_net_ns_capable()
+	 * and require CAP_NET_ADMIN over the target netns as well, so that
+	 * a caller that is privileged in their own user namespace cannot
+	 * push a wiphy into a netns where they have no privilege.
+	 */
+	if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+		put_net(net);
+		return -EPERM;
+	}
+
 	err = 0;
 
 	/* check if anything to do */
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] HID: elan: Add support for ELAN SB974D touchpad

[Sasha Levin]

From: Damien Dejean <damiendejean@google.com>

[ Upstream commit 55ce1858848132ed074fe907f00b5ce1ccab0ce1 ]

Elan SB974D touchpad uses ELAN_MT_I2C format to send HID reports. Add an
entry to match for the device and parse its vendor specific format.

Signed-off-by: Damien Dejean <damiendejean@google.com>
Signed-off-by: Kornel Dulęba <korneld@google.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

Step 1.1 Record: subsystem `HID: elan`; action verb `Add support`;
intent is to add ELAN SB974D touchpad matching so the existing ELAN HID
driver parses its vendor-specific I2C multitouch reports.

Step 1.2 Record: tags are:
- `Signed-off-by: Damien Dejean <damiendejean@google.com>`
- `Signed-off-by: Kornel Dulęba <korneld@google.com>`
- `Signed-off-by: Jiri Kosina <jkosina@suse.com>`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Cc: stable`, or `Link:` tags are present.

Step 1.3 Record: the body says SB974D uses `ELAN_MT_I2C` report format
and needs an ID table entry so `hid-elan` handles and parses that
format. Symptom is unsupported or generic handling of this touchpad, not
a crash. No affected-version statement.

Step 1.4 Record: this is not a hidden memory/race/crash fix. It is a
hardware enablement/device-ID addition to an existing driver, which is a
stable exception category.

## Phase 2: Diff Analysis

Step 2.1 Record: two files changed, 2 insertions total:
- `drivers/hid/hid-elan.c`: adds one `HID_I2C_DEVICE()` entry to
  `elan_devices`.
- `drivers/hid/hid-ids.h`: adds `USB_DEVICE_ID_SB974D 0x0400`.
Modified data structure: `elan_devices[]`. Scope: single-driver,
surgical ID addition.

Step 2.2 Record: before, ELAN I2C product `0x0400` did not match `hid-
elan`; after, BUS_I2C vendor `0x04f3` product `0x0400` matches `hid-
elan` and uses existing probe/raw-event paths.

Step 2.3 Record: bug category is hardware support/device ID addition. No
new parser, locking, memory management, or API change. The fix works by
routing this specific I2C HID device to already-existing `ELAN_MT_I2C`
handling.

Step 2.4 Record: fix quality is high: two-line addition, localized,
mirrors the existing Toshiba I2C ELAN entry, and has very low regression
risk. Main possible risk is binding product `0x0400` to `hid-elan`, but
the commit message and external fwupd discussion verify `04f3:0400` is
an ELAN touchpad PID.

## Phase 3: Git History Investigation

Step 3.1 Record: `git blame` shows `elan_devices[]` was introduced by
`9a6a4193d65b` in v4.17-rc1 range; the existing I2C Toshiba entry was
introduced by `e7ad3dc9f4a2` in v4.19-rc1 range. This means the required
driver and I2C-format support are old and present in long-term stable
lines.

Step 3.2 Record: no `Fixes:` tag, so no introducing bug commit to
follow.

Step 3.3 Record: recent history shows this commit is standalone; only
later related file change found was unrelated `HID: i2c-hid: add reset
quirk for BLTP7853 touchpad`.

Step 3.4 Record: author Damien Dejean has only this HID commit in the
checked `origin/master` HID history. Jiri Kosina committed/applied it;
`MAINTAINERS` lists Jiri Kosina and Benjamin Tissoires as HID core
maintainers.

Step 3.5 Record: no prerequisite commits found beyond the existing `hid-
elan` driver and I2C parser, both already present in checked stable
branches.

## Phase 4: Mailing List And External Research

Step 4.1 Record: `b4 dig -c 55ce185884813` found the original patch at `
https://patch.msgid.link/20260414133858.3992799-1-
damiendejean@google.com`. `b4 dig -a` showed only v1, no later
revisions.

Step 4.2 Record: `b4 dig -w` showed recipients included Jiri Kosina,
Benjamin Tissoires, `linux-input@vger.kernel.org`, `linux-
kernel@vger.kernel.org`, Damien Dejean, and Kornel Dulęba.

Step 4.3 Record: no `Reported-by` or bug-report `Link:`. The lore thread
mbox contains Jiri Kosina’s “Applied to hid.git#for-7.1/upstream-fixes,
thanks.” No NAKs or concerns in the saved thread.

Step 4.4 Record: no multi-patch series; standalone patch.

Step 4.5 Record: lore WebFetch hit Anubis, but `b4` successfully fetched
the mbox. Stable branch grep found no existing `SB974D` backport in
`stable/linux-7.0.y` or `stable/linux-6.19.y`.

## Phase 5: Code Semantic Analysis

Step 5.1 Record: modified table is `elan_devices[]`; functional paths
affected are existing callbacks `elan_probe`, `elan_input_mapping`,
`elan_input_configured`, and `elan_raw_event`.

Step 5.2 Record: `hid_match_device()` matches `hdrv->id_table`;
`hid_device_probe()` calls the matched driver’s `.probe`;
`hid_input_report()` calls `.raw_event`. Thus the new ID makes this
hardware reach existing `hid-elan` probe and report parsing.

Step 5.3 Record: relevant callees include `hid_parse`, `hid_hw_start`,
`elan_start_multitouch`, and for I2C reports `elan_i2c_report_input`.

Step 5.4 Record: reachability is hardware enumeration and HID input
report delivery. Users of the SB974D touchpad hit this during device
probe and normal touch input.

Step 5.5 Record: similar pattern exists in the same driver for
`USB_DEVICE_ID_TOSHIBA_CLICK_L9W`, also using `HID_I2C_DEVICE()` and the
existing `ELAN_MT_I2C` path.

## Phase 6: Stable Tree Analysis

Step 6.1 Record: checked stable branches `5.10.y`, `5.15.y`, `6.1.y`,
`6.6.y`, `6.12.y`, `6.18.y`, `6.19.y`, and `7.0.y`; all contain
`CONFIG_HID_ELAN`, `drivers/hid/hid-elan.c`, and the existing
`TOSHIBA_CLICK_L9W` I2C ELAN entry.

Step 6.2 Record: `git apply --check` succeeded on current `7.0.y`,
`6.19.y`, and representative older stable worktrees `5.10.y`, `5.15.y`,
`6.1.y`, `6.6.y`, `6.12.y`, `6.18.y`.

Step 6.3 Record: no related `SB974D` fix already present in checked
stable branches.

## Phase 7: Subsystem Context

Step 7.1 Record: subsystem is HID input driver support. Criticality is
driver-specific/peripheral, affecting users of this ELAN SB974D touchpad
hardware.

Step 7.2 Record: HID is actively maintained; this patch was applied
through `hid.git#for-7.1/upstream-fixes` by HID maintainer Jiri Kosina.

## Phase 8: Impact And Risk

Step 8.1 Record: affected population is hardware-specific: systems with
ELAN SB974D I2C touchpad and `CONFIG_HID_ELAN`.

Step 8.2 Record: trigger is device enumeration and normal touchpad input
on that hardware. No evidence found that unprivileged users can trigger
a security issue; this is hardware functionality.

Step 8.3 Record: failure mode without the patch is lack of proper `hid-
elan` handling for this touchpad’s vendor-specific `ELAN_MT_I2C` report
format. Severity is medium for affected hardware because touchpad
functionality is user-visible, but not a crash/corruption/security
issue.

Step 8.4 Record: benefit is high for affected hardware and low globally.
Risk is very low: two lines, no behavior change for unrelated device
IDs, no API change, and clean apply to checked stable branches.

## Phase 9: Final Synthesis

Evidence for backporting: this is exactly the stable exception for
adding a new device ID to an existing driver; the driver and parser
already exist in stable; the patch is tiny, cleanly applies, and was
accepted by the HID maintainer. Evidence against: it is hardware
enablement rather than a conventional critical bug fix, and there is no
user bug report or `Tested-by` tag in the commit.

Stable rules:
1. Obviously correct and tested? Code is obviously correct by
   inspection; explicit testing tag absent.
2. Fixes a real user-visible issue? Yes for affected SB974D systems:
   proper touchpad driver binding/report parsing.
3. Important issue? Medium hardware functionality issue, not
   crash/corruption/security.
4. Small and contained? Yes, 2 insertions in HID.
5. No new APIs/features? No API; hardware ID addition only.
6. Can apply to stable? Yes, verified across representative active
   stable branches.

Exception category: new device ID added to an existing driver. This is
stable-suitable.

## Verification

- Phase 1: `git show --format=fuller 55ce185884813` verified subject,
  body, author, committer, and tags.
- Phase 2: `git show --stat` and full diff verified exactly 2 insertions
  in `hid-elan.c` and `hid-ids.h`.
- Phase 3: `git blame` verified table history; `git describe --contains`
  placed original driver support around v4.17-rc1 and I2C support around
  v4.19-rc1.
- Phase 3: `git log --oneline` checks found no dependent SB974D series
  and only this author’s HID commit in the checked range.
- Phase 4: `b4 dig`, `b4 dig -a`, and `b4 dig -w` verified original lore
  submission, single v1, recipients, and maintainer application.
- Phase 4: WebFetch to lore/stable was blocked by Anubis; the saved `b4`
  mbox was used instead.
- Phase 5: `ReadFile` and `rg` verified `elan_probe`, `elan_raw_event`,
  `elan_i2c_report_input`, `hid_match_device`, and `hid_input_report`
  call paths.
- Phase 6: `git grep` verified relevant stable branches contain
  `HID_ELAN` and the existing ELAN I2C entry.
- Phase 6: `git apply --check` verified clean application to `7.0.y`,
  `6.19.y`, `6.18.y`, `6.12.y`, `6.6.y`, `6.1.y`, `5.15.y`, and
  `5.10.y`.
- Phase 7: `MAINTAINERS` verified Jiri Kosina and Benjamin Tissoires as
  HID maintainers.
- Phase 8: no sanitizer report, crash report, or security impact was
  found; decision is driven by the verified device-ID stable exception.

**YES**

 drivers/hid/hid-elan.c | 1 +
 drivers/hid/hid-ids.h  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/hid/hid-elan.c b/drivers/hid/hid-elan.c
index 76d93fc48f6a2..0190ad567ce4d 100644
--- a/drivers/hid/hid-elan.c
+++ b/drivers/hid/hid-elan.c
@@ -513,6 +513,7 @@ static const struct hid_device_id elan_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_ELAN, USB_DEVICE_ID_HP_X2_10_COVER),
 	  .driver_data = ELAN_HAS_LED },
 	{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, USB_DEVICE_ID_TOSHIBA_CLICK_L9W) },
+	{ HID_I2C_DEVICE(USB_VENDOR_ID_ELAN, USB_DEVICE_ID_SB974D) },
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, elan_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c1e4a6ce96317..c371721826dcc 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -455,6 +455,7 @@
 #define USB_DEVICE_ID_EDIFIER_QR30	0xa101	/* EDIFIER Hal0 2.0 SE */
 
 #define USB_VENDOR_ID_ELAN		0x04f3
+#define USB_DEVICE_ID_SB974D            0x0400
 #define USB_DEVICE_ID_TOSHIBA_CLICK_L9W	0x0401
 #define USB_DEVICE_ID_HP_X2		0x074d
 #define USB_DEVICE_ID_HP_X2_10_COVER	0x0755
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] media: qcom: camss: avoid format string warning

[Sasha Levin]

From: Arnd Bergmann <arnd@arndb.de>

[ Upstream commit 23c39cb598977f10909a2387c5e5f34afc1d6933 ]

clang-22 warns about csiphy_match_clock_name() taking a variable format
string that is not checked against the 'int index' argument:

drivers/media/platform/qcom/camss/camss-csiphy.c:566:44: error: diagnostic behavior may be improved by
      adding the 'format(printf, 2, 3)' attribute to the declaration of 'csiphy_match_clock_name'
      [-Werror,-Wmissing-format-attribute]
  561 | static bool csiphy_match_clock_name(const char *clock_name, const char *format,
      | __attribute__((format(printf, 2, 3)))
  562 |                                     int index)
  563 | {
  564 |         char name[16]; /* csiphyXXX_timer\0 */
  565 |
  566 |         snprintf(name, sizeof(name), format, index);
      |                                                   ^
drivers/media/platform/qcom/camss/camss-csiphy.c:561:13: note: 'csiphy_match_clock_name' declared here
  561 | static bool csiphy_match_clock_name(const char *clock_name, const char *format,
      |             ^

Change the function to use a snprintf() style format string that allows this
to be checked at the call site.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `media: qcom: camss`; action verb is
`avoid`; claimed intent is to avoid a clang-22 format-string build
warning/error in `csiphy_match_clock_name()`.

Step 1.2 Record: Verified fetched commit
`2211e826bd69c041534093735241182013dde7bc` has:
- `Signed-off-by: Arnd Bergmann <arnd@arndb.de>`
- `Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>`
- `Signed-off-by: Bryan O'Donoghue <bod@kernel.org>`

The original lore submission also has `Fixes: 0727615fb975 ("media:
qcom: camss: Functionally decompose CSIPHY clock lookups")`. No
`Reported-by`, `Tested-by`, `Cc: stable`, or bug-report `Link` was
verified.

Step 1.3 Record: The body describes a clang-22 diagnostic promoted to
error: `[-Werror,-Wmissing-format-attribute]`. The root cause is that
`csiphy_match_clock_name()` takes a `const char *format` and passes it
to `snprintf()` with a fixed `int index`, but the helper itself lacks a
checkable printf-style prototype.

Step 1.4 Record: This is not a hidden runtime bug fix. It is a build-
warning/build-error fix for newer clang plus warning-as-error
configurations.

### Phase 2: Diff Analysis
Step 2.1 Record: One file changed:
`drivers/media/platform/qcom/camss/camss-csiphy.c`, `7 insertions(+), 3
deletions(-)`. One function modified: `csiphy_match_clock_name()`. Scope
is single-file surgical.

Step 2.2 Record: Before, the helper accepted `format, int index` and
called `snprintf(name, sizeof(name), format, index)`. After, it is
declared `__printf(2, 3)`, accepts varargs, uses `va_start()`,
`vsnprintf()`, and `va_end()`. Call sites remain unchanged.

Step 2.3 Record: Bug category is build fix / compiler diagnostic fix. It
does not fix memory safety, locking, refcounting, or runtime logic.

Step 2.4 Record: The fix is mechanically correct and minimal. Existing
callers pass literal format strings plus `csiphy->id`, so behavior is
preserved while allowing compiler format checking. Regression risk is
very low; the only meaningful risk is varargs misuse, but current call
sites were verified unchanged and simple.

### Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the helper body was introduced by
`0727615fb975f6`, authored by Bryan O'Donoghue on 2023-09-25. `git
describe --contains` places it at `v6.7-rc1~51^2~149`.

Step 3.2 Record: The final fetched commit lacks a `Fixes:` trailer, but
the original lore submission includes `Fixes: 0727615fb975`. I inspected
that commit; it introduced the helper and the `snprintf(..., format,
index)` pattern.

Step 3.3 Record: Recent file history includes later CAMSS/CSIPHY
changes, especially `74cae7794341` changing callers to use `csiphy->id`.
No prerequisite for this format-warning fix was found beyond the helper
existing.

Step 3.4 Record: Arnd Bergmann has prior CAMSS build/undefined-behavior
fixes in history. Bryan O'Donoghue, who reviewed the patch, is listed as
a CAMSS maintainer in `MAINTAINERS`.

Step 3.5 Record: No dependent commits were found. The patch only needs
the existing helper and kernel `__printf`/`va_list` support, both
present in the checked tree.

### Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 2211e826...` found the original patch at
`https://patch.msgid.link/20260320151828.3456863-1-arnd@kernel.org`. `b4
dig -a` found only v1.

Step 4.2 Record: `b4 dig -w` shows relevant maintainers/lists were
included: CAMSS maintainers, media maintainers, `linux-media`, `linux-
arm-msm`, `linux-kernel`, and `llvm`.

Step 4.3 Record: No separate bug report was present. The concrete report
is the compiler diagnostic embedded in the patch.

Step 4.4 Record: This is a standalone one-patch fix, not part of a
multi-patch series.

Step 4.5 Record: Direct lore stable search was blocked by Anubis; web
search did not find stable-specific discussion for this exact patch.

### Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `csiphy_match_clock_name()`.

Step 5.2 Record: Callers are only within `msm_csiphy_subdev_init()`, at
the three verified clock-name checks: `"csiphy%d_timer"`, `"csi%d_phy"`,
and `"csiphy%d"`.

Step 5.3 Record: The helper calls formatting and string comparison
functions: previously `snprintf()` and `strcmp()`, after patch
`vsnprintf()` and `strcmp()`.

Step 5.4 Record: The affected path is CAMSS device probe:
`camss_probe()` calls `camss_init_subdevices()`, which calls
`msm_csiphy_subdev_init()`. Runtime behavior remains equivalent for the
verified call sites.

Step 5.5 Record: Nearby CAMSS code has no other `const char *format`
helper or `vsnprintf()`/`__printf()` pattern matching this issue.

### Phase 6: Stable Tree Analysis
Step 6.1 Record: The buggy helper exists from `v6.7` onward. Verified
absent in `v6.6`, present in `v6.12`, and present in `v7.0`.

Step 6.2 Record: `git apply --check` succeeds against the current
`7.0.5` checkout. For `v6.12`, the same helper and `snprintf(name,
sizeof(name), format, index)` pattern are present, but I did not run a
separate worktree apply check.

Step 6.3 Record: No related stable-specific fix for this exact CAMSS
warning was found in local targeted searches or public web search.

### Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is Qualcomm CAMSS media driver under
`drivers/media/platform/qcom/camss/`. Criticality is peripheral/driver-
specific, but build failures affect anyone building this driver or
COMPILE_TEST coverage.

Step 7.2 Record: CAMSS is actively developed; recent history shows many
CAMSS commits, including fixes and new platform support.

### Phase 8: Impact And Risk
Step 8.1 Record: Affected population is config-specific: builders with
`CONFIG_VIDEO_QCOM_CAMSS`, including `COMPILE_TEST`, using clang-22 with
`-Wmissing-format-attribute` and warnings-as-errors.

Step 8.2 Record: Trigger is build-time, not runtime.
`scripts/Makefile.warn` verifies `-Wmissing-format-attribute` is under
`W=1`; `-Werror` is enabled by `W=e` or `CONFIG_WERROR`.

Step 8.3 Record: Failure mode is build failure, not
crash/corruption/security. Severity is medium, but build fixes are an
accepted stable exception.

Step 8.4 Record: Benefit is moderate: keeps affected stable builds
working with newer clang warning behavior. Risk is very low: 10-line
single-function mechanical change, no API change, call sites unchanged.

### Phase 9: Final Synthesis
Evidence for backporting:
- Real build failure mode documented in commit and lore.
- Fits stable build-fix exception.
- Very small, contained, reviewed by CAMSS maintainer.
- Applies cleanly to current `7.0.5`; buggy code exists in `v6.12+` and
  `v7.0`.

Evidence against backporting:
- Not a runtime correctness, crash, data corruption, or security fix.
- Trigger requires specific compiler/warning-as-error build settings.
- Not relevant to `v6.6` and older because the helper is absent there.

Stable rules checklist:
1. Obviously correct and tested: yes for code review/readability; no
   local clang-22 build reproduction.
2. Fixes a real bug: yes, a verified build diagnostic/error path.
3. Important issue: medium; build failure, not runtime failure.
4. Small and contained: yes, one function, one file, 7+/3-.
5. No new feature/API: yes.
6. Can apply to stable: verified for current `7.0.5`; likely
   straightforward for `v6.12+`, not applicable to `v6.6` and older.

Exception category: Build fix.

## Verification
- Phase 1: `git show` verified candidate commit metadata and exact diff
  for `2211e826bd69...`.
- Phase 2: `git diff --shortstat` verified `1 file changed, 7
  insertions(+), 3 deletions(-)`.
- Phase 3: `git blame` verified helper introduced by `0727615fb975`;
  `git show` inspected that commit.
- Phase 3/6: `git describe --contains` and tag containment checks
  verified introduction in `v6.7`, presence in `v6.12+`, absence from
  `v6.6`.
- Phase 4: `b4 dig`, `b4 dig -a`, `b4 dig -w`, and saved mbox verified
  original lore thread, v1-only series, recipients, `Fixes:` trailer,
  and Bryan’s review.
- Phase 5: `rg` and file reads verified call sites and probe call chain.
- Phase 6: `git apply --check` verified clean apply to current `7.0.5`.
- Phase 7: `MAINTAINERS` verified Bryan O'Donoghue is a CAMSS
  maintainer.
- Phase 8: `scripts/Makefile.warn` verified when `-Wmissing-format-
  attribute` and `-Werror` are enabled.
- UNVERIFIED: I did not reproduce the clang-22 build failure locally.
- UNVERIFIED: I did not perform an actual `git apply --check` in a
  separate `v6.12` worktree.

This is stable-worthy as a low-risk build fix for stable trees that
contain the helper, especially `v6.12+`/`v7.0` era trees, and should be
skipped for older trees where the code does not exist.

**YES**

 drivers/media/platform/qcom/camss/camss-csiphy.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
index 62623393f4144..78a1b568dbae6 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -558,12 +558,16 @@ static int csiphy_init_formats(struct v4l2_subdev *sd,
 	return csiphy_set_format(sd, fh ? fh->state : NULL, &format);
 }
 
-static bool csiphy_match_clock_name(const char *clock_name, const char *format,
-				    int index)
+static bool __printf(2, 3)
+csiphy_match_clock_name(const char *clock_name, const char *format, ...)
 {
 	char name[16]; /* csiphyXXX_timer\0 */
+	va_list args;
+
+	va_start(args, format);
+	vsnprintf(name, sizeof(name), format, args);
+	va_end(args);
 
-	snprintf(name, sizeof(name), format, index);
 	return !strcmp(clock_name, name);
 }
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] HID: i2c-hid: add reset quirk for BLTP7853 touchpad

[Sasha Levin]

From: Xu Rao <raoxu@uniontech.com>

[ Upstream commit a991aa5e89365ba1959fae6847fd288125b209e5 ]

The BLTP7853 I2C HID touchpad may fail to probe after reboot or
reprobe because reset completion is not signalled to the host. The
driver then waits for the reset-complete interrupt until it times out
and the device probe fails:

  i2c_hid i2c-BLTP7853:00: failed to reset device.
  i2c_hid i2c-BLTP7853:00: can't add hid device: -61
  i2c_hid: probe of i2c-BLTP7853:00 failed with error -61

Add I2C_HID_QUIRK_NO_IRQ_AFTER_RESET for the device so i2c-hid does
not wait for a reset interrupt that may never arrive.

Signed-off-by: Xu Rao <raoxu@uniontech.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record: subsystem `HID: i2c-hid`; action verb `add`; intent is to add a
reset-handling quirk for the BLTP7853 touchpad.

Record: tags present are `Signed-off-by: Xu Rao <raoxu@uniontech.com>`
and `Signed-off-by: Jiri Kosina <jkosina@suse.com>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, `Link:`, or
`Cc: stable@vger.kernel.org` tags are present in the supplied message.

Record: the commit message describes a real probe failure: the device
may not signal reset completion after reboot or reprobe, the driver
waits for reset completion, and probe fails with `-61` / `-ENODATA`. The
root cause given is missing reset-complete IRQ from the device.

Record: this is not hidden as cleanup; it is explicitly a hardware
workaround for a probe failure.

### Phase 2: Diff Analysis
Record: files changed are `drivers/hid/hid-ids.h` with 3 additions and
`drivers/hid/i2c-hid/i2c-hid-core.c` with 2 additions. Total scope: 5
added lines, no removals. No function body is changed; the modified
object is the private `i2c_hid_quirks[]` table.

Record: before the patch, vendor/product `0x36b6/0xc001` had no private
i2c-hid quirk entry, so the reset path used normal reset-ack waiting.
After the patch, `i2c_hid_lookup_quirk()` can match the BLTP7853 IDs and
set `I2C_HID_QUIRK_NO_IRQ_AFTER_RESET`.

Record: in current code, `I2C_HID_QUIRK_NO_IRQ_AFTER_RESET` makes
`i2c_hid_finish_hwreset()` sleep 100 ms and clear
`I2C_HID_RESET_PENDING` instead of waiting for a reset IRQ. In older
stable code, the same quirk skips the 5 second wait path that returns
`-ENODATA`.

Record: bug category is hardware workaround / quirk. Specific mechanism:
a device that does not raise the expected reset-complete interrupt is
handled through an existing no-IRQ-after-reset path.

Record: fix quality is high: tiny table-only change, uses existing
infrastructure, no new API, no locking change, no cross-subsystem
behavior. Regression risk is very low and limited to devices reporting
exactly the new vendor/product pair.

### Phase 3: Git History Investigation
Record: exact candidate subject was not found in local `git log` on
`master`, `all-next`, `fixes-next`, `input-next`, `pending-7.0`, or
`for-greg/7.0-200`; no candidate commit hash was available to blame the
newly added lines.

Record: existing no-IRQ reset quirk support was introduced by
`402946a8ef71e` (`HID: i2c-hid: Add no-irq-after-reset quirk for
0911:5288 device`), contained since `v4.15-rc1`. Related Voyo quirk
`fc6a31b007393` shows the same failure pattern: repeated `failed to
reset device` and final `can't add hid device: -61`.

Record: no `Fixes:` tag is present, so Step 3.2 is not applicable.

Record: recent history contains normal HID/i2c-hid quirk and fix
activity. Relevant related changes include `7bcf9ebb50f2a` (`Turn
missing reset ack into a warning`) and older device-specific no-IRQ
quirks. No prerequisite was identified beyond existing
`I2C_HID_QUIRK_NO_IRQ_AFTER_RESET` support.

Record: local `git log --author="Xu Rao" -- drivers/hid` found no HID
commits on `master`. `MAINTAINERS` confirms Jiri Kosina is an HID core
maintainer, and he signed off the supplied commit.

### Phase 4: Mailing List And External Research
Record: candidate `b4 dig` could not be performed because the exact
candidate commit hash is unavailable and the subject is not present in
local reachable history.

Record: `b4 dig -c 402946a8ef71e` found the original related no-IRQ-
after-reset quirk submission at
`https://patch.msgid.link/20171107122800.23196-1-hdegoede@redhat.com`;
`b4 dig -a` showed v1 and v2; `b4 dig -w` showed HID maintainers and
`linux-input@vger.kernel.org` were included.

Record: `b4 dig -c 7bcf9ebb50f2a` found the reset-ack warning patch as
`[PATCH v3 5/7]`.

Record: web searches for the exact BLTP7853 reset-quirk subject and
stable-list discussion found no direct candidate thread. Searches did
find related BLTP7853 touchpad reports, but not independent confirmation
of this exact `0x36b6/0xc001` reset failure.

### Phase 5: Code Semantic Analysis
Record: modified key object is `i2c_hid_quirks[]`; relevant functions
are `i2c_hid_lookup_quirk()`, `__i2c_hid_core_probe()`,
`i2c_hid_finish_hwreset()`, and older-branch `i2c_hid_command()`
behavior.

Record: callers verified: `i2c_hid_core_probe()` is called from ACPI,
OF, ELAN, and Goodix i2c-hid probe drivers. `__i2c_hid_core_probe()`
reads HID descriptor vendor/product IDs and calls
`i2c_hid_lookup_quirk()`.

Record: call chain is device enumeration/probe: platform driver probe ->
`i2c_hid_core_probe()` -> `__i2c_hid_core_probe()` ->
`i2c_hid_lookup_quirk()` -> HID registration -> reset during HID parse.
This is reachable during boot, reboot, and reprobe for affected
hardware.

Record: similar patterns exist for HANTICK, ITE/Voyo, and Raydium
devices already using `I2C_HID_QUIRK_NO_IRQ_AFTER_RESET`.

### Phase 6: Stable Tree Analysis
Record: `I2C_HID_QUIRK_NO_IRQ_AFTER_RESET` exists in active checked
stable branches `5.10.y`, `5.15.y`, `6.1.y`, `6.6.y`, `6.12.y`,
`6.18.y`, `6.19.y`, and `7.0.y`.

Record: BLTP-specific IDs from this patch are not present in those
checked branches or `master`.

Record: `5.10.y`, `5.15.y`, `6.1.y`, and `6.6.y` still have the reset-
ack timeout returning `-ENODATA`, matching the commit-message failure.
`6.12.y` and newer checked branches contain `7bcf9ebb50f2a`, where
missing reset ack is downgraded to a warning, so the benefit there is
mostly avoiding a delay/warning rather than fixing probe failure.

Record: patch applies cleanly to current `stable/linux-7.0.y` when
checked with `git apply --check`. Older stable trees may need minor
context adjustment due to file layout differences, but the required
quirk mechanism exists.

### Phase 7: Subsystem And Maintainer Context
Record: subsystem is HID/i2c-hid under `drivers/hid/`, criticality
`IMPORTANT` for users of affected laptop touchpad hardware.

Record: subsystem is actively maintained; `MAINTAINERS` lists HID core
as maintained by Jiri Kosina and Benjamin Tissoires.

### Phase 8: Impact And Risk
Record: affected population is hardware-specific: systems with an I2C
HID device reporting the BLTP7853 IDs added by this patch.

Record: trigger condition is probe/reprobe after reboot or reprobe, as
described by the commit message and matched to the older stable reset
path.

Record: failure severity is HIGH for older stable branches because the
touchpad can fail to bind at all. For newer branches with
`7bcf9ebb50f2a`, severity is LOW-MEDIUM because generic handling avoids
probe failure but still waits/logs.

Record: benefit is high for older stable users with this hardware; risk
is very low because the change is a narrow hardware quirk table entry.

### Phase 9: Final Synthesis
Evidence for backporting: real device probe failure, existing quirk
mechanism, tiny hardware-specific change, no new API, maintainer sign-
off, and older stable branches demonstrably still have the failing reset
timeout behavior.

Evidence against backporting: no direct candidate lore thread or
external bug report could be verified; exact hardware ID `0x36b6/0xc001`
was only verified from the supplied patch, not an external hardware
database. Newer stable branches already have generic missing-reset-ack
handling, reducing urgency there.

Stable rules: obviously correct by inspection, fixes a real hardware
probe failure on older stable branches, small and contained, no new
feature/API, and falls under the accepted hardware quirk exception.
Backport difficulty should be clean or minor.

## Verification
- [Phase 1] Parsed supplied message and tags: only Xu Rao and Jiri
  Kosina Signed-off-by tags present.
- [Phase 2] Read `drivers/hid/i2c-hid/i2c-hid-core.c`: verified quirk
  table and reset handling.
- [Phase 3] Searched local histories without `--all`: exact candidate
  not found; related no-IRQ quirk commits found.
- [Phase 3] Inspected `402946a8ef71e`, `fc6a31b007393`, and
  `7bcf9ebb50f2a`: confirmed same reset-ack quirk mechanism and later
  generic warning behavior.
- [Phase 4] Ran `b4 dig` for related commits; candidate `b4 dig` was not
  possible without a candidate hash.
- [Phase 5] Traced callers with `rg` and read ACPI/OF probe files:
  confirmed probe-time reachability.
- [Phase 6] Checked active stable branches: quirk support exists in all
  checked branches; old reset failure path exists through `6.6.y`;
  `6.12.y+` has generic warning handling.
- [Phase 6] Ran `git apply --check` against current `7.0.y`: patch shape
  applies cleanly.
- UNVERIFIED: original candidate lore discussion, independent bug
  report, and exact external hardware database confirmation for
  `0x36b6/0xc001`.

**YES**

 drivers/hid/hid-ids.h              | 3 +++
 drivers/hid/i2c-hid/i2c-hid-core.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index c371721826dcc..559040e47f3c7 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -277,6 +277,9 @@
 #define USB_VENDOR_ID_BIGBEN	0x146b
 #define USB_DEVICE_ID_BIGBEN_PS3OFMINIPAD	0x0902
 
+#define I2C_VENDOR_ID_BLTP		0x36b6
+#define I2C_PRODUCT_ID_BLTP7853		0xc001
+
 #define USB_VENDOR_ID_BTC		0x046e
 #define USB_DEVICE_ID_BTC_EMPREX_REMOTE	0x5578
 #define USB_DEVICE_ID_BTC_EMPREX_REMOTE_2	0x5577
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index 5a183af3d5c6a..baff2728603ec 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -149,6 +149,8 @@ static const struct i2c_hid_quirks {
 		 I2C_HID_QUIRK_BOGUS_IRQ },
 	{ I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_0D42,
 		 I2C_HID_QUIRK_DELAY_WAKEUP_AFTER_RESUME },
+	{ I2C_VENDOR_ID_BLTP, I2C_PRODUCT_ID_BLTP7853,
+		I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
 	{ 0, 0 }
 };
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] ALSA: hda/realtek: Limit mic boost on Positivo DN50E

[Sasha Levin]

From: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>

[ Upstream commit d02d2d51a50d1bbf44a50eda094aa2b10fecf023 ]

The internal mic boost on the Positivo DN50E is too high.
Fix this by applying the ALC269_FIXUP_LIMIT_INT_MIC_BOOST fixup to the machine
to limit the gain.

Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Link: https://patch.msgid.link/20260511181558.670563-1-edson.drosdeck@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Stable Backport Analysis

### Phase 1: Commit Message Forensics
Record 1.1: Subsystem is `ALSA: hda/realtek`; action is “Limit” / “Fix”;
claimed intent is to cap excessive internal microphone boost on Positivo
DN50E.

Record 1.2: Tags present are `Signed-off-by: Edson Juliano Drosdeck`,
`Link: https://patch.msgid.link/20260511181558.670563-1-
edson.drosdeck@gmail.com`, and `Signed-off-by: Takashi Iwai`. No
`Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or
`Cc: stable` tag was present.

Record 1.3: The described bug is excessive internal mic boost on this
machine. The existing fixup comment verifies the mechanism: boost levels
2 and 3 are “too noisy” on internal mic input, so the fixup limits boost
to levels 0 or 1.

Record 1.4: This is not a hidden bug fix; it is an explicit hardware
quirk for a user-visible audio problem.

### Phase 2: Diff Analysis
Record 2.1: One file changes: `sound/hda/codecs/realtek/alc269.c`, 1
insertion, no deletions. The modified object is the `alc269_fixup_tbl`
quirk table. Scope is a single-line, single-driver hardware quirk.

Record 2.2: Before the change, PCI SSID `0x1e50:0x7007` had no matching
quirk. After the change, `snd_hda_pick_fixup()` can select
`ALC269_FIXUP_LIMIT_INT_MIC_BOOST` for Positivo DN50E.

Record 2.3: Bug category is hardware quirk/workaround. The existing
fixup runs at `HDA_FIXUP_ACT_PROBE`, finds internal mic pins, and calls
`snd_hda_override_amp_caps()` to limit mic boost steps.

Record 2.4: Fix quality is high: one table entry, no new logic, no API
change. Regression risk is very low and limited to machines with that
exact PCI SSID.

### Phase 3: Git History Investigation
Record 3.1: There is no buggy code line to blame; the bug is a missing
quirk entry. I verified the existing `ALC269_FIXUP_LIMIT_INT_MIC_BOOST`
machinery is present in checked stable tags including `v4.19`, `v5.4`,
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`.

Record 3.2: No `Fixes:` tag is present, so there was no introducing
commit to follow.

Record 3.3: Recent history of this file shows frequent Realtek HDA quirk
additions and fixes. No prerequisite commit was identified for this
patch beyond the already-existing fixup.

Record 3.4: The author has multiple prior accepted Realtek HDA quirks
for Positivo and VAIO systems, including Positivo ARN50, P15X, K116J,
C6400, and SU C1400.

Record 3.5: The patch is functionally standalone. Older stable trees
before the 2025 file move use `sound/pci/hda/patch_realtek.c`, so those
need a path/context backport. A direct `git apply --check` against the
current checked-out 7.0 stable tree failed due context drift, not
missing functionality.

### Phase 4: Mailing List And External Research
Record 4.1: The exact standalone commit hash was not present in local
history, so `b4 dig -c <commit>` could not be used as specified. `b4 am`
by message-id found one patch and a two-message thread. The maintainer
reply from Takashi Iwai says “Applied now. Thanks.” No NAKs or concerns
were present.

Record 4.2: The original recipients included Takashi Iwai, Jaroslav
Kysela, Zhang Heng, Stefan Binding, Kailang Yang, `linux-
sound@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.

Record 4.3: No separate bug report was found. Web search confirmed
public hardware data for Positivo DN50E and related Positivo mic-boost
patches.

Record 4.4: Related patches exist for the same fixup pattern, including
Positivo ARN50 and N14AP7 in git history, plus a public Positivo DN50F
patch using the same fixup.

Record 4.5: I found no stable-specific discussion or explicit stable
nomination.

### Phase 5: Code Semantic Analysis
Record 5.1: No function body is modified. Affected code paths are
`alc269_fixup_tbl`, `snd_hda_pick_fixup()`, `snd_hda_apply_fixup()`, and
`alc269_fixup_limit_int_mic_boost()`.

Record 5.2: `alc269_probe()` calls `snd_hda_pick_fixup()` with
`alc269_fixup_tbl`, then later calls `snd_hda_apply_fixup(codec,
HDA_FIXUP_ACT_PROBE)`.

Record 5.3: Key callees are `snd_hda_codec_get_pincfg()`,
`snd_hda_get_input_pin_attr()`, and `snd_hda_override_amp_caps()`.

Record 5.4: The path is reached automatically during HDA codec probe on
matching hardware. The bad behavior affects internal mic capture; it is
not a syscall-triggered crash/security issue.

Record 5.5: Similar uses of `ALC269_FIXUP_LIMIT_INT_MIC_BOOST` are
already present for many laptops, including other Positivo systems.

### Phase 6: Stable Tree Analysis
Record 6.1: The reusable fixup exists in all checked stable tags from
`v4.19` through `v7.0`; the DN50E entry itself was absent in checked
tags.

Record 6.2: Backport difficulty is low but not always clean apply:
`v6.19+` uses `sound/hda/codecs/realtek/alc269.c`, while older trees use
`sound/pci/hda/patch_realtek.c`.

Record 6.3: I found no existing DN50E fix in checked stable tags or
current local history.

### Phase 7: Subsystem Context
Record 7.1: Subsystem is ALSA HDA Realtek codec support. Criticality is
driver-specific, but important for affected laptop audio users.

Record 7.2: The subsystem is active, with many recent quirk additions in
the same file. The pattern is mature and widely used.

### Phase 8: Impact And Risk
Record 8.1: Affected population is users of Positivo DN50E systems with
Realtek HDA audio.

Record 8.2: Trigger is normal codec probe plus internal microphone use.
It is not an unprivileged security trigger.

Record 8.3: Failure mode is user-visible broken audio quality from
excessive internal mic gain/noise. Severity is medium for affected
hardware, not crash-level.

Record 8.4: Benefit is high for affected hardware users. Risk is very
low because this adds one exact-match PCI SSID quirk using existing
code.

### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: hardware quirk exception, one-line
targeted change, existing tested fixup machinery, maintainer applied it,
related Positivo fixes use the same pattern. Evidence against: no
separate bug report/test tag and direct apply may need context/path
adjustment. Unresolved: exact upstream commit hash was not available
locally, and no independent DN50E test report beyond the submitter’s
patch text was found.

Record 9.2: Stable rules: obviously correct: yes; fixes a real user-
visible hardware bug: yes; important enough under hardware-quirk
exception: yes; small and contained: yes; no new APIs/features: yes;
stable apply: yes with likely minor path/context adjustment on older
trees.

Record 9.3: Exception category applies: hardware-specific
quirk/workaround in an existing driver.

Record 9.4: This should be backported. The patch is exactly the type of
low-risk Realtek HDA laptop quirk that stable trees routinely carry.

## Verification
- Phase 1: Parsed the supplied commit message and b4 mbox; confirmed
  tags and absence of `Fixes:` / stable / reporter tags.
- Phase 2: Read the patch mbox; confirmed 1 insertion in
  `alc269_fixup_tbl`.
- Phase 3: Used `git grep` across stable tags to confirm
  `ALC269_FIXUP_LIMIT_INT_MIC_BOOST` exists and DN50E is absent.
- Phase 3: Checked author history; found multiple accepted Positivo/VAIO
  Realtek HDA quirk commits.
- Phase 4: `b4 am` found the patch and thread; full mbox showed Takashi
  Iwai replied “Applied now.”
- Phase 4: Web searches found related Positivo DN50F/ARN50 mic-boost
  patches and a DN50E hardware listing.
- Phase 5: Read `snd_hda_pick_fixup()`, `snd_hda_apply_fixup()`,
  `alc269_probe()`, and `alc269_fixup_limit_int_mic_boost()` to verify
  call flow and behavior.
- Phase 6: Checked `v4.19`, `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`,
  `v6.12`, `v6.19`, and `v7.0` for fixup availability and file paths.
- Unverified: exact final upstream commit hash was not available in
  local history, and no separate user bug report was found.

**YES**

 sound/hda/codecs/realtek/alc269.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 4e0885c1fc496..b1fb5e1cf0078 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7799,6 +7799,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1d72, 0x1945, "Redmi G", ALC256_FIXUP_ASUS_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1d72, 0x1947, "RedmiBook Air", ALC255_FIXUP_XIAOMI_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1e39, 0xca14, "MEDION NM14LNL", ALC233_FIXUP_MEDION_MTL_SPK),
+	SND_PCI_QUIRK(0x1e50, 0x7007, "Positivo DN50E", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
 	SND_PCI_QUIRK(0x1ee7, 0x2078, "HONOR BRB-X M1010", ALC2XX_FIXUP_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1f4c, 0xe001, "Minisforum V3 (SE)", ALC245_FIXUP_BASS_HP_DAC),
 	SND_PCI_QUIRK(0x1f66, 0x0105, "Ayaneo Portable Game Player", ALC287_FIXUP_CS35L41_I2C_2),
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] Documentation: kvm: update links in the references section of AMD Memory Encryption

[Sasha Levin]

From: Ninad Naik <ninadnaik07@gmail.com>

[ Upstream commit 80f4a7b8ce7513c203562191426e4d4cc635b095 ]

Replace non-working links in the reference section with the working ones.

Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
Link: https://patch.msgid.link/20260511174302.811918-1-ninadnaik07@gmail.com/
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

Step 1.1 Record: Subsystem `Documentation: kvm`; action verb `update` /
body verb `Replace`; intent is to replace non-working AMD Memory
Encryption reference links with working links.

Step 1.2 Record: Tags found: `Signed-off-by: Ninad Naik
<ninadnaik07@gmail.com>`, `Link: https://patch.msgid.link/20260511174302
.811918-1-ninadnaik07@gmail.com/`, `Reviewed-by: Liam Merwick
<liam.merwick@oracle.com>`, `Signed-off-by: Paolo Bonzini
<pbonzini@redhat.com>`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Acked-by:`, or `Cc: stable@vger.kernel.org`.

Step 1.3 Record: The commit body describes a documentation issue only:
reference links in `Documentation/virt/kvm/x86/amd-memory-
encryption.rst` no longer work as intended. The user-visible symptom is
stale/broken documentation references for AMD SEV/SEV-SNP material. No
runtime failure, crash, data corruption, or kernel version note is
described.

Step 1.4 Record: This is not a hidden runtime bug fix. It is a direct
documentation fix, which is an allowed stable exception category due to
zero runtime risk.

## Phase 2: Diff Analysis

Step 2.1 Record: One file changed: `Documentation/virt/kvm/x86/amd-
memory-encryption.rst`, 4 insertions and 4 deletions. No functions are
modified. Scope classification: single-file surgical documentation
update.

Step 2.2 Record: Before, four reference labels pointed to older AMD
URLs. After, those labels point to current AMD Technical Information
Portal URLs, and the SNP firmware ABI reference points to a current AMD
PDF path. Only the `References` section is affected.

Step 2.3 Record: Bug category is documentation correctness, specifically
stale external references. No synchronization, memory safety, reference
counting, initialization, type, logic, or hardware workaround code is
involved.

Step 2.4 Record: Fix quality is high: the diff only swaps URL strings,
preserves labels, and does not touch kernel code or public APIs.
Regression risk is effectively limited to the possibility of choosing a
less useful URL, not runtime behavior.

## Phase 3: Git History Investigation

Step 3.1 Record: `git blame` on the reference section showed the white-
paper line came from `fbabc2eaef9fd7` in v6.3-rc1, the SNP firmware ABI
line came from `136d8bc931c84f` in v6.11-rc1, and older reference lines
are present in stable branches back to at least `v5.15` by direct branch
grep. Some blame output for pre-rename lines hit a boundary attribution,
so I did not rely on that boundary commit as the true source.

Step 3.2 Record: No `Fixes:` tag is present, so there is no specific
introducing commit to follow.

Step 3.3 Record: Recent file history on `origin/master` includes KVM
SEV/SNP documentation and API additions, including `20c3c4108d58f`,
`dcbcc2323c806`, `ad27ce155566f`, `dee5a47cc7a45`, and `136d8bc931c84f`.
The candidate is standalone because it only changes URL strings and does
not depend on those code/API changes to be meaningful where the same
reference lines exist.

Step 3.4 Record: `git log --author='Ninad Naik'` showed this author has
other documentation link/spelling style commits, including
`a362ae6e7e85b` for `amd-pstate` dead links and `5ed26ffe57ffc` for a
`hwmon` link. I did not verify the author as a KVM maintainer; Paolo
Bonzini committed/applied it and Liam Merwick reviewed it.

Step 3.5 Record: No code symbols or function dependencies exist. The
patch can apply standalone where the same documentation reference block
exists; older stable branches may need context/path adjustments.

## Phase 4: Mailing List And External Research

Step 4.1 Record: `b4 dig -c 80f4a7b8ce751` found the original patch
thread at `https://patch.msgid.link/20260511174302.811918-1-
ninadnaik07@gmail.com`. `b4 dig -a` found only v1; `b4 am -c` found no
newer revision.

Step 4.2 Record: `b4 dig -w` showed the patch was sent to KVM and docs
maintainers/lists, including Paolo Bonzini, Jonathan Corbet, Sean
Christopherson, Michael Roth, Liam Merwick, `kvm@vger.kernel.org`, and
`linux-doc@vger.kernel.org`.

Step 4.3 Record: There is no separate bug report or reporter tag. The
thread contains Liam Merwick’s `Reviewed-by` and Paolo Bonzini’s
“Applied, thanks.” I found no NAKs or concerns in the fetched thread.

Step 4.4 Record: The patch is a one-patch series. No related required
patches were identified.

Step 4.5 Record: Web search did not find stable-specific discussion for
this exact subject/hash. Direct WebFetch of lore stable search was
blocked by Anubis, so stable-list search is partially unverified.

## Phase 5: Code Semantic Analysis

Step 5.1 Record: No functions are modified.

Step 5.2 Record: No callers exist because this is documentation.
Documentation references to this file exist from
`Documentation/virt/kvm/api.rst`, `Documentation/admin-guide/kernel-
parameters.txt`, `Documentation/virt/kvm/x86/index.rst`, and related
documentation pages.

Step 5.3 Record: No callees exist. The changed labels are consumed by
Sphinx/ReST documentation rendering.

Step 5.4 Record: No runtime call chain exists. User impact is
documentation usability for KVM SEV/SEV-SNP developers/users.

Step 5.5 Record: Similar pattern exists in prior documentation link
fixes, including `fbabc2eaef9fd7` for an AMD memory encryption white-
paper URL and `bad0524e24201` for an x86 SEV documentation URL.

## Phase 6: Cross-Referencing And Stable Tree Analysis

Step 6.1 Record: Stable branches contain affected references.
`stable/linux-5.15.y` and `stable/linux-6.1.y` contain the old KVM AMD
memory encryption doc with three AMD references. `stable/linux-6.6.y`
contains the three current old references. `stable/linux-6.12.y` through
`stable/linux-7.0.y` contain all four references, including the SNP
firmware ABI link.

Step 6.2 Record: Backport difficulty is clean for the current
`linux-7.0.y`-based tree: `git apply --check` succeeded. Older trees
likely need small manual adjustment: `5.15.y` uses the pre-`x86/` path,
`5.15.y`/`6.1.y` have an older white-paper URL, and `6.6.y` lacks the
SNP firmware ABI line.

Step 6.3 Record: `stable/linux-7.0.y` does not contain this candidate
commit by subject. I found prior related doc-link fixes, but not this
exact KVM reference update in stable branches checked.

## Phase 7: Subsystem And Maintainer Context

Step 7.1 Record: Subsystem is KVM x86 documentation for AMD SEV/SEV-SNP.
Criticality is peripheral for runtime kernel stability, but relevant to
KVM confidential-computing documentation users.

Step 7.2 Record: File history shows active KVM SEV/SNP documentation
churn due to recent SEV-SNP commands and API documentation. The touched
change itself is isolated documentation.

## Phase 8: Impact And Risk Assessment

Step 8.1 Record: Affected population is documentation users, especially
KVM/SEV/SEV-SNP developers and operators consulting AMD specs from
stable kernel docs.

Step 8.2 Record: Trigger condition is reading the documentation
references. It is not syscall- or runtime-triggered, and unprivileged
runtime triggering is not applicable.

Step 8.3 Record: Failure mode is stale/non-direct documentation links.
Severity is LOW for runtime stability, but valid under the
documentation-fix exception.

Step 8.4 Record: Benefit is modest but real: stable documentation points
users at current AMD references. Risk is very low: 4 URL replacements in
one `.rst` file, no code, no ABI, no behavior change. Risk-benefit ratio
is favorable because runtime regression risk is effectively zero.

## Phase 9: Final Synthesis

Step 9.1 Record: Evidence for backporting: documentation fix exception
applies; patch is tiny; reviewed; applied by KVM maintainer Paolo
Bonzini; no NAKs found; affected references exist in stable trees;
current `7.0.y` patch application check succeeds. Evidence against: no
runtime bug, no crash/security/data-loss impact, and older stable
branches need minor backport adjustment. Unresolved: lore stable search
was blocked by Anubis, so I could not fully verify stable-list
discussion.

Step 9.2 Record: Stable rules checklist: obviously correct and reviewed:
yes; fixes a real issue: yes, stale documentation references; important
runtime issue: no, but documentation fixes are an allowed exception;
small and contained: yes, 4 lines changed in one file; no new
features/APIs: yes; can apply to stable: yes for current `7.0.y`, likely
clean for `6.12.y+`, minor adjustment for older branches.

Step 9.3 Record: Exception category: documentation fix. This is
explicitly the kind of zero-runtime-risk update that can be accepted
even though it is not a runtime correctness fix.

Step 9.4 Record: Decision is YES. Backporting is appropriate for stable
trees that carry the affected documentation, with minor manual
adjustment where older branch context differs.

## Verification

- [Phase 1] `git show --format=fuller --stat --patch 80f4a7b8ce751`:
  confirmed subject, tags, one-file documentation diff, and no runtime-
  code changes.
- [Phase 2] Diff inspection: confirmed 4 URL replacements only in
  `Documentation/virt/kvm/x86/amd-memory-encryption.rst`.
- [Phase 3] `git blame -L 652,664`: confirmed local history for the
  reference block, including `fbabc2eaef9fd7` and `136d8bc931c84f`.
- [Phase 3] `git describe --contains`: confirmed `fbabc2eaef9fd7` first
  appears by v6.3-rc1 and `136d8bc931c84f` by v6.11-rc1.
- [Phase 3] `git log origin/master --oneline -20 --
  Documentation/virt/kvm/x86/amd-memory-encryption.rst`: confirmed
  recent KVM SEV/SNP doc history and candidate placement.
- [Phase 4] `b4 dig -c 80f4a7b8ce751`: found original patch thread by
  patch-id.
- [Phase 4] `b4 dig -c 80f4a7b8ce751 -a`: confirmed only v1 series.
- [Phase 4] `b4 dig -c 80f4a7b8ce751 -w`: confirmed KVM/docs maintainers
  and lists were included.
- [Phase 4] `b4 mbox`/saved thread plus `rg`: confirmed `Reviewed-by:
  Liam Merwick` and Paolo’s “Applied, thanks”; found no NAK/stable
  request text.
- [Phase 4] WebFetch of lore/patch URLs was blocked by Anubis; b4
  successfully fetched the thread.
- [Phase 5] `rg` in the doc file: confirmed changed labels are
  referenced by SEV/SNP documentation text.
- [Phase 5] `rg` under `Documentation`: confirmed documentation pages
  link to `amd-memory-encryption.rst`.
- [Phase 6] `git grep` across `stable/linux-5.15.y`, `6.1.y`, `6.6.y`,
  `6.12.y`, `6.15.y`, `6.16.y`, `6.17.y`, `6.18.y`, `6.19.y`, and
  `7.0.y`: confirmed affected old references exist and identified branch
  differences.
- [Phase 6] `git diff 80f4a7b8ce751^ 80f4a7b8ce751 | git apply --check`:
  confirmed clean application to the current `7.0.y`-based working tree.
- [Phase 8] URL checks with Python HEAD/WebFetch: confirmed old direct
  AMD URLs no longer behave as direct PDF references in several cases,
  while the new SNP ABI URL returns an AMD PDF; other new AMD TIP URLs
  resolve to AMD documentation portal pages.
- UNVERIFIED: full stable mailing-list history, because direct lore
  stable WebFetch was blocked by Anubis and web search found no exact
  stable discussion.

**YES**

 Documentation/virt/kvm/x86/amd-memory-encryption.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
index b2395dd4769de..bd04a908a8dbd 100644
--- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
+++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
@@ -656,8 +656,8 @@ References
 See [white-paper]_, [api-spec]_, [amd-apm]_, [kvm-forum]_, and [snp-fw-abi]_
 for more info.
 
-.. [white-paper] https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
-.. [api-spec] https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
-.. [amd-apm] https://support.amd.com/TechDocs/24593.pdf (section 15.34)
+.. [white-paper] https://docs.amd.com/v/u/en-US/memory-encryption-white-paper
+.. [api-spec] https://docs.amd.com/v/u/en-US/55766_PUB_3.24_SEV_API
+.. [amd-apm] https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2 (section 15.34)
 .. [kvm-forum]  https://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
-.. [snp-fw-abi] https://www.amd.com/system/files/TechDocs/56860.pdf
+.. [snp-fw-abi] https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] scsi: scsi_dh_alua: Increase default ALUA timeout to maximum spec value

[Sasha Levin]

From: Brian Bunker <brian@purestorage.com>

[ Upstream commit 68c3a65a5a8e85643745fdde02cb63904e165620 ]

The ALUA handler maps a 0 value (no implicit transition timeout provided
by the target) to the ALUA_FAILOVER_TIMEOUT constant, currently 60
seconds. This means the kernel already does not accept an infinite
transition time.

However, 60 seconds is insufficient for some arrays that may take longer
to complete ALUA transitions. Since the highest value allowed by the
SCSI specification for the implicit transition timeout is a single byte
(255 seconds), change the default to 255. This way, when a target does
not provide an explicit transition timeout, we default to the maximum
value the spec allows rather than an arbitrary 60 second limit.

Co-developed-by: Krishna Kant <krishna.kant@purestorage.com>
Signed-off-by: Krishna Kant <krishna.kant@purestorage.com>
Co-developed-by: Riya Savla <rsavla@purestorage.com>
Signed-off-by: Riya Savla <rsavla@purestorage.com>
Signed-off-by: Brian Bunker <brian@purestorage.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://patch.msgid.link/20260416165512.26497-2-brian@purestorage.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis Walkthrough

Phase 1 Record: Subsystem is `scsi: scsi_dh_alua`; action is “increase”;
intent is to raise the default ALUA implicit transition timeout from 60s
to 255s. Tags verified from commit
`68c3a65a5a8e85643745fdde02cb63904e165620`: co-developed/SOB by Krishna
Kant and Riya Savla, SOB by Brian Bunker, `Reviewed-by: Hannes
Reinecke`, `Link:` to the v4 posting, SOB by Martin K. Petersen. No
`Fixes:`, `Reported-by:`, `Tested-by:`, or `Cc: stable`. Body describes
a real behavior problem: targets that omit an explicit ALUA transition
timeout get capped at 60s, which is too short for some arrays.

Phase 2 Record: One file changed,
`drivers/scsi/device_handler/scsi_dh_alua.c`, 1 insertion/1 deletion. No
function body is modified; only `ALUA_FAILOVER_TIMEOUT` changes. The
macro is used by `submit_rtpg()`, `submit_stpg()`, `alua_tur()`, and
`alua_rtpg()` for command and transition expiry timing. Before: missing
target timeout defaults to 60s. After: defaults to 255s. Bug category is
logic/correctness for storage failover timing. Fix quality is very small
and obvious; main regression risk is slower failure detection for arrays
that omit timeout and remain stuck.

Phase 3 Record: `git blame` shows the 60s default came from
`3588c5a21aef8c` (`[SCSI] scsi_dh_alua: implement 'implied transition
timeout'`), first contained in `v3.6`. That original commit added the
implicit transition timeout machinery and made 60s the finite fallback.
Recent local history shows ALUA-related fixes but no prerequisite for
this one. Author Brian Bunker previously authored ALUA transition-state
fix `6056a92ceb2a7`, so this is from a contributor with direct ALUA
history. No standalone dependency was found.

Phase 4 Record: `b4 dig -c 68c3a65a5a8e8` found the v4 lore submission
at
`https://patch.msgid.link/20260416165512.26497-2-brian@purestorage.com`.
`b4 dig -a` found v3 and v4; v4 is the applied revision. `b4 dig -w`
shows Brian Bunker, `linux-scsi`, Hannes Reinecke, Krishna Kant, and
Riya Savla were included. The v4 thread has Hannes’s `Reviewed-by` and
Martin Petersen’s “Applied to 7.1/scsi-staging”. Earlier v2 discussion
verified Hannes objected to tying ALUA transition timeout to device
command timeout, and the patch evolved into the simpler 255s default. I
found no stable-list discussion.

Phase 5 Record: Modified function list is empty, but impacted code paths
are the ALUA RTPG/STPG/TUR and transition expiry paths. Call tracing
verified `alua_rtpg_work()` calls `alua_tur()` and `alua_rtpg()`,
`alua_activate()` queues RTPG from dm-multipath activation,
`alua_check_sense()` is invoked from SCSI error handling, and
`alua_prep_fn()` is called from SCSI request setup. This is reachable
from SCSI disk/device-handler attach, error handling, and dm-multipath
path activation. Similar pattern search found the same 60s fallback in
active stable tags.

Phase 6 Record: The buggy 60s default exists in `v4.14`, `v4.19`,
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.16`, `v6.17`, and `v7.0`
tags in this repo. The exact macro line is present, so backport
difficulty should be clean or trivial for those trees. `b4 am` also
reported the v4 patch “applies clean to current tree.” No alternate
stable fix was found.

Phase 7 Record: Subsystem is SCSI device handler / ALUA multipath
storage. Criticality is IMPORTANT: it affects systems using ALUA-capable
SCSI storage, especially enterprise multipath arrays. MAINTAINERS
verifies SCSI is maintained by James Bottomley and Martin Petersen, and
the patch was committed by Martin Petersen.

Phase 8 Record: Affected users are config/hardware-specific: ALUA SCSI
disk users, commonly multipath enterprise storage. Trigger is an ALUA
transition where the target omits an explicit transition timeout and
takes more than 60s. Failure mode is premature transition expiry,
leading `alua_rtpg()` to mark the port group standby and return I/O/path
failure. Severity is HIGH for affected systems because it can break
failover or storage availability. Benefit is high for affected storage
users; risk is low because this is a one-line bounded timeout increase
and 255s matches the implementation’s `unsigned char`/`buff[5]` timeout
representation.

Phase 9 Record: Evidence for backporting: real storage failover
correctness issue, long-lived bug since v3.6, affects many stable trees,
one-line bounded fix, reviewed by Hannes Reinecke, committed by SCSI
maintainer Martin Petersen, no new API or feature. Evidence against: no
formal `Reported-by` or `Tested-by`; behavior may wait longer before
declaring a nonresponsive target failed. Stable checklist: obviously
correct yes; real bug yes; important issue yes for storage
availability/path failure; small and contained yes; no new APIs yes;
applies to stable trees yes/trivial. Exception category: none, this is
not a device ID/quirk/build/doc fix.

## Verification

- Phase 1: `git show 68c3a65a5a8e8` verified commit message, tags,
  author, committer, and one-line diff.
- Phase 2: `git show` and source read verified only
  `ALUA_FAILOVER_TIMEOUT` changes from `60` to `255`.
- Phase 3: `git blame` verified the 60s default came from
  `3588c5a21aef8c`; `git describe --contains` verified `v3.6` ancestry.
- Phase 4: `b4 dig`, `b4 dig -a`, `b4 dig -w`, and saved mboxes verified
  v3/v4 review history, Hannes review, and Martin’s apply note. Direct
  WebFetch of lore was blocked/timed out; b4 succeeded.
- Phase 5: `git grep` and file reads verified ALUA call paths through
  SCSI request setup, SCSI error handling, and dm-multipath activation.
- Phase 6: `git grep` against stable tags verified the 60s default
  exists across listed stable releases.
- Phase 7: `MAINTAINERS` search verified SCSI maintainer/list context.
- Phase 8: Source inspection verified the failure path: timeout expiry
  in `alua_rtpg()` changes transitioning state handling to standby/I/O
  error.
- Unverified: I did not independently fetch the SCSI SPC text; the “255
  maximum spec value” claim is supported by the reviewed commit text and
  by the kernel implementation storing the timeout as a single byte.

This should be backported: it fixes a real ALUA multipath storage
availability problem with a tiny, bounded, maintainer-reviewed change
and minimal regression risk.

**YES**

 drivers/scsi/device_handler/scsi_dh_alua.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c b/drivers/scsi/device_handler/scsi_dh_alua.c
index efb08b9b145a1..80ab0ff921d43 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -37,7 +37,7 @@
 #define TPGS_MODE_EXPLICIT		0x2
 
 #define ALUA_RTPG_SIZE			128
-#define ALUA_FAILOVER_TIMEOUT		60
+#define ALUA_FAILOVER_TIMEOUT		255	/* max 255 (8-bit value) */
 #define ALUA_FAILOVER_RETRIES		5
 #define ALUA_RTPG_DELAY_MSECS		5
 #define ALUA_RTPG_RETRY_DELAY		2
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] HID: google: hammer: stop hardware on devres action failure

[Sasha Levin]

From: Myeonghun Pak <mhun512@gmail.com>

[ Upstream commit b08665fe80fab0956e64741c07d9bbcec635c34d ]

hammer_probe() starts the HID hardware before registering the devres
action that stops it. If devm_add_action() fails, probe returns an
error with the hardware still started because the cleanup action was
never registered and the driver's remove callback is not called after a
failed probe.

Use devm_add_action_or_reset() so the stop action runs immediately on
registration failure while preserving the existing devres-managed cleanup
path for later probe failures and remove.

Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
- Step 1.1 Record: subsystem `HID: google: hammer`; action verb `stop`;
  intent is to stop HID hardware if devres action registration fails.
- Step 1.2 Record: tags in committed
  `b08665fe80fab0956e64741c07d9bbcec635c34d`: `Signed-off-by: Myeonghun
  Pak <mhun512@gmail.com>` and `Signed-off-by: Jiri Kosina
  <jkosina@suse.com>`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
  `Reviewed-by:`, `Acked-by:`, `Link:`, or `Cc: stable`.
- Step 1.3 Record: bug is an error-path cleanup failure.
  `hammer_probe()` calls `hid_hw_start()` before registering
  `hammer_stop` with devres; if `devm_add_action()` returns `-ENOMEM`,
  probe fails and no registered cleanup action calls `hid_hw_stop()`.
- Step 1.4 Record: yes, this is a hidden bug fix: a one-line
  devres/error-path cleanup fix preventing started HID hardware from
  being left active after failed probe.

### Phase 2: Diff Analysis
- Step 2.1 Record: one file, `drivers/hid/hid-google-hammer.c`; 1
  insertion, 1 deletion; modified function `hammer_probe()`; single-file
  surgical fix.
- Step 2.2 Record: before, failure of `devm_add_action()` returned
  directly after `hid_hw_start()` succeeded. After,
  `devm_add_action_or_reset()` runs `hammer_stop(hdev)` immediately if
  action registration fails.
- Step 2.3 Record: bug category is error-path resource cleanup. The
  broken state is missing `hid_hw_stop()` after successful
  `hid_hw_start()` when devres action allocation fails.
- Step 2.4 Record: fix quality is high: it uses the kernel helper whose
  inline definition calls the action on registration failure. No
  unrelated changes, no public API change, and no normal-path behavior
  change when registration succeeds.

### Phase 3: Git History Investigation
- Step 3.1 Record: blame shows `devm_add_action(&hdev->dev, hammer_stop,
  hdev)` came from `d950db3f80a801` (`HID: google: switch to devm when
  registering keyboard backlight LED`), first contained by `v5.18-rc1`.
- Step 3.2 Record: no `Fixes:` tag. I followed the blamed introducing
  commit instead; `d950db3f80a801` added `hammer_stop()` and moved stop
  cleanup into devres.
- Step 3.3 Record: recent file history shows related Google HID
  cleanup/device-ID/vivaldi work, but no intermediate fix for this exact
  missed cleanup.
- Step 3.4 Record: candidate author has only this HID commit in
  `origin/master` in the checked history. Jiri Kosina is listed in
  `MAINTAINERS` for HID core and applied/signed the commit.
- Step 3.5 Record: no dependency found. The replacement helper exists in
  affected stable branches checked.

### Phase 4: Mailing List And External Research
- Step 4.1 Record: `b4 dig -c b08665fe80fab` found the original patch at
  `https://patch.msgid.link/20260424125043.52639-1-
  pakmyeonghun@bagmyeonghun-ui-MacBookPro.local`. `b4 dig -a` found only
  v1.
- Step 4.2 Record: `b4 dig -w` showed the original recipients were
  Myeonghun Pak, Jiri Kosina, Benjamin Tissoires, `linux-
  input@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.
- Step 4.3 Record: no separate bug report or `Reported-by` tag was
  present.
- Step 4.4 Record: thread had 3 messages; Jiri replied, “Makes sense,
  thanks for catching it. Applied.” No NAKs or objections found in the
  fetched mbox.
- Step 4.5 Record: direct lore stable web search was blocked by Anubis;
  local stable branch log search did not find this commit already
  present.

### Phase 5: Code Semantic Analysis
- Step 5.1 Record: modified function is `hammer_probe()`.
- Step 5.2 Record: `hammer_probe()` is registered as `.probe` in
  `hammer_driver`; HID core reaches it via `hid_device_probe()` ->
  `__hid_device_probe()` -> `hdrv->probe(hdev, id)`.
- Step 5.3 Record: key callees are `hid_parse()`, `hid_hw_start()`,
  `devm_add_action_or_reset()`, `hid_hw_open()`, and
  `hammer_register_leds()`. `hid_hw_start()` documentation says
  `hid_hw_stop()` must be called after success.
- Step 5.4 Record: path is reachable during HID device probe for Google
  Hammer-family USB IDs in the driver table. Trigger for the bug is
  allocation failure inside `devm_add_action()` after hardware start.
- Step 5.5 Record: no other `hammer_stop` pattern found. Nearby HID
  drivers commonly call `hid_hw_stop()` on probe-error paths, supporting
  that this cleanup is expected.

### Phase 6: Stable Tree Analysis
- Step 6.1 Record: buggy code exists in `stable/linux-6.1.y`, `6.6.y`,
  `6.12.y`, `6.15.y`, `6.16.y`, `6.17.y`, `6.18.y`, and `6.19.y`; not in
  `stable/linux-5.15.y`.
- Step 6.2 Record: patch applied cleanly with `git apply --check` on
  temporary worktrees for `6.1.y`, `6.6.y`, `6.12.y`, and `6.19.y`.
- Step 6.3 Record: no related stable fix with the same subject was found
  in checked stable branch logs.

### Phase 7: Subsystem Context
- Step 7.1 Record: subsystem is HID driver code, specifically Google
  Hammer HID devices; criticality is driver-specific/peripheral.
- Step 7.2 Record: HID is actively maintained; recent `drivers/hid`
  history includes multiple fixes and quirks, and the candidate was
  merged through the HID tree.

### Phase 8: Impact And Risk
- Step 8.1 Record: affected users are users of Google Hammer-family HID
  hardware on stable kernels containing `d950db3f80a801`.
- Step 8.2 Record: trigger is uncommon but real: memory/devres
  allocation failure during device probe after `hid_hw_start()`
  succeeds. I did not verify unprivileged syscall reachability.
- Step 8.3 Record: failure mode is leaked/active HID hardware state
  after failed probe, not a verified crash or data corruption. Severity
  is medium, with higher concern under memory pressure because cleanup
  is explicitly required by HID core semantics.
- Step 8.4 Record: benefit is moderate for affected hardware and error
  recovery correctness; risk is very low because the successful path is
  unchanged and the failure path calls the already intended cleanup
  function.

### Phase 9: Final Synthesis
- Step 9.1 Record: evidence for backporting: real cleanup bug, affected
  maintained stable trees, one-line obviously correct fix, uses existing
  helper, applies cleanly, maintainer accepted it. Evidence against: no
  reported user crash, rare trigger, driver-specific impact. Unresolved:
  no runtime test report or concrete field failure report found.
- Step 9.2 Record: stable rules: obviously correct yes; fixes real bug
  yes; important enough as resource/hardware-state leak on failed probe
  yes, though not crash-class; small and contained yes; no new
  feature/API yes; applies to stable yes for checked branches.
- Step 9.3 Record: no automatic exception category; this is not a device
  ID, quirk, DT, build, or documentation patch.
- Step 9.4 Record: risk-benefit favors backporting because the fix is a
  minimal correction to a verified cleanup bug in stable-present code.

## Verification
- Phase 1: inspected `git show --stat --no-ext-diff b08665fe80fab`;
  confirmed subject, body, tags, and 1-line diff.
- Phase 2: inspected full candidate diff; confirmed only
  `devm_add_action()` -> `devm_add_action_or_reset()` in
  `hammer_probe()`.
- Phase 3: ran blame on changed area; confirmed introducing commit
  `d950db3f80a801`, first contained by `v5.18-rc1`.
- Phase 3: inspected `d950db3f80a801`; confirmed it added devres-managed
  `hammer_stop()`.
- Phase 4: ran `b4 dig -c`, `-a`, and `-w`; confirmed original patch
  URL, v1 only, maintainers/lists included.
- Phase 4: fetched full thread with `b4 mbox`; confirmed Jiri Kosina
  replied that the patch made sense and was applied.
- Phase 5: read HID core and devres code; confirmed `hid_hw_start()`
  requires `hid_hw_stop()`, and `devm_add_action_or_reset()` invokes the
  action on failure.
- Phase 6: checked stable branches with `git grep`; confirmed buggy line
  in `6.1.y` through `6.19.y`, not `5.15.y`.
- Phase 6: ran `git apply --check` in temporary worktrees for `6.1.y`,
  `6.6.y`, `6.12.y`, and `6.19.y`; all passed.
- UNVERIFIED: no separate user bug report, crash report, or runtime test
  result was found.

**YES**

 drivers/hid/hid-google-hammer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 1af477e58480b..c99c3c0d442e1 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -496,7 +496,7 @@ static int hammer_probe(struct hid_device *hdev,
 	if (error)
 		return error;
 
-	error = devm_add_action(&hdev->dev, hammer_stop, hdev);
+	error = devm_add_action_or_reset(&hdev->dev, hammer_stop, hdev);
 	if (error)
 		return error;
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] ALSA: doc: cs35l56: Update path to HDA driver source

[Sasha Levin]

From: Richard Fitzgerald <rf@opensource.cirrus.com>

[ Upstream commit 74e8409821ac8cda70bf23eb593f2c7f6e3b5a2f ]

The HDA drivers were moved to sound/hda/... so update a Documentation
reference that still pointed to the old location.

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260511104148.36382-1-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `ALSA: doc: cs35l56`; action verb `Update`;
intent: correct a stale documentation path to the HDA driver source.

Record 1.2: Tags present in supplied message: `Signed-off-by: Richard
Fitzgerald <rf@opensource.cirrus.com>`, `Link: https://patch.msgid.link/
20260511104148.36382-1-rf@opensource.cirrus.com`, `Signed-off-by:
Takashi Iwai <tiwai@suse.de>`. No `Fixes:`, `Reported-by:`, `Tested-
by:`, `Reviewed-by:`, `Acked-by:`, or `Cc: stable`.

Record 1.3: The body says the HDA drivers moved to `sound/hda/...`,
leaving this documentation reference pointing at the old
`sound/pci/hda/...` location. Symptom is incorrect documentation only;
no runtime failure, crash, data corruption, or security impact is
described.

Record 1.4: This is not a hidden runtime bug fix. It is a direct
documentation correction.

## Phase 2: Diff Analysis
Record 2.1: One file changed: `Documentation/sound/codecs/cs35l56.rst`,
1 insertion and 1 deletion. No functions modified. Scope: single-file
documentation-only surgical change.

Record 2.2: Before: HDA users were pointed to
`sound/pci/hda/cs35l56_hda.c`. After: they are pointed to
`sound/hda/codecs/side-codecs/cs35l56_hda.c`.

Record 2.3: Bug category: documentation correctness fix. Verified
current tree has `sound/hda/codecs/side-codecs/cs35l56_hda.c`;
`sound/pci/hda` does not exist in this checkout.

Record 2.4: Fix quality is obvious and minimal. Regression risk is
runtime zero, but backport targeting matters: applying it to older trees
where the driver is still under `sound/pci/hda` would make the
documentation wrong.

## Phase 3: Git History Investigation
Record 3.1: `git blame` shows the stale documentation line was
introduced by `088fb4ee17fc4` (`ALSA: doc: cs35l56: Add information
about Cirrus Logic CS35L54/56/57`). The line became stale when
`6014e9021b28e` moved HDA codec drivers into `sound/hda/codecs`.

Record 3.2: No `Fixes:` tag is present, so there was no Fixes target to
follow.

Record 3.3: Recent file history shows only CS35L56 documentation
updates. Related source movement is `6014e9021b28e`, which renamed
`sound/pci/hda/cs35l56_hda.c` to `sound/hda/codecs/side-
codecs/cs35l56_hda.c`.

Record 3.4: Author Richard Fitzgerald has multiple recent CS35L56/HDA-
related commits in this subsystem, including documentation and HDA
driver fixes.

Record 3.5: Dependency identified: this patch is correct only in trees
that already contain the HDA move commit `6014e9021b28e`.

## Phase 4: Mailing List And External Research
Record 4.1: `b4 am` using message ID
`20260511104148.36382-1-rf@opensource.cirrus.com` found a single patch
submission and reported no newer revision. Direct `WebFetch` to
lore/patch.msgid.link was blocked by Anubis, but `b4` retrieved the
mbox.

Record 4.2: `b4 dig -c` could not be run for the candidate commit
because no candidate commit hash was supplied and the commit was not
found on checked named branches searched. `b4 am` verified author DKIM
signatures and the patch metadata. `b4 dig -c 6014e9021b28e -w` verified
the prerequisite move patch was an ALSA HDA series sent to `linux-sound`
and relevant HDA/Cirrus recipients.

Record 4.3: No bug report, syzbot report, crash report, or user report
is linked.

Record 4.4: Candidate is standalone as a documentation update, but
semantically depends on the prior source-tree move.

Record 4.5: Web searches and local pending branch searches found no
stable-specific discussion for this exact documentation patch.

## Phase 5: Code Semantic Analysis
Record 5.1: No functions modified; documentation text only.

Record 5.2: No callers; this is not runtime code.

Record 5.3: No callees; no allocations, locks, I/O, or side effects.

Record 5.4: No userspace-triggerable kernel execution path. Impact is
limited to readers of the documentation.

Record 5.5: Search found the old path only in
`Documentation/sound/codecs/cs35l56.rst` among `.rst` files checked.

## Phase 6: Stable Tree Analysis
Record 6.1: Tag containment shows the documentation exists from
`v6.13+`; the HDA move exists from `v6.17+`. Therefore the stale-path
documentation issue exists only in trees containing both, i.e.
approximately `v6.17+` and later.

Record 6.2: `git apply --check` confirms the patch applies cleanly to
the current `7.0.y` tree. Backport difficulty is trivial for affected
trees, but it must not be applied to trees where the HDA driver still
lives under `sound/pci/hda`.

Record 6.3: No related stable fix for this exact path correction was
found in local pending branches.

## Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is ALSA sound documentation for Cirrus CS35L56
HDA/SoundWire amplifiers. Criticality: peripheral/documentation, not
runtime core.

Record 7.2: Sound documentation and HDA side-codec areas are actively
maintained; recent logs show multiple CS35L56/HDA commits.

## Phase 8: Impact And Risk Assessment
Record 8.1: Affected population: developers, maintainers, integrators,
and users consulting this CS35L56 documentation in kernels where the HDA
source has moved.

Record 8.2: Trigger condition: reading the documentation. Not
triggerable as a kernel runtime fault.

Record 8.3: Failure mode: stale documentation path. Severity LOW, but
documentation fixes are explicitly acceptable stable material due zero
runtime risk.

Record 8.4: Benefit is modest but real for affected trees; risk is very
low if limited to trees with `6014e9021b28e`, but negative for older
trees where the old path is still correct.

## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes an objectively wrong
documentation reference, one-line contained patch, no runtime regression
risk, applies cleanly to current `7.0.y`, documentation/comment fixes
are an accepted stable exception. Evidence against: no runtime bug, no
important crash/security/corruption impact, and it must be branch-
limited. Unresolved: exact upstream candidate commit hash was not
available locally.

Record 9.2: Stable rules: obviously correct: yes; tested: `b4` says
applies cleanly and local `git apply --check` passed; fixes a real bug:
yes, documentation bug; important runtime issue: no; small and
contained: yes, 1 line; no new feature/API: yes; applies to affected
stable trees: yes, for trees after the HDA move.

Record 9.3: Exception category: documentation fix.

Record 9.4: Decision: backport is appropriate, but only to stable trees
that already contain the HDA source move to `sound/hda/codecs/side-
codecs`. Do not apply to older stable trees where
`sound/pci/hda/cs35l56_hda.c` remains the correct path.

## Verification
- [Phase 1] Parsed supplied commit message and downloaded mbox:
  confirmed subject, author, message ID, and one-line documentation
  rationale.
- [Phase 2] Read `Documentation/sound/codecs/cs35l56.rst`: confirmed old
  path is present.
- [Phase 2] Checked filesystem: confirmed `sound/hda/codecs/side-
  codecs/cs35l56_hda.c` exists and `sound/pci/hda` does not in current
  tree.
- [Phase 3] `git blame -L 35,45`: confirmed stale line came from
  `088fb4ee17fc4`.
- [Phase 3] `git show 6014e9021b28e`: confirmed HDA codecs, including
  `cs35l56_hda.c`, were moved from `sound/pci/hda` to
  `sound/hda/codecs/side-codecs`.
- [Phase 4] `b4 am`: retrieved the patch, found one patch, no newer
  revision, DKIM signed.
- [Phase 4] `b4 dig -c <msgid>`: failed because `b4 dig` requires a
  commit-ish, not a message ID.
- [Phase 4] WebFetch to lore/patch.msgid.link: blocked by Anubis.
- [Phase 6] `git tag --contains`: documentation starts at `v6.13+`; HDA
  move starts at `v6.17+`.
- [Phase 6] `git apply --check`: candidate patch applies cleanly to
  current tree.
- [Phase 6] `git ls-tree`: `v6.6`/`v6.12` have old HDA source path and
  no affected doc; `v6.18` has both affected doc and new HDA source
  path.
- UNVERIFIED: Candidate final upstream commit hash, because it was not
  found on searched local named branches and was not provided.

**YES**

 Documentation/sound/codecs/cs35l56.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/sound/codecs/cs35l56.rst b/Documentation/sound/codecs/cs35l56.rst
index d5363b08f5152..b3f8c1c238518 100644
--- a/Documentation/sound/codecs/cs35l56.rst
+++ b/Documentation/sound/codecs/cs35l56.rst
@@ -40,7 +40,7 @@ There are two drivers in the kernel
 
 *For systems using SoundWire*: sound/soc/codecs/cs35l56.c and associated files
 
-*For systems using HDA*: sound/pci/hda/cs35l56_hda.c
+*For systems using HDA*: sound/hda/codecs/side-codecs/cs35l56_hda.c
 
 Firmware
 ========
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] Bluetooth: hci_uart: Fix NULL deref in recv callbacks when priv is uninitialized

[Sasha Levin]

From: Aurelien DESBRIERES <aurelien@hackers.camp>

[ Upstream commit 902fe40bce7059722f7ffa1c378e577675cf1918 ]

When a fault is injected during hci_uart line discipline setup, the
proto open() callback may fail leaving hu->priv as NULL. A subsequent
TIOCSTI ioctl can trigger the recv() callback before priv is
initialized, causing a NULL pointer dereference.

Fix all four affected HCI UART protocol drivers by adding a NULL check
on hu->priv at the start of their recv() callbacks: h4, h5, ath and
bcsp.

Reported-by: syzbot+ff30eeab8e07b37d524e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ff30eeab8e07b37d524e
Signed-off-by: Aurelien DESBRIERES <aurelien@hackers.camp>
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `Bluetooth: hci_uart`; action verb `Fix`;
intent is to prevent NULL dereference in HCI UART protocol `recv()`
callbacks when `hu->priv` is not initialized.

Step 1.2 Record: Tags found: `Reported-by:
syzbot+ff30eeab8e07b37d524e@syzkaller.appspotmail.com`; `Closes:
https://syzkaller.appspot.com/bug?extid=ff30eeab8e07b37d524e`; `Signed-
off-by: Aurelien DESBRIERES`; `Assisted-by: Claude:claude-sonnet-4-6`;
`Signed-off-by: Luiz Augusto von Dentz`. No `Fixes:` tag. Notable
pattern: syzbot report with reproducer and KASAN NULL-deref crash.

Step 1.3 Record: The commit describes a `hu->priv == NULL` path during
HCI UART setup followed by received data via `TIOCSTI`, causing a NULL
pointer dereference. The syzkaller report verifies a KASAN NULL-
deref/general protection fault in `h4_recv`, with call chain `tty_ioctl
-> tiocsti -> hci_uart_tty_receive -> h4_recv`.

Step 1.4 Record: This is not hidden cleanup; it is an explicit memory-
safety crash fix. The added checks prevent dereferencing protocol-
private state when setup/error handling leaves it absent.

## Phase 2: Diff Analysis
Step 2.1 Record: Four files changed, all in `drivers/bluetooth`:
`hci_ath.c` `+3/-0`, `hci_bcsp.c` `+3/-0`, `hci_h4.c` `+3/-0`,
`hci_h5.c` `+3/-0`; total `12` insertions. Modified functions:
`ath_recv`, `bcsp_recv`, `h4_recv`, `h5_recv`. Scope: small multi-file
surgical driver fix.

Step 2.2 Record: Each hunk previously assigned `hu->priv` to a protocol-
private pointer and then dereferenced it. After the patch, each callback
returns `-ENODEV` if that pointer is NULL. The affected path is receive
handling through the HCI UART line discipline, including data injected
by `TIOCSTI`.

Step 2.3 Record: Bug category is NULL pointer dereference / memory
safety. Specific mechanism: `hci_uart_tty_receive()` calls
`hu->proto->recv()`, and these callbacks dereference `hu->priv`; if
setup/error handling leaves `hu->priv` NULL, the callback crashes. The
fix adds direct NULL guards before first dereference.

Step 2.4 Record: Fix quality is high: simple, local, obviously correct,
no API/data structure changes. Regression risk is very low; it only
changes an invalid crash path to `-ENODEV`.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` on the vulnerable lines showed the current
callback bodies come from long-standing Bluetooth UART code, with recent
edits such as `b489556a856d` for `h4_recv_buf()` usage and
`ca94b2b036c2` adding the BCSP registered guard. The vulnerable pattern
exists in `v6.19.14` and `v7.0.5`.

Step 3.2 Record: No `Fixes:` tag, so no tagged introducing commit to
follow.

Step 3.3 Record: Related recent commits include `0ffac654e95c` / stable
backport `981b4fd2baf3` removing the `HCI_UART_REGISTERED` guard from
`h4_recv`, and `0c3cd7a0b862` fixing a related HCI UART NULL deref in
write work. Another related upstream commit, `68d39ea5e0ad`, clears
`HCI_UART_PROTO_INIT` on register error but is present in `v7.1-rc*`,
not in checked `v6.19.14`/`v7.0.5`.

Step 3.4 Record: No prior Bluetooth commits by Aurelien DESBRIERES were
found in this checkout. The patch was committed/applied by Bluetooth
maintainer Luiz Augusto von Dentz.

Step 3.5 Record: No functional prerequisite is required for this patch
in affected trees; it applies cleanly to current `v7.0.5`. It is most
relevant to trees with the `HCI_UART_PROTO_INIT` receive path and the
recent H4 initialization-race changes, such as checked `v6.19.y` and
`v7.0.y`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 902fe40bce70` found the original thread:
`https://patch.msgid.link/20260421135331.15425-1-aurelien@hackers.camp`.
`b4 dig -a` found only v1; the committed patch matches the submitted
revision.

Step 4.2 Record: `b4 dig -w` showed recipients included `linux-
bluetooth`, Marcel Holtmann, Johan Hedberg, Luiz Dentz, `linux-kernel`,
and syzbot. The patchwork bot reported it was applied to
`bluetooth/bluetooth-next.git` by Luiz Augusto von Dentz.

Step 4.3 Record: Syzkaller bug page verifies: “general protection fault
in h4_recv”, KASAN NULL-ptr-deref, C and syz reproducers, and fix commit
`902fe40bce70`.

Step 4.4 Record: No multi-patch series was found; only v1 of this one-
patch submission.

Step 4.5 Record: Direct lore stable fetch was blocked by Anubis; web
search found no stable-specific discussion. This does not affect the
decision because the syzbot crash and code path are verified elsewhere.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified functions: `ath_recv`, `bcsp_recv`, `h4_recv`,
`h5_recv`.

Step 5.2 Record: Exact call path verified: protocol structs assign
`.recv = h4_recv/ath_recv/bcsp_recv/h5_recv`; `hci_uart_tty_receive()`
calls `hu->proto->recv(hu, data, count)`; `tiocsti()` calls the line
discipline `receive_buf`.

Step 5.3 Record: Key callees include `h4_recv_buf()`,
`hci_recv_frame()`, `h5_reset_rx()`, `bcsp_unslip_one_byte()`, and skb
cleanup helpers. The first unsafe operation in each changed function was
a dereference of the private pointer.

Step 5.4 Record: Reachability is verified from userspace ioctl in the
syzkaller trace and reproducer: `openat("/dev/ptmx")`, `TIOCSETD` to
`N_HCI`, `HCIUARTSETPROTO` with fault injection, then `TIOCSTI`.

Step 5.5 Record: Similar HCI UART receive callbacks exist; some, like
`qca_recv` and `ll_recv`, still have `HCI_UART_REGISTERED` guards before
dereferencing private data. The candidate focuses on the four callbacks
identified in the accepted patch.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked `v6.19.14` and `v7.0.5`: the four callbacks
exist without the new NULL checks. These trees also have
`hci_uart_tty_receive()` accepting `HCI_UART_PROTO_INIT`. Checked
`v6.6`/`v6.12`: older receive gating differs, so the exact trigger is
less clearly present there.

Step 6.2 Record: `git apply --check` of the candidate diff succeeds on
the current `v7.0.5` checkout. Expected backport difficulty for similar
affected trees is clean or trivial.

Step 6.3 Record: No equivalent recv-callback NULL guard was found in
`v6.19.14` or `v7.0.5`. A related central cleanup exists upstream as
`68d39ea5e0ad`, but not in those checked stable tags.

## Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is Bluetooth HCI UART, a driver subsystem
under `drivers/bluetooth`. Criticality: important for systems using
UART-attached Bluetooth controllers; not universal core kernel code.

Step 7.2 Record: Bluetooth UART code is actively changing in this range,
with recent initialization-race and NULL-deref fixes in the same area.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems with `N_HCI` / HCI UART
Bluetooth line discipline enabled, especially with H4/H5/ATH/BCSP
protocol paths.

Step 8.2 Record: Trigger verified by syzkaller requires HCI UART line
discipline setup, fault/error during protocol setup, then received data
through `TIOCSTI`. The reproducer uses fault injection and ioctl access;
unprivileged exploitability was not established.

Step 8.3 Record: Failure mode is kernel oops/general protection fault
from KASAN NULL dereference in `h4_recv`; severity HIGH to CRITICAL
because it crashes the kernel.

Step 8.4 Record: Benefit is high for affected stable trees because it
prevents a reproducible kernel crash. Risk is very low: 12 added lines,
no new feature, no locking changes, no API changes.

## Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: syzbot report with
reproducer, KASAN NULL deref, syscall-triggered path, small surgical
patch, accepted by Bluetooth maintainer, applies cleanly to checked
stable tree. Evidence against: trigger appears tied to setup
failure/fault injection and may not affect older stable trees with
different HCI UART initialization flow. Unresolved: exact applicability
to every older LTS branch was not fully verified.

Step 9.2 Record: Stable rules checklist: obviously correct: yes; fixes
real bug: yes, syzbot crash; important issue: yes, kernel oops; small
and contained: yes, 12 insertions in four driver callbacks; no new
features/APIs: yes; applies to stable: yes for checked `v7.0.5`, likely
trivial for affected `v6.19.y`.

Step 9.3 Record: No exception category needed; this is a direct crash
fix, not a device ID/quirk/build/doc patch.

Step 9.4 Record: Decision is to backport to affected stable trees,
especially those containing the `HCI_UART_PROTO_INIT` receive path and
recent HCI UART initialization fixes. The benefit/risk ratio is strongly
favorable.

## Verification
- Phase 1: Parsed commit `902fe40bce7059722f7ffa1c378e577675cf1918` with
  `git show`; verified syzbot and Closes tags.
- Phase 2: Verified diff stat: four files, 12 insertions, only NULL
  guards in recv callbacks.
- Phase 3: Ran `git blame` on changed callback lines and inspected
  related commits `0ffac654e95c`, `981b4fd2baf3`, `0c3cd7a0b862`, and
  `68d39ea5e0ad`.
- Phase 4: Ran `b4 dig -c`, `-a`, and `-w`; fetched mirror thread and
  syzkaller bug/reproducer.
- Phase 5: Verified call path with source reads and exact searches:
  `tiocsti()` -> line discipline `receive_buf` ->
  `hci_uart_tty_receive()` -> protocol `.recv`.
- Phase 6: Checked `v6.19.14`, `v7.0.5`, `v6.12`, and `v6.6` snippets;
  verified patch applies to current `v7.0.5` with `git apply --check`.
- Phase 8: Verified failure mode from syzkaller crash log: KASAN NULL-
  ptr-deref/general protection fault in `h4_recv`.
- UNVERIFIED: Exact applicability to every active older stable/LTS
  branch; older branches with different HCI UART gating may not need
  this patch.

**YES**

 drivers/bluetooth/hci_ath.c  | 3 +++
 drivers/bluetooth/hci_bcsp.c | 3 +++
 drivers/bluetooth/hci_h4.c   | 3 +++
 drivers/bluetooth/hci_h5.c   | 3 +++
 4 files changed, 12 insertions(+)

diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
index fa679ad0acdfa..8201fa7f61e84 100644
--- a/drivers/bluetooth/hci_ath.c
+++ b/drivers/bluetooth/hci_ath.c
@@ -191,6 +191,9 @@ static int ath_recv(struct hci_uart *hu, const void *data, int count)
 {
 	struct ath_struct *ath = hu->priv;
 
+	if (!ath)
+		return -ENODEV;
+
 	ath->rx_skb = h4_recv_buf(hu, ath->rx_skb, data, count,
 				  ath_recv_pkts, ARRAY_SIZE(ath_recv_pkts));
 	if (IS_ERR(ath->rx_skb)) {
diff --git a/drivers/bluetooth/hci_bcsp.c b/drivers/bluetooth/hci_bcsp.c
index b386f91d8b46d..db56eead27ceb 100644
--- a/drivers/bluetooth/hci_bcsp.c
+++ b/drivers/bluetooth/hci_bcsp.c
@@ -585,6 +585,9 @@ static int bcsp_recv(struct hci_uart *hu, const void *data, int count)
 	if (!test_bit(HCI_UART_REGISTERED, &hu->flags))
 		return -EUNATCH;
 
+	if (!bcsp)
+		return -ENODEV;
+
 	BT_DBG("hu %p count %d rx_state %d rx_count %ld",
 	       hu, count, bcsp->rx_state, bcsp->rx_count);
 
diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index a889a66a326f7..7673727074985 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -109,6 +109,9 @@ static int h4_recv(struct hci_uart *hu, const void *data, int count)
 {
 	struct h4_struct *h4 = hu->priv;
 
+	if (!h4)
+		return -ENODEV;
+
 	h4->rx_skb = h4_recv_buf(hu, h4->rx_skb, data, count,
 				 h4_recv_pkts, ARRAY_SIZE(h4_recv_pkts));
 	if (IS_ERR(h4->rx_skb)) {
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index cfdf75dc28475..d353837182125 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -587,6 +587,9 @@ static int h5_recv(struct hci_uart *hu, const void *data, int count)
 	struct h5 *h5 = hu->priv;
 	const unsigned char *ptr = data;
 
+	if (!h5)
+		return -ENODEV;
+
 	BT_DBG("%s pending %zu count %d", hu->hdev->name, h5->rx_pending,
 	       count);
 
-- 
2.53.0

[PATCH AUTOSEL 7.0] ALSA: hda/realtek: Add mute LED fixup for HP Pavilion 15-cs1xxx

[Sasha Levin]

From: Rodrigo Faria <rodrigofilipefaria@gmail.com>

[ Upstream commit 01801e20d69346e1e6cec0d908f1cea3a49e51b5 ]

Add a new fixup for the mute LED on the HP Pavilion 15-cs1xxx series
using the VREF on NID 0x1b.

The BIOS on these models (tested up to F.32) incorrectly reports
the mute LED on NID 0x18 via DMI OEM strings, which lacks VREF
capabilities. This fixup overrides the LED pin to the correct
NID 0x1b.

Signed-off-by: Rodrigo Faria <rodrigofilipefaria@gmail.com>
Link: https://patch.msgid.link/20260505185518.23625-1-rodrigofilipefaria@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
This should be backported. It is a small, model-specific ALSA HDA
Realtek hardware workaround for an HP Pavilion 15-cs1xxx BIOS quirk: the
BIOS reports the mute LED on NID `0x18`, but that pin lacks VREF
capability; the patch routes the existing HP VREF mute-LED handling to
NID `0x1b`. It affects only systems matching PCI SSID `103c:856a`.

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record: Subsystem is `ALSA: hda/realtek`; action is `Add`; intent is
adding a mute LED fixup for HP Pavilion 15-cs1xxx.

Record: Tags present: `Signed-off-by: Rodrigo Faria
<rodrigofilipefaria@gmail.com>`, `Link: https://patch.msgid.link/2026050
5185518.23625-1-rodrigofilipefaria@gmail.com`, `Signed-off-by: Takashi
Iwai <tiwai@suse.de>`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Reviewed-by`, or `Cc: stable`.

Record: Bug described is incorrect BIOS/DMI OEM mute LED pin reporting.
Symptom is mute LED control using the wrong NID, so the mute LED does
not work correctly on this model. Version info: BIOS tested up to F.32.
Root cause: reported NID `0x18` lacks VREF capability; correct NID is
`0x1b`.

Record: This is a hardware quirk/fixup, not a hidden memory-safety bug.
It fixes incorrect hardware description/firmware behavior.

### Phase 2: Diff Analysis
Record: One file changed: `sound/hda/codecs/realtek/alc269.c`, 21
insertions, no removals. Modified areas: new helper
`alc295_fixup_hp_pavilion_mute_led_1b`, enum entry, fixup table entry,
PCI SSID quirk entry. Scope: single-file, surgical driver quirk.

Record: Before: HP vendor/DMI mute LED handling could derive the wrong
LED NID from BIOS OEM string. After: for PCI SSID `103c:856a`, the
driver selects a dedicated fixup that calls existing
`alc269_fixup_hp_mute_led()` and then overrides `spec->mute_led_nid =
0x1b`.

Record: Bug category is hardware workaround / quirk. Specific mechanism:
reuse existing VREF mute LED cdev setup, but force the pin to the
verified VREF-capable NID.

Record: Fix quality is good: small, contained, uses existing Realtek HDA
LED infrastructure, only selected for one HP subsystem ID. Regression
risk is very low and limited to that model.

### Phase 3: Git History Investigation
Record: Local exact-subject `git log` found no commit hash in this
checkout, so `b4 dig -c <hash>` could not be run against the target
commit. The patch was analyzed by message-id instead.

Record: `git blame` on nearby current-tree lines shows this repository’s
Realtek split file was imported through a grafted/snapshot-style commit,
so blame was not useful for the original upstream introduction of the
generic HP LED code.

Record: Related local history contains similar model-specific HP
Pavilion mute LED quirk commits: `2f388b4e8fdd6`, `068641bc9dc3d`, and
`ab2be3af8c4ea`, each one-line Pavilion mute LED quirk additions.

Record: Author history for Rodrigo Faria in this file returned no local
commits. Maintainer handling was verified from the mailing-list thread:
Takashi Iwai replied “Applied now.”

Record: Dependencies: no hard functional dependency beyond existing
Realtek HDA HP mute LED infrastructure. That infrastructure exists in
checked stable tags, though older trees use
`sound/pci/hda/patch_realtek.c` and may need manual path/context
backporting.

### Phase 4: Mailing List And External Research
Record: `b4 am` by message-id found `[PATCH v3] ALSA: hda/realtek: Add
mute LED fixup for HP Pavilion 15-cs1xxx`, 1 patch, 2 messages in
thread, DKIM-signed.

Record: Full thread shows the patch was sent to Takashi Iwai, Jaroslav
Kysela, `linux-sound`, and `linux-kernel`; Takashi replied “Applied
now.” No NAKs, objections, or stable nomination were found in the
fetched thread.

Record: `b4 am -v 2` could not find revision 2 from this message-id; web
searches also did not locate earlier cs1xxx revisions. The subject says
v3, but earlier revision discussion remains unverified.

Record: External search found public evidence of HP Pavilion 15-cs-
series systems using ALC295 audio, but no separate cs1xxx-specific bug
report was found.

Record: Stable-list searches found no cs1xxx-specific stable discussion,
but did find similar ALSA Realtek HP Pavilion mute LED quirks appearing
in stable discussion/results.

### Phase 5: Code Semantic Analysis
Record: Modified/added key function:
`alc295_fixup_hp_pavilion_mute_led_1b`.

Record: Callers: the new function is referenced from `alc269_fixups[]`;
that fixup is selected by `snd_hda_pick_fixup()` during Realtek codec
probe, using the PCI SSID quirk table. This is device
probe/configuration path, not a syscall hot path.

Record: Callees: `alc269_fixup_hp_mute_led()` scans HP DMI OEM strings,
sets LED polarity/NID, registers the mute LED cdev through
`snd_hda_gen_add_mute_led_cdev()`, and installs `led_power_filter`. The
new helper then overrides `spec->mute_led_nid`.

Record: Reachability: affected path is reachable during HDA codec probe
on matching HP hardware and later through the LED audio mute
trigger/cdev callback.

Record: Similar patterns: many existing HP Realtek quirks use
`ALC269_FIXUP_HP_MUTE_LED_MIC3`, `ALC295_FIXUP_HP_MUTE_LED_COEFBIT11`,
and related model-specific entries.

### Phase 6: Stable Tree Analysis
Record: Checked tags `v6.19`, `v6.18`, `v6.17`, `v6.16`, `v6.12`, and
`v6.6` exist locally.

Record: `v6.19` and `v6.18` use `sound/hda/codecs/realtek/alc269.c`;
`v6.6` uses older `sound/pci/hda/patch_realtek.c`.

Record: Generic HP VREF mute LED infrastructure exists in `v6.6` and
newer checked tags. `ALC295_FIXUP_HP_MUTE_LED_COEFBIT11` exists in
`v6.16+`, but not in `v6.12`/`v6.6`; the new fixup itself does not
depend on that helper, only on nearby placement/context.

Record: `git apply --check` succeeds on current `7.0.5` checkout. It
fails on a temporary `v6.18` worktree due to context drift, so stable
backports likely need minor manual adjustment. Older stable trees need
path adjustment to `sound/pci/hda/patch_realtek.c`.

### Phase 7: Subsystem And Maintainer Context
Record: Subsystem is ALSA HDA Realtek codec driver under sound.
Criticality: peripheral/driver-specific, affecting HP Pavilion 15-cs1xxx
users.

Record: The file is actively maintained and frequently receives model-
specific quirks. Recent local history includes multiple ALSA Realtek
HP/Lenovo/ASUS/Samsung quirk commits.

### Phase 8: Impact And Risk
Record: Affected users are specific to HP Pavilion 15-cs1xxx / PCI SSID
`103c:856a` with Realtek ALC295-class HDA audio.

Record: Trigger condition is normal codec probe and mute LED operation
on that hardware. No evidence found that unprivileged users can trigger
a crash or security issue; the user-visible effect is
incorrect/nonfunctional mute LED.

Record: Failure severity is LOW to MEDIUM: not a crash or data
corruption issue, but a real hardware functionality regression/quirk.

Record: Benefit is medium for affected users because it restores correct
mute LED behavior. Risk is very low because the quirk is model-specific
and uses existing LED control paths.

### Phase 9: Final Synthesis
Record: Evidence for backporting: hardware quirk category, fixes real
BIOS misreporting, limited to one PCI SSID, small patch, uses
established ALSA Realtek fixup patterns, accepted by ALSA maintainer,
and similar HP mute LED quirks are common stable material.

Record: Evidence against backporting: no crash/security/data corruption;
no explicit stable tag; current patch does not apply cleanly to at least
`v6.18` without minor context adjustment; older trees need file-
path/context adjustment.

Record: Stable rules: obviously correct enough by inspection; fixes a
real hardware bug; small and contained; no new public API; no new
feature beyond hardware-specific workaround; stable application may
require minor backport edits.

Record: Exception category applies: hardware-specific quirk/workaround
in an existing driver.

## Verification
- [Phase 1] Parsed subject, body, and tags from supplied commit message
  and fetched mbox.
- [Phase 2] Verified patch is 21 insertions in
  `sound/hda/codecs/realtek/alc269.c`.
- [Phase 3] Ran local `git log` by exact subject: no matching commit
  hash found.
- [Phase 3] Ran `git blame` around affected code: local history is
  snapshot/grafted, limiting original-introduction analysis.
- [Phase 4] Ran `b4 am` by message-id: found v3 patch, 2-message thread,
  DKIM-signed.
- [Phase 4] Read full mbox: Takashi Iwai replied “Applied now”; no
  objections found.
- [Phase 5] Traced quirk selection through `snd_hda_pick_fixup()` and
  Realtek probe path.
- [Phase 6] Checked stable tags and paths: `v6.18+` split path, `v6.6`
  old `patch_realtek.c` path.
- [Phase 6] Checked relevant symbols in stable tags: HP VREF LED
  infrastructure exists in checked stable trees.
- [Phase 6] Ran `git apply --check`: applies to current checkout, not
  cleanly to `v6.18` due context drift.
- [Phase 8] Verified failure mode from commit body and code: wrong LED
  NID affects mute LED behavior, not memory safety.
- UNVERIFIED: exact applied upstream commit SHA, because it was not
  present in local `git log`.
- UNVERIFIED: earlier v1/v2 review discussion, because `b4` and web
  search did not locate those revisions.
- UNVERIFIED: exact applicability to every active older LTS tree beyond
  the checked tags.

**YES**

 sound/hda/codecs/realtek/alc269.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index a55b73ced81d6..7e0289a1a1ca7 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -1676,6 +1676,21 @@ static void alc295_fixup_hp_mute_led_coefbit11(struct hda_codec *codec,
 	}
 }
 
+/* Override wrong pin to NID 0x1b (F.32 BIOS reports 0x18 via DMI OEM string)
+ * on HP pavilion 15-cs1xxx laptops
+ */
+static void alc295_fixup_hp_pavilion_mute_led_1b(struct hda_codec *codec,
+						 const struct hda_fixup *fix,
+						 int action)
+{
+	struct alc_spec *spec = codec->spec;
+
+	alc269_fixup_hp_mute_led(codec, fix, action);
+
+	if (action == HDA_FIXUP_ACT_PRE_PROBE)
+		spec->mute_led_nid = 0x1b;
+}
+
 static void alc233_fixup_lenovo_coef_micmute_led(struct hda_codec *codec,
 				const struct hda_fixup *fix, int action)
 {
@@ -3872,6 +3887,7 @@ enum {
 	ALC290_FIXUP_SUBWOOFER,
 	ALC290_FIXUP_SUBWOOFER_HSJACK,
 	ALC295_FIXUP_HP_MUTE_LED_COEFBIT11,
+	ALC295_FIXUP_HP_PAVILION_MUTE_LED_1B,
 	ALC269_FIXUP_THINKPAD_ACPI,
 	ALC269_FIXUP_LENOVO_XPAD_ACPI,
 	ALC269_FIXUP_DMIC_THINKPAD_ACPI,
@@ -5715,6 +5731,10 @@ static const struct hda_fixup alc269_fixups[] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc295_fixup_hp_mute_led_coefbit11,
 	},
+	[ALC295_FIXUP_HP_PAVILION_MUTE_LED_1B] = {
+		.type = HDA_FIXUP_FUNC,
+		.v.func = alc295_fixup_hp_pavilion_mute_led_1b,
+	},
 	[ALC298_FIXUP_SAMSUNG_AMP] = {
 		.type = HDA_FIXUP_FUNC,
 		.v.func = alc298_fixup_samsung_amp,
@@ -6912,6 +6932,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8537, "HP ProBook 440 G6", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
 	SND_PCI_QUIRK(0x103c, 0x8548, "HP EliteBook x360 830 G6", ALC285_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x854a, "HP EliteBook 830 G6", ALC285_FIXUP_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x856a, "HP Pavilion 15-cs1xxx", ALC295_FIXUP_HP_PAVILION_MUTE_LED_1B),
 	SND_PCI_QUIRK(0x103c, 0x85c6, "HP Pavilion x360 Convertible 14-dy1xxx", ALC295_FIXUP_HP_MUTE_LED_COEFBIT11),
 	SND_PCI_QUIRK(0x103c, 0x85de, "HP Envy x360 13-ar0xxx", ALC285_FIXUP_HP_ENVY_X360),
 	SND_PCI_QUIRK(0x103c, 0x8603, "HP Omen 17-cb0xxx", ALC285_FIXUP_HP_MUTE_LED),
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] btrfs: fix check_chunk_block_group_mappings() to iterate all chunk maps

[Sasha Levin]

From: ZhengYuan Huang <gality369@gmail.com>

[ Upstream commit fc51cba3ebae67f967120e27162e94cfb8594479 ]

[BUG]
A corrupted image with a chunk present in the chunk tree but whose
corresponding block group item is missing from the extent tree can be
mounted successfully, even though check_chunk_block_group_mappings()
is supposed to catch exactly this corruption at mount time.  Once
mounted, running btrfs balance with a usage filter (-dusage=N or
-dusage=min..max) triggers a null-ptr-deref:

  KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
    RIP: 0010:chunk_usage_filter fs/btrfs/volumes.c:3874 [inline]
    RIP: 0010:should_balance_chunk fs/btrfs/volumes.c:4018 [inline]
    RIP: 0010:__btrfs_balance fs/btrfs/volumes.c:4172 [inline]
    RIP: 0010:btrfs_balance+0x2024/0x42b0 fs/btrfs/volumes.c:4604

[CAUSE]
The crash occurs because __btrfs_balance() iterates the on-disk chunk
tree, finds the orphaned chunk, calls chunk_usage_filter() (or
chunk_usage_range_filter()), which queries the in-memory block group
cache via btrfs_lookup_block_group().  Since no block group was ever
inserted for this chunk, the lookup returns NULL, and the subsequent
dereference of cache->used crashes.

check_chunk_block_group_mappings() uses btrfs_find_chunk_map() to
iterate the in-memory chunk map (fs_info->mapping_tree):

  map = btrfs_find_chunk_map(fs_info, start, 1);

With @start = 0 and @length = 1, btrfs_find_chunk_map() looks for a
chunk map that *contains* the logical address 0. If no chunk contains
logical address 0, btrfs_find_chunk_map(fs_info, 0, 1) returns NULL
immediately and the loop breaks after the very first iteration,
having checked zero chunks. The entire verification function is therefore
a no-op, and the corrupted image passes the mount-time check undetected.

[FIX]
Replace the btrfs_find_chunk_map() based loop with a direct in-order
walk of fs_info->mapping_tree using rb_first_cached() + rb_next().
This guarantees that every chunk map in the tree is visited regardless
of the logical addresses involved.

No lock is taken around the traversal. This function is called during
mount from btrfs_read_block_groups(), which is invoked from open_ctree()
before any background threads (cleaner, transaction kthread, etc.) are
started. There are therefore no concurrent writers that could modify
mapping_tree at this point. An analogous lockless direct traversal of
mapping_tree already exists in fill_dummy_bgs() in the same file.

Since we walk the rb-tree directly via rb_entry() without going through
btrfs_find_chunk_map(), no reference is taken on each map entry, so the
btrfs_free_chunk_map() calls are also removed.

Signed-off-by: ZhengYuan Huang <gality369@gmail.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record: Subsystem is `btrfs`; action verb is `fix`; claimed intent is to
make `check_chunk_block_group_mappings()` actually visit all chunk maps.

Record: Tags found in the committed version: `Signed-off-by: ZhengYuan
Huang <gality369@gmail.com>`, `Reviewed-by: David Sterba
<dsterba@suse.com>`, `Signed-off-by: David Sterba <dsterba@suse.com>`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Link:`, or `Cc:
stable@vger.kernel.org` tag was present.

Record: The commit describes a real mount-time corruption validation
bug: a chunk can exist in the chunk tree while the matching block group
item is missing from the extent tree. Because the verifier may check
zero chunks, the corrupted filesystem can mount, and later `btrfs
balance -dusage=...` can hit a NULL dereference in
`chunk_usage_filter()` / `chunk_usage_range_filter()`.

Record: This is not hidden cleanup. It is an explicit NULL-deref /
corruption-detection fix.

## Phase 2: Diff Analysis
Record: One file changed: `fs/btrfs/block-group.c`, 8 insertions and 15
deletions in the committed object. Modified function:
`check_chunk_block_group_mappings()`. Scope: single-file surgical fix.

Record: Before, the function started at logical address 0 and repeatedly
called `btrfs_find_chunk_map(fs_info, start, 1)`. If no chunk
intersected `[0,1)`, the first lookup returned NULL and the loop exited
without checking any chunk. After, it walks `fs_info->mapping_tree`
directly with `rb_first_cached()` and `rb_next()`.

Record: Bug category is logic/correctness with memory-safety
consequence. The broken verifier allows filesystem corruption through
mount; later balance can dereference a NULL block group pointer.

Record: Fix quality is good: small, direct, reviewed by the btrfs
maintainer, and it removes `btrfs_free_chunk_map()` calls because direct
`rb_entry()` traversal does not acquire chunk-map references. Regression
risk is low; the main concern is lockless traversal, but code and commit
context verify this runs during mount before cleaner/transaction
kthreads start.

## Phase 3: Git History Investigation
Record: `git blame` on the pre-fix function shows the verifier loop
originated from `4358d9635a16` (`btrfs: migrate the block group
read/creation code`), first contained in `v5.4-rc1`. Later chunk-map
conversion came from `7dc66abb5a47` in `v6.8-rc1`.

Record: No `Fixes:` tag is present, so there was no Fixes target to
follow.

Record: Recent `fs/btrfs/block-group.c` history shows normal btrfs
churn, but no prior fix for `check_chunk_block_group_mappings()` except
this commit. `git log --grep=check_chunk_block_group_mappings
origin/master` found only `fc51cba3ebae`.

Record: Author history in `fs/btrfs` shows ZhengYuan Huang has other
btrfs fixes; the patch was reviewed and committed by David Sterba, who
is listed in `MAINTAINERS` as a btrfs maintainer.

Record: The commit was submitted as patch 4/4, but the final mainline
history contains this verifier fix independently. The earlier balance
hardening patches were not found in `origin/master`; this patch still
has standalone value because it prevents the corrupted state from
passing mount.

## Phase 4: Mailing List And External Research
Record: `b4 dig -c fc51cba3ebae...` found the original lore submission:
`https://patch.msgid.link/20260325004339.2323838-5-gality369@gmail.com`.

Record: `b4 dig -a` found v2 and v3 series. v3 is the committed/latest
revision found by `b4`.

Record: `b4 dig -w` showed the patch was sent to David Sterba, Chris
Mason, Ilya Dryomov, `linux-btrfs`, and `linux-kernel`.

Record: Direct `WebFetch` of lore was blocked by Anubis, so I used `b4`
mbox content and Patchew. The v3 mbox includes David Sterba saying he
added the fixes to `for-next`; the committed patch has his `Reviewed-
by`.

Record: Patchew v2 discussion records David Sterba saying block group
lookup checks make sense in general, and the author clarified the bug is
reproducible with a crafted filesystem image and normal syscalls, not
only fuzzing. No NAKs were found. No stable-specific discussion was
found by web search.

## Phase 5: Code Semantic Analysis
Record: Modified function: `check_chunk_block_group_mappings()`.

Record: Caller trace verified: `open_ctree()` calls
`btrfs_read_block_groups()`, which calls
`check_chunk_block_group_mappings()`. In `disk-io.c`,
`btrfs_read_block_groups()` occurs before the cleaner and transaction
kthreads are started.

Record: Crash path verified: `BTRFS_IOC_BALANCE_V2` reaches
`btrfs_ioctl_balance()`, then `btrfs_balance()`, `__btrfs_balance()`,
`should_balance_chunk()`, then usage filters. Current code dereferences
`cache->used` immediately after `btrfs_lookup_block_group()`.

Record: Key callees: `rb_first_cached()`, `rb_next()`, `rb_entry()`,
`btrfs_lookup_block_group()`, `btrfs_put_block_group()`, and error
reporting via `btrfs_err()`.

Record: Similar safe direct mapping-tree traversal already exists in
`fill_dummy_bgs()` in the same file, and other mapping-tree traversal
code exists elsewhere with appropriate locking/context.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Record: Buggy code exists in stable branches. `stable/linux-6.8.y`
through `stable/linux-6.19.y` contain the `btrfs_find_chunk_map(fs_info,
start, 1)` pattern. `stable/linux-5.4.y`, `5.10.y`, `5.15.y`, `6.1.y`,
`6.6.y`, and `6.7.y` contain the older analogous
`lookup_extent_mapping(map_tree, start, 1)` pattern.

Record: The upstream patch applies cleanly to the current `7.0` tree
with `git apply --check`.

Record: Older pre-`6.8` stable trees likely need an adjusted backport
because they use `extent_map` / `map_lookup` rather than `struct
btrfs_chunk_map`. The bug mechanism is still verified there by the
strict intersection semantics in `extent_map.c`.

Record: I found no related stable branch commit already fixing this
issue by subject/grep.

## Phase 7: Subsystem And Maintainer Context
Record: Subsystem is btrfs filesystem code under `fs/btrfs/`.
Criticality is IMPORTANT to CORE-for-users-of-btrfs because filesystem
corruption handling and kernel crashes are involved.

Record: Subsystem is actively maintained; recent `origin/master --
fs/btrfs` history shows many btrfs fixes. David Sterba is listed as a
btrfs maintainer and reviewed/committed this fix.

## Phase 8: Impact And Risk Assessment
Record: Affected users are btrfs users with a corrupted or crafted
filesystem image containing a chunk without a corresponding block group
item.

Record: Trigger is mount of that corrupted image followed by balance
with usage filters for the crash path; the patched behavior rejects the
inconsistency at mount time with `-EUCLEAN`. Patchew discussion says it
is reproducible with crafted filesystem image plus normal syscalls.
Balance ioctl requires `CAP_SYS_ADMIN`, verified in
`btrfs_ioctl_balance()`.

Record: Failure mode is HIGH/CRITICAL: KASAN NULL pointer dereference in
filesystem balance code, i.e. kernel crash/oops risk, and the underlying
issue is missed filesystem corruption detection.

Record: Benefit is high: prevents corrupted btrfs images from mounting
silently and avoids a later NULL dereference. Risk is low for `6.8+`
style trees: one contained verifier loop change during mount. Risk is
medium-low for older trees only because the backport needs translation
to the older extent-map data structure.

## Phase 9: Final Synthesis
Record: Evidence for backporting: real NULL-deref crash path, crafted-
image reproducibility, filesystem corruption detection failure, small
one-function fix, maintainer review, code present across stable trees,
and clean apply to current `7.0` tree.

Record: Evidence against backporting: no `Fixes:`/`Cc: stable` tag;
older stable trees need adjusted backports; the exact patch is not
directly applicable to pre-`6.8` extent-map code. These do not outweigh
the bug severity.

Record: Stable rules checklist: obviously correct and reviewed: yes;
fixes real user-visible bug: yes; important issue: yes, NULL deref and
missed corruption detection; small and contained: yes; no new
feature/API: yes; stable application: clean for current `7.0`, likely
straightforward for `6.8+`, adjusted backport needed for older trees.

Record: Exception category: none. This is a normal bug fix, not a device
ID, quirk, DT, build, or documentation-only patch.

## Verification
- [Phase 1] `git show --format=fuller --stat fc51cba3ebae...`: confirmed
  commit message, tags, author, reviewer, and one-file diff.
- [Phase 2] `git show --no-ext-diff fc51cba3ebae... -- fs/btrfs/block-
  group.c`: confirmed the loop replacement and removal of
  `btrfs_free_chunk_map()` calls.
- [Phase 3] `git blame -L ... fc51cba3ebae^ -- fs/btrfs/block-group.c`:
  identified `4358d9635a16` as the original verifier-loop source and
  `7dc66abb5a47` as later chunk-map conversion.
- [Phase 3] `git show 4358d9635a16` and `git describe --contains`:
  confirmed first appearance around `v5.4-rc1`.
- [Phase 3] `git log --grep=check_chunk_block_group_mappings
  origin/master`: found no prior related fix except this commit.
- [Phase 4] `b4 dig -c`, `-a`, `-w`, and `-m`: found v3 lore submission,
  v2/v3 revision history, recipients, and maintainer response.
- [Phase 4] Patchew v2 fetch: confirmed David Sterba review discussion
  and author statement that crafted images plus normal syscalls
  reproduce the issue.
- [Phase 5] `rg`/file reads in `disk-io.c`, `block-group.c`,
  `volumes.c`, and `ioctl.c`: verified mount-time call path and balance
  NULL-deref path.
- [Phase 6] `git grep` on stable branches: confirmed the buggy lookup
  pattern in `6.8.y` through `6.19.y` and analogous extent-map pattern
  in older stable branches.
- [Phase 6] `git apply --check` against the current tree: confirmed
  clean application to the current `7.0` checkout.
- [Phase 7] `MAINTAINERS`: confirmed David Sterba as btrfs maintainer.
- UNVERIFIED: I did not run a runtime reproducer or mount a crafted
  btrfs image.
- UNVERIFIED: I did not prove exact clean application to every older
  stable branch; pre-`6.8` trees require an adjusted extent-map
  backport.

The technical merit is strong: this is a small, reviewed btrfs
corruption-detection fix that prevents a real NULL-deref crash path and
should be backported, with adjusted backports for older extent-map based
stable trees.

**YES**

 fs/btrfs/block-group.c | 23 ++++++++---------------
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
index c0d17a369bda5..acb55b6f1e550 100644
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -2374,29 +2374,25 @@ static struct btrfs_block_group *btrfs_create_block_group(
  */
 static int check_chunk_block_group_mappings(struct btrfs_fs_info *fs_info)
 {
-	u64 start = 0;
+	struct rb_node *node;
 	int ret = 0;
 
-	while (1) {
+	/*
+	 * This is called during mount from btrfs_read_block_groups(), before
+	 * any background threads are started, so no concurrent writers can
+	 * modify the mapping_tree. No lock is needed here.
+	 */
+	for (node = rb_first_cached(&fs_info->mapping_tree); node; node = rb_next(node)) {
 		struct btrfs_chunk_map *map;
 		struct btrfs_block_group *bg;
 
-		/*
-		 * btrfs_find_chunk_map() will return the first chunk map
-		 * intersecting the range, so setting @length to 1 is enough to
-		 * get the first chunk.
-		 */
-		map = btrfs_find_chunk_map(fs_info, start, 1);
-		if (!map)
-			break;
-
+		map = rb_entry(node, struct btrfs_chunk_map, rb_node);
 		bg = btrfs_lookup_block_group(fs_info, map->start);
 		if (unlikely(!bg)) {
 			btrfs_err(fs_info,
 	"chunk start=%llu len=%llu doesn't have corresponding block group",
 				     map->start, map->chunk_len);
 			ret = -EUCLEAN;
-			btrfs_free_chunk_map(map);
 			break;
 		}
 		if (unlikely(bg->start != map->start || bg->length != map->chunk_len ||
@@ -2409,12 +2405,9 @@ static int check_chunk_block_group_mappings(struct btrfs_fs_info *fs_info)
 				bg->start, bg->length,
 				bg->flags & BTRFS_BLOCK_GROUP_TYPE_MASK);
 			ret = -EUCLEAN;
-			btrfs_free_chunk_map(map);
 			btrfs_put_block_group(bg);
 			break;
 		}
-		start = map->start + map->chunk_len;
-		btrfs_free_chunk_map(map);
 		btrfs_put_block_group(bg);
 	}
 	return ret;
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] ALSA: usb-audio: Add quirk flags for AlphaTheta EUPHONIA

[Sasha Levin]

From: Anton Swart <anton.swart.jhb@gmail.com>

[ Upstream commit f80785888f7c0980a49545b87a80e3817c9ed7c6 ]

The AlphaTheta EUPHONIA (VID 0x2b73, PID 0x0047) is a USB Audio
Class 2 DJ mixer that requires implicit feedback for full-duplex
operation. The capture endpoint (0x83 IN, interface 2) acts as the
implicit feedback source for the playback endpoint (0x03 OUT,
interface 1), and the device firmware does not send isochronous
data on the capture endpoint unless the host is simultaneously
sending data on the playback endpoint, i.e. playback must be
started first.

Without QUIRK_FLAG_PLAYBACK_FIRST the kernel waits for capture URBs
before submitting playback URBs, creating a deadlock: the device
waits for playback data and the host waits for capture data.
Without QUIRK_FLAG_GENERIC_IMPLICIT_FB the kernel does not detect
the implicit feedback relationship between the two interfaces.

The same flag combination is already used for the Behringer UMC202HD,
UMC204HD and UMC404HD (0x1397:0x0507/0x0508/0x0509), which exhibit
the identical implicit-feedback topology.

Tested on Raspberry Pi 5 with kernel 6.12.75; continuous full-duplex
streaming at 96 kHz / 24-bit, zero XRUNs.

Signed-off-by: Anton Swart <anton.swart.jhb@gmail.com>
Link: https://patch.msgid.link/20260503211517.14332-1-anton.swart.jhb@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject
Record: Subsystem: `ALSA: usb-audio`. Action verb: `Add`. Claimed
intent: add device-specific quirk flags for AlphaTheta EUPHONIA.

### Step 1.2: Tags
Record:
- `Signed-off-by: Anton Swart <anton.swart.jhb@gmail.com>`: author
  signoff.
- `Link: https://patch.msgid.link/20260503211517.14332-1-
  anton.swart.jhb@gmail.com`: original patch submission.
- `Signed-off-by: Takashi Iwai <tiwai@suse.de>`: supplied commit message
  says ALSA maintainer applied/signed off.
- No `Fixes:` tag.
- No `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
  stable@vger.kernel.org` tags.
- The patch body says it was tested on Raspberry Pi 5 with kernel
  `6.12.75`, but this is not a formal `Tested-by:` tag.

### Step 1.3: Commit Body
Record: The bug is a device-specific full-duplex startup deadlock for
AlphaTheta EUPHONIA USB Audio Class 2 mixer `VID:PID 0x2b73:0x0047`. The
capture endpoint is the implicit feedback source, but firmware does not
emit capture isochronous data until playback is already sending.
Symptom: full-duplex streaming cannot start because host waits for
capture feedback while device waits for playback data. Version info:
tested on `6.12.75`. Root cause: kernel does not both detect generic
implicit feedback and start playback first for this device.

### Step 1.4: Hidden Bug Fix
Record: Yes. Although phrased as “Add quirk flags”, this is a hardware
workaround fixing real device malfunction. It falls under the stable
hardware-quirk exception.

## Phase 2: Diff Analysis

### Step 2.1: Inventory
Record:
- File changed: `sound/usb/quirks.c`
- Scope: 2 lines added, 0 removed.
- Function/data object modified: `quirk_flags_table[]`.
- Classification: single-file, table-only, surgical hardware quirk.

### Step 2.2: Code Flow Change
Record:
- Before: device `0x2b73:0x0047` had no built-in quirk flag entry.
- After: matching USB audio devices get `QUIRK_FLAG_PLAYBACK_FIRST |
  QUIRK_FLAG_GENERIC_IMPLICIT_FB`.
- Affected path: USB audio device probe initializes `chip->quirk_flags`
  from `quirk_flags_table[]`; stream parsing and endpoint start then use
  those flags.
- Path type: initialization/probe plus later stream-start behavior.

### Step 2.3: Bug Mechanism
Record:
- Category: hardware workaround / USB audio implicit feedback startup
  ordering.
- `QUIRK_FLAG_GENERIC_IMPLICIT_FB` is verified in `sound/usb/implicit.c`
  to trigger `add_generic_implicit_fb()` when the generic implicit-
  feedback flag is set.
- `QUIRK_FLAG_PLAYBACK_FIRST` is verified in `sound/usb/endpoint.c` to
  skip the normal “do not submit playback URBs until feedback arrives”
  behavior for implicit-feedback sinks.
- Together they fix the described stream-start deadlock for this device.

### Step 2.4: Fix Quality
Record: The fix is obviously minimal and consistent with existing
entries. The same exact flag combination is already present for
Behringer UMC202HD/UMC204HD/UMC404HD in `sound/usb/quirks.c`. Regression
risk is very low because the new behavior is limited to exact USB ID
`0x2b73:0x0047`.

## Phase 3: Git History Investigation

### Step 3.1: Blame Changed Area
Record: `git blame` on the insertion area showed neighboring quirk
entries are longstanding table entries, including Fiero SC-01 entries
introduced by `668abe6dc7b619` (`ALSA: usb-audio: Sort quirk table
entries`). Local history is partly grafted, so I did not rely on graft-
boundary blame for introduction of the whole mechanism.

### Step 3.2: Fixes Tag
Record: Not applicable. There is no `Fixes:` tag.

### Step 3.3: File History
Record: Recent `sound/usb/quirks.c` history contains many similar
device-specific quirk additions/fixes. No prerequisite patch is
referenced by the commit message. This patch is standalone for trees
that already have `QUIRK_FLAG_GENERIC_IMPLICIT_FB` and
`QUIRK_FLAG_PLAYBACK_FIRST`.

### Step 3.4: Author History
Record: `git log --author='Anton Swart' -10 -- sound/usb` found no local
prior commits. `MAINTAINERS` verifies Takashi Iwai is a listed `SOUND`
maintainer, and the supplied commit message has his signoff.

### Step 3.5: Dependencies
Record: The patch depends on existing `QUIRK_FLAG_GENERIC_IMPLICIT_FB`
and `QUIRK_FLAG_PLAYBACK_FIRST` infrastructure. Verified present in
`v6.1`, `v6.6`, `v6.12`, and `v7.0.5`. Verified `v5.15` has
`PLAYBACK_FIRST` but not `GENERIC_IMPLICIT_FB`, so this exact patch is
not directly applicable to `5.15.y`.

## Phase 4: Mailing List And External Research

### Step 4.1: Original Discussion
Record: No upstream commit hash was available locally, so `b4 dig -c
<commit>` could not be used. I used the supplied message-id link with
`b4 am`. It found the patch at `https://lore.kernel.org/all/202605032115
17.14332-1-anton.swart.jhb@gmail.com/`, one patch, two messages in
thread, zero code-review messages analyzed, DKIM signed by Gmail.
`WebFetch` to lore was blocked by Anubis.

### Step 4.2: Reviewers / Recipients
Record: `b4 am --cc-trailers` showed recipients: `alsa-devel@alsa-
project.org`, Jaroslav Kysela, Takashi Iwai, and `linux-
kernel@vger.kernel.org`. These are appropriate ALSA/kernel recipients.
No reviewer trailers were found in the b4-processed thread.

### Step 4.3: Bug Report
Record: No separate bug report or `Reported-by:` tag found. The patch
itself gives a concrete device topology, failure mode, and test result.
Web search found AlphaTheta product/support pages but no separate kernel
bug report for this quirk.

### Step 4.4: Related Series
Record: `b4 am` found a single-patch submission, not a multi-patch
series. No series dependency found.

### Step 4.5: Stable Mailing List
Record: `WebFetch` searches for lore stable/all were blocked by Anubis.
Web search did not find stable-list discussion for this exact patch. No
evidence found of a stable-specific objection.

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions/Data
Record: Modified object: `quirk_flags_table[]`. Affected functions
verified:
- `snd_usb_init_quirk_flags_table()`
- `snd_usb_init_quirk_flags()`
- `snd_usb_audio_create()`
- `audioformat_playback_quirk()`
- `add_generic_implicit_fb()`
- `snd_usb_endpoint_start()`

### Step 5.2: Callers
Record: `usb_audio_probe()` calls `snd_usb_audio_create()`, which
initializes quirk flags. ALSA PCM ops call `snd_usb_pcm_prepare()` and
playback/capture trigger callbacks, which call `start_endpoints()`,
which calls `snd_usb_endpoint_start()`.

### Step 5.3: Callees
Record: `snd_usb_init_quirk_flags_table()` scans `quirk_flags_table[]`
and ORs flags into `chip->quirk_flags`. `audioformat_playback_quirk()`
calls `add_generic_implicit_fb()` when `QUIRK_FLAG_GENERIC_IMPLICIT_FB`
is set. `snd_usb_endpoint_start()` changes URB submission behavior based
on `QUIRK_FLAG_PLAYBACK_FIRST`.

### Step 5.4: Call Chain / Reachability
Record: Reachable when the matching USB audio device is probed and
userspace opens/starts ALSA PCM full-duplex streams. I did not verify
whether an unprivileged user can trigger it on a given distribution;
ALSA device permissions are policy-dependent.

### Step 5.5: Similar Patterns
Record: Verified existing exact flag combination for Behringer
`0x1397:0x0507`, `0x0508`, and `0x0509`. Verified
`QUIRK_FLAG_GENERIC_IMPLICIT_FB` appears in ten quirk-table entries in
current `7.0.y`.

## Phase 6: Stable Tree Analysis

### Step 6.1: Buggy Code Exists
Record:
- `v7.0.5`: quirk infrastructure exists; EUPHONIA entry absent.
- `v6.12.75`: quirk infrastructure exists; EUPHONIA entry absent.
- `v6.6`: quirk infrastructure exists; EUPHONIA entry absent.
- `v6.1`: quirk infrastructure exists; EUPHONIA entry absent.
- `v5.15`: `GENERIC_IMPLICIT_FB` flag absent, so this exact patch is not
  applicable.

### Step 6.2: Backport Difficulty
Record:
- `v7.0.5`: index-only `git apply --check` passes.
- `v6.12.75`: index-only `git apply --check` passes.
- `v6.6` and `v6.1`: exact patch does not apply because nearby context
  differs, but the same table and flags exist; expected minor context-
  only backport.
- `v5.15`: exact patch does not apply and lacks required generic flag
  infrastructure.

### Step 6.3: Related Fixes Already Stable
Record: No existing `0x2b73:0x0047` or `AlphaTheta EUPHONIA` entry found
in the local tree. No local history match for this device.

## Phase 7: Subsystem Context

### Step 7.1: Subsystem Criticality
Record: Subsystem is ALSA USB audio, under `sound/usb`. Criticality:
important for users of affected USB audio hardware, but not
universal/core kernel.

### Step 7.2: Activity
Record: `sound/usb` is actively maintained; recent history shows
multiple ALSA USB fixes and quirk updates. Maintainer context verified
through `MAINTAINERS`.

## Phase 8: Impact And Risk

### Step 8.1: Affected Users
Record: Driver/hardware-specific: users of AlphaTheta EUPHONIA USB audio
mixer on kernels with this usb-audio quirk infrastructure.

### Step 8.2: Trigger Conditions
Record: Trigger is full-duplex streaming where capture endpoint acts as
implicit feedback and playback must start first. The commit message
reports testing continuous full-duplex 96 kHz / 24-bit on Raspberry Pi 5
with kernel `6.12.75`.

### Step 8.3: Failure Severity
Record: Failure mode is a device/stream-start deadlock: audio full-
duplex streaming does not start. Severity: medium-high for affected
hardware users. It is not verified as a system-wide kernel
deadlock/panic.

### Step 8.4: Risk / Benefit
Record: Benefit is high for affected hardware because it makes full-
duplex operation work. Risk is very low: exact USB-ID match, 2-line
table addition, no API or shared logic change.

## Phase 9: Final Synthesis

### Step 9.1: Evidence
Record: Evidence for backporting:
- Real hardware malfunction with concrete topology and failure mode.
- Hardware quirk category is explicitly stable-suitable.
- 2-line exact-device table addition.
- Existing identical flag combination for similar implicit-feedback
  devices.
- Tested on `6.12.75`.
- Appropriate ALSA maintainers/lists were CC’d; supplied commit has
  Takashi Iwai signoff.

Evidence against:
- No separate `Reported-by:` or formal `Tested-by:` tag.
- `v6.6`/`v6.1` need minor context backport.
- `v5.15` lacks `QUIRK_FLAG_GENERIC_IMPLICIT_FB`, so this exact patch
  should not be applied there without additional analysis/prerequisites.

Unresolved:
- Lore web UI could not be fetched due Anubis.
- No upstream commit hash was available locally, so `b4 dig -c` could
  not be performed.
- No independent bug report was found.

### Step 9.2: Stable Rules
Record:
1. Obviously correct and tested: yes, for applicable trees; 2-line
   exact-ID quirk and patch body reports testing.
2. Fixes a real bug: yes, full-duplex stream startup deadlock for
   specific hardware.
3. Important issue: yes for affected hardware; device full-duplex
   operation is broken without it.
4. Small and contained: yes, one file, two lines.
5. No new APIs/features: yes. This is a hardware quirk, not a new
   interface.
6. Applies to stable trees: cleanly to `v7.0.5` and `v6.12.75`; minor
   context backport for `v6.6`/`v6.1`; not directly to `v5.15`.

### Step 9.3: Exception Category
Record: Hardware quirk/workaround for a broken/nonstandard USB audio
device. This is one of the strong stable-appropriate exception
categories.

### Step 9.4: Decision
This should be backported to stable trees that already have the generic
implicit-feedback quirk flag infrastructure, especially `6.12.y`,
`6.6.y`, `6.1.y`, and `7.0.y` if applicable. For `5.15.y`, do not apply
this exact patch without separate prerequisite/backport work because the
required `QUIRK_FLAG_GENERIC_IMPLICIT_FB` flag is absent.

## Verification

- Phase 1: Parsed supplied subject, body, and tags; verified original
  patch body with `b4 am` mbox.
- Phase 2: Verified diff is 2 insertions in `sound/usb/quirks.c`.
- Phase 2/5: Read `sound/usb/quirks.c`, `sound/usb/usbaudio.h`,
  `sound/usb/implicit.c`, `sound/usb/endpoint.c`, `sound/usb/card.c`,
  `sound/usb/pcm.c`, and `sound/usb/stream.c`.
- Phase 3: Ran `git blame` around the insertion area and similar
  Behringer entries; noted grafted history limits.
- Phase 3: Ran file and author history searches without `--all`.
- Phase 4: Ran `b4 am` on the supplied patch link; found one patch and
  DKIM-signed submission.
- Phase 4: Ran `b4 am --cc-trailers`; verified ALSA maintainers/lists
  were CC’d.
- Phase 4: Tried `WebFetch` for lore and stable queries; blocked by
  Anubis.
- Phase 4: Ran web searches; found no separate stable discussion or
  independent bug report.
- Phase 5: Verified caller path from USB probe to quirk flag
  initialization and from ALSA PCM prepare/trigger to endpoint start.
- Phase 5: Verified same flag combination already exists for Behringer
  UMC202HD/UMC204HD/UMC404HD.
- Phase 6: Checked `v7.0.5`, `v6.12.75`, `v6.6`, `v6.1`, and `v5.15` for
  relevant flags/context.
- Phase 6: Ran index-only apply checks: applies to `v7.0.5` and
  `v6.12.75`; does not apply as-is to `v6.6`, `v6.1`, or `v5.15`.
- Phase 7: Verified `MAINTAINERS` lists Takashi Iwai as a `SOUND`
  maintainer.
- Phase 8: Failure mode and tested hardware/kernel are verified from the
  patch message; unprivileged triggerability is unverified.

**YES**

 sound/usb/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 148bf7e4e4d72..2ffc69b57ab49 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2401,6 +2401,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_GENERIC_IMPLICIT_FB),
 	DEVICE_FLG(0x2b53, 0x0031, /* Fiero SC-01 (firmware v1.1.0) */
 		   QUIRK_FLAG_GENERIC_IMPLICIT_FB),
+	DEVICE_FLG(0x2b73, 0x0047, /* AlphaTheta EUPHONIA */
+		   QUIRK_FLAG_PLAYBACK_FIRST | QUIRK_FLAG_GENERIC_IMPLICIT_FB),
 	DEVICE_FLG(0x2d95, 0x8011, /* VIVO USB-C HEADSET */
 		   QUIRK_FLAG_CTL_MSG_DELAY_1M),
 	DEVICE_FLG(0x2d95, 0x8021, /* VIVO USB-C-XE710 HEADSET */
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] powerpc/g5: Enable all windfarms by default

[Sasha Levin]

From: Linus Walleij <linusw@kernel.org>

[ Upstream commit 8d57bb61734b23f6342e9de781173f1d83f90d3a ]

The G5 defconfig is clearly intended for the G5 Powermac
series, and that should enable all the available
windfarm drivers, or the machine will overheat a short
while after booting and shut itself down, which is
annoying.

Signed-off-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260505-powermac-g5-config-v3-1-7747bf72f874@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `powerpc/g5`; action verb `Enable`; intent: enable
all existing windfarm thermal drivers in `g5_defconfig`.

Record 1.2: Tags found: `Signed-off-by: Linus Walleij
<linusw@kernel.org>`, `Signed-off-by: Madhavan Srinivasan
<maddy@linux.ibm.com>`, `Link: https://patch.msgid.link/20260505-
powermac-g5-config-v3-1-7747bf72f874@kernel.org`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.

Record 1.3: The body says G5 machines using this defconfig may overheat
shortly after boot and shut down if not all windfarm drivers are
enabled. Root cause: the G5 defconfig enables some, but not all, G5
windfarm thermal control drivers.

Record 1.4: This is a hidden bug fix despite “Enable” wording: it
changes default configuration to include missing existing thermal-
management drivers, preventing hardware overheat shutdown.

## Phase 2: Diff Analysis
Record 2.1: One file changed: `arch/powerpc/configs/g5_defconfig`,
`+2/-0`. No functions modified. Scope: single-file surgical defconfig
fix.

Record 2.2: Before: `g5_defconfig` enabled `WINDFARM_PM81`, `PM91`,
`PM112`, and `PM121`, but omitted `PM72` and `RM31`. After: it also
enables `CONFIG_WINDFARM_PM72=y` and `CONFIG_WINDFARM_RM31=y`.

Record 2.3: Bug category: hardware/default-config correctness fix.
Mechanism: builds in already-existing thermal control drivers for
PowerMac7,2/7,3 and RackMac3,1 systems.

Record 2.4: Fix quality is high: two config lines, no API change, no
code refactor. Regression risk is low because the enabled drivers check
machine compatibility and return `-ENODEV` on nonmatching hardware.

## Phase 3: Git History Investigation
Record 3.1: Blame shows surrounding windfarm entries came from
`2c39bf49fd0530` in 2012, while PM72/RM31 drivers were introduced by
`6cd320996746` and are present from v3.5. Checked v3.5, v3.6, v4.0,
v5.4, v5.10: the defconfig omitted PM72/RM31.

Record 3.2: No `Fixes:` tag, so no Fixes target to follow.

Record 3.3: Recent `g5_defconfig` history is mostly defconfig
maintenance and symbol removals; no prerequisite patch was identified.
The mailed patch is a one-patch series.

Record 3.4: Linus Walleij is an established kernel
maintainer/contributor, though not listed as PowerPC maintainer. The
patch was acked by Michael Ellerman in-thread and applied by Madhavan
Srinivasan, both PowerPC maintainers per `MAINTAINERS`.

Record 3.5: Dependencies are existing Kconfig symbols and are satisfied.
`make ARCH=powerpc g5_defconfig` on the candidate produced
`CONFIG_WINDFARM_PM72=y`, `CONFIG_WINDFARM_RM31=y`, and `CONFIG_I2C=y`.

## Phase 4: Mailing List And External Research
Record 4.1: `b4 am` found the v3 submission and three revisions: v1, v2,
v3. `b4 dig` matched the patch-id and found lore/patch.msgid links.
Direct `WebFetch` to lore was blocked by Anubis, but `b4 mbox`
downloaded the full v3 thread.

Record 4.2: `b4 dig -w` showed the patch was sent to Madhavan
Srinivasan, Michael Ellerman, Nicholas Piggin, Christophe Leroy,
`linuxppc-dev`, and `linux-kernel`.

Record 4.3: No separate bug report link was present. Thread evidence
confirms impact: Segher Boessenkool wrote that affected machines boot
but “won’t run for even a minute”; Linus said Debian likely works by
having the driver in initramfs/rootfs and that built-in is safer.

Record 4.4: Series context: same two-line patch rebased from v1 to v3,
no multi-patch dependency.

Record 4.5: Web search found no stable-list discussion for this exact
patch. No known stable objection found.

## Phase 5: Code Semantic Analysis
Record 5.1: No functions changed. Relevant enabled init functions are
`wf_pm72_init()` and `wf_rm31_init()`.

Record 5.2: These init functions are run at boot/module init when built.
`windfarm_core_init()` registers the `windfarm` platform device.

Record 5.3: `wf_pm72_init()` checks `PowerMac7,2`/`PowerMac7,3`;
`wf_rm31_init()` checks `RackMac3,1`; both register a platform driver
only after compatibility checks.

Record 5.4: Reachability is boot-time on affected hardware using
`g5_defconfig`, not syscall-triggered. The failure mode is hardware
thermal shutdown, not userspace API behavior.

Record 5.5: Similar pattern already exists in the same defconfig for
other G5 windfarm drivers (`PM81`, `PM91`, `PM112`, `PM121`).

## Phase 6: Stable Tree Analysis
Record 6.1: Checked v5.10, v5.15, v6.1, v6.6, v6.12, v6.18, v6.19, and
v7.0 tags: the buggy omission exists and the PM72/RM31 Kconfig symbols
exist.

Record 6.2: Generated patch applied cleanly to all checked tags: v5.10
through v7.0.

Record 6.3: Checked those tags for the exact subject; no related fix
already present.

## Phase 7: Subsystem Context
Record 7.1: Subsystem: PowerPC defconfig / Power Macintosh thermal
management. Criticality: platform-specific but important for affected
hardware because thermal control is required for safe operation.

Record 7.2: `drivers/macintosh` has low-to-moderate activity, mostly
treewide cleanups and small fixes; PowerMac is marked orphan, while
broader PowerPC is supported.

## Phase 8: Impact And Risk
Record 8.1: Affected users: PowerMac G5 AGP systems (`PowerMac7,2`,
`PowerMac7,3`) and Xserve G5 (`RackMac3,1`) using kernels built from
`g5_defconfig`.

Record 8.2: Trigger: booting affected hardware with the default G5
config lacking the built-in thermal driver. Not unprivileged-user-
triggered.

Record 8.3: Failure mode: overheating followed by shutdown shortly after
boot. Severity: CRITICAL for affected hardware availability and hardware
safety.

Record 8.4: Benefit is high for affected stable users; risk is very low:
two defconfig lines, existing drivers, clean applies, machine-specific
init guards.

## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes real hardware thermal
shutdown; two-line contained patch; existing drivers; dependencies
verified; applies cleanly to checked stable tags; maintainer
ack/application in PowerPC fixes. Evidence against: affects only niche
old hardware; no explicit `Cc: stable` or `Tested-by`. No unresolved
technical blockers.

Record 9.2: Stable rules: obviously correct: yes; tested: config
generation verified, no runtime `Tested-by`; real bug: yes; important
issue: yes, overheating/shutdown; small/contained: yes; no new
API/features: yes, only enables existing drivers in defconfig; applies
to stable: yes for checked tags.

Record 9.3: Exception category: closest match is hardware-support/config
fix for existing drivers, not new driver code.

Record 9.4: Decision: backport. This is a small, low-risk default-config
fix for a severe hardware failure mode.

## Verification
- Phase 1: Parsed tags from supplied commit and b4-fetched mbox.
- Phase 2: Verified diff is `+2/-0` in
  `arch/powerpc/configs/g5_defconfig`.
- Phase 3: Used `git blame`, `git log`, and `git show`; found PM72/RM31
  drivers introduced by `6cd320996746`, present since v3.5.
- Phase 4: Used `b4 am`, `b4 dig`, `b4 dig -w`, `b4 mbox`; full thread
  shows Michael Ellerman ack and Madhavan Srinivasan applied it to
  `powerpc/fixes`.
- Phase 5: Read `drivers/macintosh/Kconfig`, `Makefile`,
  `windfarm_pm72.c`, `windfarm_rm31.c`, and `windfarm_core.c`; verified
  machine-specific guards and boot/init path.
- Phase 6: Checked v5.10, v5.15, v6.1, v6.6, v6.12, v6.18, v6.19, v7.0
  for symbol presence and clean patch application.
- Phase 8: Failure mode verified from commit text and mailing-list
  thread; no independent runtime test performed here.

**YES**

 arch/powerpc/configs/g5_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 428f17b455132..2fe8ca266b5f6 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -85,6 +85,8 @@ CONFIG_PMAC_SMU=y
 CONFIG_MAC_EMUMOUSEBTN=y
 CONFIG_WINDFARM=y
 CONFIG_WINDFARM_PM81=y
+CONFIG_WINDFARM_PM72=y
+CONFIG_WINDFARM_RM31=y
 CONFIG_WINDFARM_PM91=y
 CONFIG_WINDFARM_PM112=y
 CONFIG_WINDFARM_PM121=y
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] ALSA: hda/realtek: Add codec SSID quirk for Lenovo Yoga Pro 9 16IMH9

[Sasha Levin]

From: Rámon van Raaij <ramon@vanraaij.eu>

[ Upstream commit 56722cfbb78d7eb41756cd78dc5192d08bd14f3d ]

The Yoga Pro 9 16IMH9 (codec SSID 17aa:38d6) shares PCI audio device
subsystem ID 17aa:3811 with the Legion S7 15IMH05. The existing
SND_PCI_QUIRK entry for the Legion routes both machines to
ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS, which does not bind the TAS2781
smart amplifiers, resulting in near-silent built-in speakers.

Add an HDA_CODEC_QUIRK entry immediately before the conflicting PCI quirk
that matches the Yoga Pro 9's unique codec SSID and routes it to
ALC287_FIXUP_TAS2781_I2C. Codec quirks are evaluated after PCI quirks and
take precedence, leaving the Legion S7 15IMH05 entry unaffected.

This follows the same pattern used to disambiguate PCI SSID 17aa:3847
(shared between Yoga Pro 7 14IMH9 and Legion 7 16ACHG6), where a
HDA_CODEC_QUIRK for codec SSID 17aa:38cf resolves the conflict.

Signed-off-by: Rámon van Raaij <ramon@vanraaij.eu>
Link: https://patch.msgid.link/20260430191224.patch1-ramon@vanraaij.eu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `ALSA: hda/realtek`; action is `Add`;
claimed intent is adding a codec-SSID quirk so Lenovo Yoga Pro 9 16IMH9
uses the TAS2781 fixup instead of the Legion S7 PCI-SSID fixup.

Step 1.2 Record: Tags present are `Signed-off-by: Rámon van Raaij
<ramon@vanraaij.eu>`, `Link:
https://patch.msgid.link/20260430191224.patch1-ramon@vanraaij.eu`, and
`Signed-off-by: Takashi Iwai <tiwai@suse.de>`. No `Fixes:`, `Reported-
by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable@vger.kernel.org` tag is present.

Step 1.3 Record: The commit describes a real hardware misidentification:
Yoga Pro 9 16IMH9 has codec SSID `17aa:38d6` but shares PCI audio SSID
`17aa:3811` with Legion S7 15IMH05, causing
`ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS` to be selected. The stated
symptom is near-silent built-in speakers because TAS2781 smart
amplifiers are not bound.

Step 1.4 Record: This is a bug fix disguised as an “add quirk” change.
It is a hardware-specific workaround for wrong quirk selection, one of
the standard stable exception categories.

### Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `sound/hda/codecs/realtek/alc269.c`,
4 insertions, 0 deletions. No function body is changed; the modified
object is `alc269_fixup_tbl`. Scope is single-file, table-only,
surgical.

Step 2.2 Record: Before, a Yoga Pro 9 16IMH9 with PCI SSID `17aa:3811`
would hit the existing Legion S7 `SND_PCI_QUIRK` and get
`ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS`. After, the earlier
`HDA_CODEC_QUIRK(0x17aa, 0x38d6, ..., ALC287_FIXUP_TAS2781_I2C)` matches
by codec SSID first due table order and routes that machine to the
TAS2781 I2C fixup.

Step 2.3 Record: Bug category is hardware workaround / logic
correctness. The broken mechanism is ambiguous PCI SSID reuse; the fix
uses the more specific codec SSID.

Step 2.4 Record: Fix quality is high. It is a 4-line exact-match quirk,
no API change, no broad behavior change. Regression risk is very low and
limited to devices reporting codec SSID `17aa:38d6`.

### Phase 3: Git History
Step 3.1 Record: `git blame` shows the conflicting
`SND_PCI_QUIRK(0x17aa, 0x3811, "Legion S7 15IMH05", ...)` came from
`67f4c61a73e9b` by Eric Naim. `git describe --contains 67f4c61a73e9b`
reports `v7.1-rc1~166^2~6`; candidate `56722cfbb78d` is contained by
`v7.1-rc3~27^2~13`.

Step 3.2 Record: No `Fixes:` tag is present, so there is no tagged
introducer to follow. Manual blame identifies the relevant prior Legion
quirk.

Step 3.3 Record: Recent file history is mostly audio quirk additions.
Related commit `217d5bc9f9627` adds the same codec-SSID disambiguation
pattern for Yoga Pro 7 14IMH9 versus Legion 7 16ACHG6.

Step 3.4 Record: `git log --author='Rámon van Raaij' ... master --
sound/hda/codecs/realtek/alc269.c` returned no earlier matching commits
in this local history. Maintainer Takashi Iwai committed the patch.

Step 3.5 Record: Dependencies are the existing `HDA_CODEC_QUIRK`
infrastructure, `ALC287_FIXUP_TAS2781_I2C`, and the conflicting Legion
`17aa:3811` entry. All exist in the checked 7.0 tree; `git apply
--check` of the candidate diff against current `HEAD` succeeded.

### Phase 4: Mailing List / External Research
Step 4.1 Record: `b4 dig -c 56722cfbb78d -a` found one revision, v1, at
`https://patch.msgid.link/20260430191224.patch1-ramon@vanraaij.eu`. No
newer revision for this exact patch was found.

Step 4.2 Record: `b4 dig -c 56722cfbb78d -w` shows recipients were Rámon
van Raaij, `linux-sound@vger.kernel.org`, `alsa-devel@alsa-project.org`,
and Takashi Iwai. The maintainer replied “Applied now. Thanks.”

Step 4.3 Record: No separate bug report link or `Reported-by` tag is in
the candidate. Web search found public Yoga Pro 9i/TIAS2781/ALC287 audio
issue reports, but I did not use those as primary evidence for the exact
`17aa:38d6` SSID.

Step 4.4 Record: `b4 mbox -c` showed a later related patch for codec
SSID `17aa:38d5`, referencing this candidate commit and the same
hardware class. It is related context, not a prerequisite.

Step 4.5 Record: Web search for stable-specific discussion of
`56722cfbb78d` did not find a stable-thread result. Lore `WebFetch` was
blocked by anti-bot HTML, but `b4` access succeeded.

### Phase 5: Semantic Code Analysis
Step 5.1 Record: No function is modified. Key affected symbols are
`alc269_fixup_tbl`, `snd_hda_pick_fixup`, `HDA_CODEC_QUIRK`,
`ALC287_FIXUP_TAS2781_I2C`, and `ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS`.

Step 5.2 Record: `alc269_probe()` calls `snd_hda_pick_fixup(codec,
alc269_fixup_models, alc269_fixup_tbl, alc269_fixups)`.
`hda_codec_driver_probe()` calls the codec driver probe op, so this is
reached during HDA codec binding/probe.

Step 5.3 Record: `HDA_CODEC_QUIRK` sets `.match_codec_ssid = true`.
`snd_hda_pick_fixup()` checks such entries against
`codec->core.subsystem_id`; the TAS2781 fixup calls
`comp_generic_fixup(..., "i2c", "TIAS2781", ...)`. The Legion fixup is
HDA verb/coefficient based and does not call the TAS2781 component
binding helper.

Step 5.4 Record: Reachability is hardware probe path: HDA controller
probes codecs, Realtek codec driver probes, `alc269_probe()` picks the
fixup. The bug is not syscall/security-triggered; it affects audio
functionality on matching hardware.

Step 5.5 Record: Similar patterns exist in the same table, especially
`HDA_CODEC_QUIRK(0x17aa, 0x38cf, "Lenovo Yoga Pro 7 14IMH9", ...)`
immediately before a conflicting Legion PCI SSID entry.

### Phase 6: Stable Tree Analysis
Step 6.1 Record: In checked local refs, `HEAD` and `pending-6.18`
contain the conflicting `17aa:3811` Legion quirk and do not contain the
candidate `HDA_CODEC_QUIRK(0x17aa, 0x38d6, ...)`. Older checked pending
refs did not show the conflicting line in the `git grep` run.

Step 6.2 Record: Backport difficulty is clean for current `HEAD`: `git
apply --check` succeeded. For older trees without `HDA_CODEC_QUIRK` or
without the Legion `17aa:3811` quirk, this patch is either not
applicable or would need prerequisites.

Step 6.3 Record: No equivalent `17aa:38d6` codec quirk was found in
checked stable refs. Existing `SND_PCI_QUIRK(0x17aa, 0x38d6, ...)`
entries are PCI-SSID entries and do not fix the reported Yoga Pro 9 case
where the PCI SSID is `17aa:3811`.

### Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is ALSA HDA Realtek codec support under
`sound/hda/codecs/realtek`. Criticality is driver-specific/important for
affected laptop users, not core-kernel-wide.

Step 7.2 Record: The subsystem is actively maintained; recent history
shows many Realtek laptop quirk additions and related fixes. Takashi
Iwai applied the patch.

### Phase 8: Impact / Risk
Step 8.1 Record: Affected population is Lenovo Yoga Pro 9 16IMH9 units
with codec SSID `17aa:38d6` on stable trees containing the Legion
`17aa:3811` quirk.

Step 8.2 Record: Trigger is normal boot/device probe and use of built-in
speakers. It is hardware/config specific, not unprivileged exploitation.

Step 8.3 Record: Failure mode is broken built-in speaker output,
described as near-silent speakers. Severity is high for affected
hardware functionality, though not crash/data-corruption/security
severity.

Step 8.4 Record: Benefit is high for affected laptops and also prevents
a regression caused by the shared PCI SSID quirk. Risk is very low: 4
lines, exact match, no new API, no shared logic changes.

### Phase 9: Synthesis
Step 9.1 Record: Evidence for backporting: real user-visible hardware
breakage, standard stable hardware-quirk category, tiny table-only
patch, maintainer-applied, exact existing pattern, clean apply to
current checked stable tree. Evidence against: no `Tested-by`, no `Cc:
stable`, no separate bug-report link in the commit, and not applicable
to trees lacking the prerequisite Legion quirk or `HDA_CODEC_QUIRK`
infrastructure. Unresolved: I did not independently verify the physical
uniqueness of codec SSID `17aa:38d6` beyond the submitted patch and
maintainer acceptance.

Step 9.2 Record: Stable rules: already upstream/mainline yes; obviously
correct yes by code inspection and `checkpatch`; fixes a real bug yes,
wrong quirk causing near-silent speakers; important enough yes as a
hardware quirk / broken device functionality; small and contained yes, 4
insertions; no new feature/API yes; applies cleanly to current checked
stable `HEAD`, with older-tree applicability depending on prerequisites.

Step 9.3 Record: Exception category applies: hardware quirk/workaround
for a specific laptop audio configuration.

Step 9.4 Record: Decision is YES for stable trees that contain the
conflicting Legion S7 `17aa:3811` quirk and the
`HDA_CODEC_QUIRK`/TAS2781 infrastructure. It should not be forced into
older trees where the buggy conflicting quirk is absent.

## Verification
- [Phase 1] Parsed commit `56722cfbb78d7eb41756cd78dc5192d08bd14f3d`
  with `git show`; confirmed tags and message.
- [Phase 2] Inspected diff: `sound/hda/codecs/realtek/alc269.c`, 4
  insertions.
- [Phase 3] Ran `git blame` around the conflicting quirk; confirmed
  `67f4c61a73e9b` introduced `17aa:3811`.
- [Phase 3] Ran `git show 67f4c61a73e9b`; confirmed it adds the Legion
  S7 quirk.
- [Phase 4] Ran `b4 dig -c 56722cfbb78d -a` and `-w`; found v1
  submission, recipients, and maintainer application.
- [Phase 5] Read `snd_hda_pick_fixup()`, `HDA_CODEC_QUIRK`,
  `alc269_probe()`, TAS2781 fixup, and Legion fixup paths.
- [Phase 6] Ran `git grep` across checked stable refs; found conflict in
  `HEAD` and `pending-6.18`, and no candidate codec quirk there.
- [Phase 6] Ran `git apply --check`; candidate applies to current
  checked `HEAD`.
- [Phase 8] Ran `scripts/checkpatch.pl --no-tree`; 0 errors, 0 warnings.
- UNVERIFIED: No runtime test on Lenovo Yoga Pro 9 16IMH9 hardware; no
  full build performed; exact affected stable branch set beyond checked
  local refs not exhaustively proven because broad branch containment
  checks were too slow and stopped.

**YES**

 sound/hda/codecs/realtek/alc269.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index ded6e78142a07..a55b73ced81d6 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7624,6 +7624,10 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x3801, "Lenovo Yoga9 14IAP7", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
 	HDA_CODEC_QUIRK(0x17aa, 0x3802, "DuetITL 2021", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
 	SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga Pro 9 14IRP8", ALC287_FIXUP_TAS2781_I2C),
+	/* Yoga Pro 9 16IMH9 shares PCI SSID 17aa:3811 with Legion S7 15IMH05;
+	 * use codec SSID to distinguish them
+	 */
+	HDA_CODEC_QUIRK(0x17aa, 0x38d6, "Lenovo Yoga Pro 9 16IMH9", ALC287_FIXUP_TAS2781_I2C),
 	SND_PCI_QUIRK(0x17aa, 0x3811, "Legion S7 15IMH05", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS),
 	SND_PCI_QUIRK(0x17aa, 0x3813, "Legion 7i 15IMHG05", ALC287_FIXUP_LEGION_15IMHG05_SPEAKERS),
 	SND_PCI_QUIRK(0x17aa, 0x3818, "Lenovo C940 / Yoga Duet 7", ALC298_FIXUP_LENOVO_C940_DUET7),
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] tools/ynl: add missing uapi header deps in Makefile.deps

[Sasha Levin]

From: Stanislav Fomichev <sdf.kernel@gmail.com>

[ Upstream commit 46e9b0224475abc739612ef72c35b7c90211a0c1 ]

ethtool.h includes linux/typelimits.h which is a relatively new header
not yet shipped in most distro kernel-header packages. Without the
explicit entry, the build silently falls through to -idirafter.

dev_energymodel.h is a new YNL family whose uapi header is not in
system paths at all and was missing a CFLAGS entry entirely.

Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260508204114.205896-2-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit
`46e9b0224475` `tools/ynl: add missing uapi header deps in
Makefile.deps`

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record 1.1: Subsystem `tools/ynl`; action verb `add`; intent is to add
missing YNL uAPI header dependency entries.

Record 1.2: Tags present: `Signed-off-by: Stanislav Fomichev
<sdf@fomichev.me>`, `Link:
https://patch.msgid.link/20260508204114.205896-2-sdf@fomichev.me`,
`Signed-off-by: Jakub Kicinski <kuba@kernel.org>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by`, `Cc: stable`.

Record 1.3: The described problem is incomplete `Makefile.deps`:
`ethtool.h` includes the newer `linux/typelimits.h`, and
`dev_energymodel.h` has a YNL family/spec but no `CFLAGS_dev-
energymodel` entry. Symptom is YNL tools/header dependency build
correctness with distro kernel headers; no crash/security/data-
corruption symptom is described.

Record 1.4: This is a build/tooling correctness fix, not a hidden
runtime bug fix.

### Phase 2: Diff Analysis
Record 2.1: One file changed: `tools/net/ynl/Makefile.deps`, `+3/-1`. No
functions; Makefile variables only. Scope is single-file surgical.

Record 2.2: Before: `ethtool` force-included `ethtool.h`,
`ethtool_netlink.h`, and generated ethtool netlink headers, but not
`typelimits.h`; `dev-energymodel` had no per-family CFLAGS. After:
`typelimits.h` is explicitly force-included before `ethtool.h`, and
`CFLAGS_dev-energymodel` force-includes `dev_energymodel.h`.

Record 2.3: Bug category is build/tooling dependency correctness. It is
not memory safety, locking, refcounting, or runtime logic.

Record 2.4: Fix quality is high: tiny, declarative Makefile-only change.
Regression risk is low for `v7.0.y`; but not suitable unmodified for
older trees lacking `include/uapi/linux/typelimits.h`.

### Phase 3: Git History
Record 3.1: Blame showed the affected `CFLAGS_ethtool` line came from
`46fb3ba95b93`, later ethtool deps from `0bdcfaf84a942`; `get_hdr_inc2`
came from `db6b35cffe59`.

Record 3.2: No `Fixes:` tag, so no target commit to follow.

Record 3.3: Related history includes prior YNL old-header/build fixes:
`db6b35cffe59 tools: ynl: fix build on systems with old kernel headers`,
`0bdcfaf84a942 tools: ynl: add all headers to makefile deps`, and
several YNL family additions.

Record 3.4: Author Stanislav Fomichev has related net/YNL commits; Jakub
Kicinski committed it and is a netdev maintainer.

Record 3.5: Dependency check: `dev_energymodel.h` and `dev-
energymodel.yaml` exist in `v6.19+`; `typelimits.h` and the ethtool
include of it exist in `v7.0+`. The full patch is therefore appropriate
as-is for `v7.0.y`, not for `v6.19.y`.

### Phase 4: Mailing List
Record 4.1: `b4 dig` found the original submission at the provided patch
link. It was `[PATCH net-next 1/2]`.

Record 4.2: `b4 dig -w` showed netdev maintainers/lists were included:
`netdev`, `davem`, `edumazet`, `kuba`, `pabeni`, Donald Hunter, Simon
Horman, and `linux-kernel`.

Record 4.3: No separate bug report, syzbot report, or user crash report
was found. WebFetch of the patch URL was blocked by Anubis, but `b4`
retrieved the lore thread.

Record 4.4: It was part of a 2-patch series. Patch 1 was applied to
`netdev/net.git`; patch 2, the check-deps target, was not applied.
Jakub’s concern was about patch 2 being better as a NIPA check, not
about patch 1.

Record 4.5: No stable-specific discussion or stable nomination found.

### Phase 5: Code Semantic Analysis
Record 5.1: No C functions modified; key Makefile variables are
`CFLAGS_ethtool` and new `CFLAGS_dev-energymodel`.

Record 5.2: `tools/net/ynl/generated/Makefile` uses `$(CFLAGS_$*)` when
compiling `%-user.o`; dry-run confirmed `ethtool-user.o` and `dev-
energymodel-user.o` are affected.

Record 5.3: The YNL generator uses each spec’s `uapi-header`; `dev-
energymodel.yaml` declares `uapi-header: linux/dev_energymodel.h`.

Record 5.4: This is reachable through building generated YNL userspace
protocol objects, not through runtime kernel execution or syscalls.

Record 5.5: Similar pattern exists throughout `Makefile.deps`: YNL
families have explicit `CFLAGS_<family>` entries to force the in-tree
uAPI header and avoid stale/missing system headers.

### Phase 6: Stable Tree Analysis
Record 6.1: `v7.0`/`v7.0.9` contain both prerequisites:
`dev_energymodel.h`, `dev-energymodel.yaml`, `typelimits.h`, and
`ethtool.h` including `typelimits.h`. Older checked tags before `v6.19`
do not contain the dev-energymodel pieces; `v6.19` lacks `typelimits.h`.

Record 6.2: Patch applies cleanly to current `7.0.y` workspace. Backport
difficulty for `v7.0.y`: clean. For `v6.19.y`: needs adjustment or
should not take the `typelimits` hunk.

Record 6.3: No equivalent related fix was found already in
`stable/linux-7.0.y`.

### Phase 7: Subsystem Context
Record 7.1: Subsystem is `tools/net/ynl`, userspace tooling for netlink
YAML-generated helpers. Criticality is peripheral to kernel runtime but
relevant to building kernel tools.

Record 7.2: Subsystem is active; recent history shows several generated
YNL family and Makefile dependency changes.

### Phase 8: Impact And Risk
Record 8.1: Affected users are developers/distributions/build systems
building `tools/net/ynl/generated`, especially with distro kernel-header
packages that lack newer headers.

Record 8.2: Trigger is building generated YNL objects for `ethtool` or
`dev-energymodel`. No unprivileged runtime trigger.

Record 8.3: Failure mode is build/tooling header dependency
inconsistency, not kernel crash or data corruption. Severity: medium as
a tools build fix.

Record 8.4: Benefit is moderate for `v7.0.y` build correctness; risk is
very low because this is a tiny Makefile-only dependency addition. Risk
rises only if applied blindly to older trees missing `typelimits.h`.

### Phase 9: Final Synthesis
Evidence for backporting: small contained build fix; applies cleanly to
`v7.0.y`; fixes incomplete YNL uAPI dependency declarations; netdev
maintainer applied patch 1; no runtime behavior or API change.

Evidence against: no crash/security/data-corruption issue; no stable
nomination; not appropriate unmodified for all older stable trees.

Stable rules: obviously correct yes; fixes a real build/tooling
dependency issue yes; important enough under build-fix exception for
`v7.0.y` yes; small/contained yes; no new API/feature yes; applies to
`v7.0.y` yes.

## Verification
- [Phase 1] `git show 46e9b0224475` verified subject, body, tags,
  author, committer, and `+3/-1` diff.
- [Phase 2] Diff verified only `tools/net/ynl/Makefile.deps` changes.
- [Phase 3] `git blame` and `git log` verified changed-line history and
  related YNL dependency fixes.
- [Phase 4] `b4 dig`, `b4 dig -a`, `b4 dig -w`, and saved mbox verified
  original lore thread, recipients, one revision, and patch 1
  application.
- [Phase 5] `rg`, `git grep`, `ReadFile`, and `make -n` verified how
  `CFLAGS_$*` reaches generated object builds.
- [Phase 6] Tag/ref checks verified affected code in `v7.0.y`; `git
  apply --check` verified clean application to current tree.
- [Phase 8] No runtime reachability was found; impact is limited to
  tools build/header dependency behavior.

Backport this to `v7.0.y`; avoid applying it unmodified to older stable
trees that lack `typelimits.h`.

**YES**

 tools/net/ynl/Makefile.deps | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/net/ynl/Makefile.deps b/tools/net/ynl/Makefile.deps
index 08205f9fc5257..cc53b2f21c444 100644
--- a/tools/net/ynl/Makefile.deps
+++ b/tools/net/ynl/Makefile.deps
@@ -15,9 +15,11 @@ UAPI_PATH:=../../../../include/uapi/
 get_hdr_inc=-D$(1) -include $(UAPI_PATH)/linux/$(2)
 get_hdr_inc2=-D$(1) -D$(2) -include $(UAPI_PATH)/linux/$(3)
 
+CFLAGS_dev-energymodel:=$(call get_hdr_inc,_LINUX_DEV_ENERGYMODEL_H,dev_energymodel.h)
 CFLAGS_devlink:=$(call get_hdr_inc,_LINUX_DEVLINK_H_,devlink.h)
 CFLAGS_dpll:=$(call get_hdr_inc,_LINUX_DPLL_H,dpll.h)
-CFLAGS_ethtool:=$(call get_hdr_inc,_LINUX_ETHTOOL_H,ethtool.h) \
+CFLAGS_ethtool:=$(call get_hdr_inc,_LINUX_TYPELIMITS_H,typelimits.h) \
+	$(call get_hdr_inc,_LINUX_ETHTOOL_H,ethtool.h) \
 	$(call get_hdr_inc,_LINUX_ETHTOOL_NETLINK_H_,ethtool_netlink.h) \
 	$(call get_hdr_inc,_LINUX_ETHTOOL_NETLINK_GENERATED_H,ethtool_netlink_generated.h)
 CFLAGS_handshake:=$(call get_hdr_inc,_LINUX_HANDSHAKE_H,handshake.h)
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] fbdev: ipu-v3: clean up kernel-doc warnings

[Sasha Levin]

From: Randy Dunlap <rdunlap@infradead.org>

[ Upstream commit f1fb23a0a0fcbdb66672da51d7d63a259f6396ca ]

Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values

Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
 described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
 'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
 ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
 return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
 return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
 return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
 return value of 'ipu_image_convert'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `fbdev: ipu-v3`; action verb `clean up`;
intent is to correct kernel-doc warnings in `include/video/imx-ipu-
image-convert.h`.

Step 1.2 Record: tags in committed message are `Signed-off-by: Randy
Dunlap <rdunlap@infradead.org>`, `Reviewed-by: Philipp Zabel
<p.zabel@pengutronix.de>`, and `Signed-off-by: Helge Deller
<deller@gmx.de>`. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-
by:`, `Link:`, or `Cc: stable@vger.kernel.org` tag is present in the
committed message.

Step 1.3 Record: the described problem is seven kernel-doc warnings: one
undocumented/private list member, malformed typedef documentation, and
missing `Returns:` sections. The visible symptom is documentation
tooling warnings, not a runtime crash, hang, data corruption, or
security issue. No affected kernel version is stated. Root cause is
incorrect kernel-doc comment syntax.

Step 1.4 Record: this is not a hidden runtime bug fix. The body and diff
both show a documentation/comment-only cleanup.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `include/video/imx-ipu-image-
convert.h`, 11 insertions and 5 deletions. Modified documentation covers
`struct ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`. Scope is single-
file, header-only, surgical.

Step 2.2 Record: hunk behavior:
- `struct ipu_image_convert_run`: before, `list` was documented neither
  as a member nor private; after, `/* private: */` tells kernel-doc to
  ignore it as an API member.
- `ipu_image_convert_cb_t`: before, kernel-doc treated the typedef
  comment as a function prototype mismatch; after, it is marked as a
  typedef comment.
- Return docs: before, several returns were plain prose or missing;
  after, they use kernel-doc `Returns:` syntax.
- `ipu_image_convert_prepare()`: before, the V4L2 usage note followed
  the return prose; after, the return section is last and formatted for
  kernel-doc.

Step 2.3 Record: bug category is documentation/kernel-doc warning
cleanup. No error-path, synchronization, refcount, memory-safety,
initialization, type, logic, or hardware workaround change exists.

Step 2.4 Record: fix quality is high for the stated documentation issue:
small, obviously correct kernel-doc syntax changes. Runtime regression
risk is effectively zero because no C declarations, types, function
bodies, data layout, or APIs are changed. Documentation rendering risk
is very low.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the affected header comments and
declarations came from `cd98e85a6b786d` by Steve Longerbeam, dated
2016-09-17. `git describe --contains cd98e85a6b786d` reports it as
present by `v4.9-rc1~41^2~24^2`.

Step 3.2 Record: no `Fixes:` tag is present, so there is no tagged
introducing commit to follow. Blame identifies `cd98e85a6b786d` as the
source of the documented preimage; `git show` confirms that commit added
queued IPU image conversion support and the API documentation.

Step 3.3 Record: recent local history for the file shows `96e9d754b35e8`
removing unused `ipu_image_convert_*` functions, `c942fddf8793b` adding
SPDX boilerplate conversion, and `cd98e85a6b786d` adding the header/API.
No prerequisite commit is needed for this documentation-only patch.

Step 3.4 Record: `git log --author='Randy Dunlap'` under fbdev/include
areas shows Randy has related cleanup/documentation work such as `fbdev:
hgafb: fix kernel-doc comments` and `fbdev: fbmon: fix function name in
kernel-doc`. The patch was reviewed by Philipp Zabel and committed by
Helge Deller, verified from the commit and lore thread.

Step 3.5 Record: no dependencies found. The diff changes only comments
and applies locally with `git apply --check`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`
failed to find a lore match by patch-id, author/subject, or in-body
From. External fetch found the v3 discussion at
`https://yhbt.net/lore/dri-
devel/20260427183236.656902-1-rdunlap@infradead.org/T/`. The v3 thread
has Helge Deller replying “applied to fbdev git tree.” Web search/fetch
also found v2 and a v2 ping. No NAKs or objections were found.

Step 4.2 Record: `b4 dig -w` also failed for the same reason. The v3
lore mirror shows recipients included `dri-devel`, Philipp Zabel, DRM
maintainers, `imx`, `linux-arm-kernel`, Helge Deller, and `linux-fbdev`.

Step 4.3 Record: no `Reported-by:` or bug-report `Link:` tags exist. No
external crash/security bug report applies.

Step 4.4 Record: this is a standalone one-patch documentation cleanup.
v2 added the reviewed-by and updated Cc list; v3 rebased and resent.

Step 4.5 Record: direct `lore.kernel.org/stable` fetch was blocked by
Anubis. Web search for the exact subject plus `stable` found patch-
thread results but no stable-specific discussion or stable nomination.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified documented symbols are
`ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`.

Step 5.2 Record: `rg` found callers in `drivers/staging/media/imx/imx-
media-csc-scaler.c` for `ipu_image_convert_abort()`,
`ipu_image_convert_queue()`, `ipu_image_convert_adjust()`,
`ipu_image_convert_unprepare()`, and `ipu_image_convert_prepare()`.
Runtime callers are unaffected because only comments changed.

Step 5.3 Record: reading `drivers/gpu/ipu-v3/ipu-image-convert.c`
confirms the documented functions perform image format
adjustment/verification, context allocation, queueing, abort/unprepare,
and single conversion setup. None of those function bodies are touched.

Step 5.4 Record: runtime path is reachable through IPU image conversion
users, but the patch changes no runtime path. The affected path for the
fix is kernel-doc/documentation generation.

Step 5.5 Record: no related same-header kernel-doc fix was found by `git
log --grep='kernel-doc' -- include/video/imx-ipu-image-convert.h`.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: version tags `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.15`, `v6.16`, and `v6.17` all contain `include/video/imx-ipu-image-
convert.h` with the old kernel-doc text. The API was introduced before
`v4.9-rc1`, so active stable trees checked contain the documentation
issue.

Step 6.2 Record: expected backport difficulty is clean or minor. `git
apply --check` succeeds against the current local tree, and the checked
stable tags contain representative preimage lines. Full per-stable
worktree application was not run.

Step 6.3 Record: no related stable fix for this header was found in
local `git log --grep` searches.

## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is fbdev/gpu IPU-v3 image conversion
documentation in an include header. Runtime criticality is
peripheral/driver-specific; documentation-build criticality is low.

Step 7.2 Record: local subsystem history shows ongoing cleanup/removal
activity in `drivers/gpu/ipu-v3` and the header, including unused-
function removals and treewide cleanup. This patch is not part of a
required functional series.

## Phase 8: Impact And Risk
Step 8.1 Record: affected population is kernel documentation builders,
maintainers, and users consuming generated kernel-doc. Runtime users of
IPU-v3 are not affected by behavior.

Step 8.2 Record: trigger is running kernel-doc/documentation tooling
over this header. It is not triggered by boot, device probe, syscalls,
or ordinary runtime use. Unprivileged runtime trigger does not apply.

Step 8.3 Record: failure mode is documentation warnings only. Severity
is LOW. I did not verify any configuration where these warnings are
fatal, so that does not drive the decision.

Step 8.4 Record: benefit is low but real under the documentation-fix
exception: it makes stable documentation builds cleaner. Risk is
extremely low because only comments change. Risk/benefit is favorable if
stable accepts documentation corrections.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: pure documentation
correction, explicitly fixes listed kernel-doc warnings, tiny single-
file patch, reviewed by Philipp Zabel, applied by Helge Deller, old text
exists in active stable tags checked, and documentation/comment fixes
are an allowed stable exception. Evidence against: no runtime bug, no
crash/security/data-corruption impact, no stable nomination found, and
b4 could not match the thread. Unresolved: direct stable-lore search was
blocked; full apply checks on every stable branch were not run.

Step 9.2 Record:
1. Obviously correct and tested? Mostly yes for documentation syntax;
   reviewed and applied, but no `Tested-by`.
2. Fixes a real bug that affects users? Yes, a real kernel-doc warning
   issue; not a runtime bug.
3. Important issue? No runtime severity; LOW documentation-build
   severity.
4. Small and contained? Yes, 11 additions and 5 deletions in one header.
5. No new features or APIs? Yes, comments only.
6. Can apply to stable trees? Likely yes; local apply check passed and
   stable tags checked contain the preimage.

Step 9.3 Record: exception category applies: documentation/comment fix.
This is the main reason to accept despite lack of runtime impact.

Step 9.4 Decision: backporting is appropriate under the stable
documentation-fix exception. It is not a stability/security fix, but it
is a correct, reviewed, zero-runtime-risk cleanup of real kernel-doc
warnings in code present across active stable trees.

## Verification
- Phase 1: fetched and inspected committed metadata for
  `f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`; confirmed tags and
  message.
- Phase 2: `git show --stat --patch` confirmed one header, 11
  insertions, 5 deletions, comments only.
- Phase 3: `git blame` confirmed changed comment preimage from
  `cd98e85a6b786d`; `git describe --contains` placed it before
  `v4.9-rc1`; `git show cd98e85a6b786d` confirmed original API addition.
- Phase 3: `git log` on the header/subsystem found no prerequisite
  functional series.
- Phase 4: `b4 dig`, `b4 dig -a`, and `b4 dig -w` all failed to match;
  recorded as a tool limitation/failure.
- Phase 4: WebFetch of the v3 lore mirror confirmed the patch thread and
  Helge Deller’s applied reply; Spinics fetch confirmed v2 and a later
  ping.
- Phase 5: `rg` found runtime users; `ReadFile` of implementation
  confirmed function bodies exist but are not changed.
- Phase 6: tag checks confirmed the header and old doc text in `v5.10`,
  `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.15`, `v6.16`, and `v6.17`; `git
  apply --check` succeeded locally.
- Phase 8: severity/risk assessment is derived from the verified
  comments-only diff.
- UNVERIFIED: direct `lore.kernel.org/stable` search content was blocked
  by Anubis; no actual `make htmldocs` run was performed; full patch
  application against every individual stable branch was not performed.

**YES**

 include/video/imx-ipu-image-convert.h | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/include/video/imx-ipu-image-convert.h b/include/video/imx-ipu-image-convert.h
index 003b3927ede5c..6b77968a6a150 100644
--- a/include/video/imx-ipu-image-convert.h
+++ b/include/video/imx-ipu-image-convert.h
@@ -27,12 +27,13 @@ struct ipu_image_convert_run {
 
 	int status;
 
+	/* private: */
 	/* internal to image converter, callers don't touch */
 	struct list_head list;
 };
 
 /**
- * ipu_image_convert_cb_t - conversion callback function prototype
+ * typedef ipu_image_convert_cb_t - conversion callback function prototype
  *
  * @run:	the completed conversion run pointer
  * @ctx:	a private context pointer for the callback
@@ -60,7 +61,7 @@ void ipu_image_convert_adjust(struct ipu_image *in, struct ipu_image *out,
  * @out:	output image format
  * @rot_mode:	rotation mode
  *
- * Returns 0 if the formats and rotation mode meet IPU restrictions,
+ * Returns: 0 if the formats and rotation mode meet IPU restrictions,
  * -EINVAL otherwise.
  */
 int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
@@ -77,11 +78,11 @@ int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
  * @complete:	run completion callback
  * @complete_context:	a context pointer for the completion callback
  *
- * Returns an opaque conversion context pointer on success, error pointer
+ * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
+ *
+ * Returns: an opaque conversion context pointer on success, error pointer
  * on failure. The input/output formats and rotation mode must already meet
  * IPU retrictions.
- *
- * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
  */
 struct ipu_image_convert_ctx *
 ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
@@ -122,6 +123,8 @@ void ipu_image_convert_unprepare(struct ipu_image_convert_ctx *ctx);
  * In V4L2, drivers should call ipu_image_convert_queue() while
  * streaming to queue the conversion of a received input buffer.
  * For example mem2mem devices this would be called in .device_run.
+ *
+ * Returns: 0 on success or -errno on error.
  */
 int ipu_image_convert_queue(struct ipu_image_convert_run *run);
 
@@ -155,6 +158,9 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx);
  * On successful return the caller can queue more run requests if needed, using
  * the prepared context in run->ctx. The caller is responsible for unpreparing
  * the context when no more conversion requests are needed.
+ *
+ * Returns: pointer to the created &struct ipu_image_convert_run that has
+ * been queued on success; an ERR_PTR(errno) on error.
  */
 struct ipu_image_convert_run *
 ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] ASoC: amd: yc: Add DMI quirk for MSI Bravo 15 C7VE

[Sasha Levin]

From: Bob Song <songxiebing@kylinos.cn>

[ Upstream commit 0e60d96616640ffcf51b81a87c71e30d92385a93 ]

The laptop requires a quirk ID to enable its internal microphone. Add
it to the DMI quirk table.

Reported-by: gannovera <gannovera@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218402
Signed-off-by: Bob Song <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260430014920.141276-1-songxiebing@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Stable Backport Review

### Phase 1: Commit Message Forensics
Record 1.1: Subsystem is `ASoC: amd: yc`; action verb is `Add`; claimed
intent is adding a DMI quirk for MSI Bravo 15 C7VE internal microphone
enablement.

Record 1.2: Tags found: `Reported-by: gannovera <gannovera@gmail.com>`,
`Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218402`, `Signed-
off-by: Bob Song <songxiebing@kylinos.cn>`, `Link: https://patch.msgid.l
ink/20260430014920.141276-1-songxiebing@kylinos.cn`, `Signed-off-by:
Mark Brown <broonie@kernel.org>`. No `Fixes:` tag and no explicit `Cc:
stable`.

Record 1.3: The message states the laptop requires a quirk ID to enable
its internal microphone. Symptom is missing internal microphone support
on MSI Bravo 15 C7VE. Version info is not stated. Root cause described
is absence from `yc_acp_quirk_table`.

Record 1.4: This is a hardware quirk fix, not a hidden cleanup bug. It
fits the stable exception category for DMI quirks/workarounds.

### Phase 2: Diff Analysis
Record 2.1: One file changed: `sound/soc/amd/yc/acp6x-mach.c`, 7
insertions, 0 deletions. Modified object is the static
`yc_acp_quirk_table[]`. Scope is a single-file surgical quirk addition.

Record 2.2: Before: the DMI table matched nearby MSI models such as
`Bravo 15 B7ED` and `Bravo 15 C7VF`, but not `Bravo 15 C7VE`. After:
exact vendor/product match for `Micro-Star International Co., Ltd.` and
`Bravo 15 C7VE` maps to `&acp6x_card`. Affected path is platform probe
hardware matching.

Record 2.3: Bug category is hardware workaround / DMI quirk. Mechanism:
`acp6x_probe()` calls `dmi_first_match(yc_acp_quirk_table)` and, on
match, sets platform driver data to `acp6x_card`; without a match, the
driver can return `-ENODEV` if ACPI did not already enable the card.

Record 2.4: Fix quality is high: it adds only one exact DMI table entry
using an existing pattern and no new logic. Regression risk is very low
and limited to machines reporting that exact DMI product/vendor pair.

### Phase 3: Git History Investigation
Record 3.1: `git blame` around adjacent MSI entries in the checked-out
7.0 tree traced those lines to the local merge base, not a useful
original introducer. The “bug” is absence of this model entry, not a bad
line introduced by a known commit. Verified file absent in `v5.15` and
present in `v5.16`, `v6.1`, `v6.6`, and `v6.12`.

Record 3.2: No `Fixes:` tag, so no introducing commit to follow.

Record 3.3: Recent history of `sound/soc/amd/yc/acp6x-mach.c` contains
many similar DMI quirk additions, including HP, ASUS, MSI Thin/Vector
entries. No prerequisite refactor was identified for this specific
7-line addition.

Record 3.4: Author history in the fetched maintainer branch showed Bob
Song’s related commits for this path consist of this patch. The patch
was committed by Mark Brown, the ASoC maintainer.

Record 3.5: Dependency check found the needed symbols and structure
already exist in stable-relevant trees: `yc_acp_quirk_table`,
`acp6x_card`, and `dmi_first_match()` are present in `v6.1`;
`SND_SOC_AMD_YC_MACH` exists in `v6.1` and `v6.6`. The exact submitted
hunk applies cleanly to the current 7.0 tree; older trees such as `v6.1`
lack the nearby MSI `Bravo 15 B7ED` anchor and would need a simple
context adjustment.

### Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c 0e60d96616640ffcf51b81a87c71e30d92385a93` found
the lore thread at `https://patch.msgid.link/20260430014920.141276-1-
songxiebing@kylinos.cn`. `b4 dig -a` found two same-subject submissions
dated 2026-04-22 and 2026-04-30; the April 30 version is the applied
one.

Record 4.2: `b4 dig -w` showed the April 30 submission included Takashi
Iwai, Jaroslav Kysela, Liam Girdwood, Mark Brown, Vijendar Mukunda,
`linux-sound`, `linux-kernel`, and the reporter.

Record 4.3: Direct `WebFetch` of Bugzilla was blocked by Anubis. Search
results and the lore thread corroborate that Bugzilla #218402 is tied to
this MSI Bravo 15 C7VE microphone issue.

Record 4.4: Related pattern found: a similar MSI Bravo 17 C7VE quirk
thread describes the same ACP6x DMIC not-enabled problem on a related
MSI model. No dependency between that patch and this one was found.

Record 4.5: Stable-list search found no stable-specific discussion for
`Bravo 15 C7VE`.

### Phase 5: Code Semantic Analysis
Record 5.1: Modified object is `yc_acp_quirk_table[]`; key consuming
function is `acp6x_probe()`.

Record 5.2: `acp6x_probe()` is the `.probe` callback of platform driver
`acp6x_mach_driver`. The platform device named `acp_yc_mach` is
registered by `snd_acp6x_probe()` in `pci-acp6x.c` when ACP6x PDM mode
is set.

Record 5.3: Key callees in `acp6x_probe()` are ACPI property checks,
`_WOV` evaluation, `dmi_first_match()`, `platform_set_drvdata()`,
`platform_get_drvdata()`, and `devm_snd_soc_register_card()`.

Record 5.4: Reachability is hardware enumeration/probe on AMD Yellow
Carp ACP systems, not a syscall-triggered path. For the affected laptop,
the issue is encountered at boot/device probe when the internal DMIC
card is not registered.

Record 5.5: Similar pattern is widespread in the same table: many
laptop-specific entries all set `.driver_data = &acp6x_card`.

### Phase 6: Stable Tree Analysis
Record 6.1: `v5.15` lacks `sound/soc/amd/yc/acp6x-mach.c`; `v5.16`,
`v6.1`, `v6.6`, and `v6.12` contain it. This is relevant to stable trees
with the AMD YC machine driver, especially `v6.1+`.

Record 6.2: Current 7.0 tree accepts the patch cleanly via `git apply
--check`. `v6.6`, `v6.12`, `v6.18`, `v6.19`, and HEAD have nearby MSI
entries; `v6.1` has the quirk machinery but not the same adjacent MSI
context, so it needs minor manual placement.

Record 6.3: Searches found no existing `Bravo 15 C7VE` entry in current
HEAD, `v6.6`, `v6.12`, `v6.18`, or `v6.19`.

### Phase 7: Subsystem Context
Record 7.1: Subsystem is ALSA SoC / AMD YC machine driver under
`sound/`. Criticality is peripheral but user-visible: it affects audio
capture on a specific laptop model.

Record 7.2: The subsystem/file is actively receiving DMI quirk
additions, verified by recent history listing multiple ASoC AMD YC quirk
commits.

### Phase 8: Impact And Risk
Record 8.1: Affected users are MSI Bravo 15 C7VE owners using kernels
with `CONFIG_SND_SOC_AMD_YC_MACH`.

Record 8.2: Trigger condition is device probing on that hardware when
firmware/ACPI does not otherwise enable the DMIC path. It is not an
unprivileged-user-triggered security issue.

Record 8.3: Failure mode is loss of internal microphone functionality,
not crash, data corruption, or security impact. Severity is medium for
affected users.

Record 8.4: Benefit is high for affected hardware because it restores
the internal microphone. Risk is very low because the patch is seven
lines, exact-DMI-scoped, and uses existing driver data.

### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: real user report, Bugzilla closure
tag, accepted by ASoC maintainer, exact hardware quirk, tiny scope, no
API/behavior change outside the matching laptop, and stable rules
explicitly allow hardware quirks. Evidence against: no explicit `Cc:
stable`, no `Tested-by`, Bugzilla direct fetch blocked, and `v6.1` needs
trivial context adjustment. None of these outweigh the quirk benefit.

Record 9.2: Stable rules: obviously correct yes; fixes a real user-
visible hardware bug yes; important enough for affected users yes,
though not crash-level; small and contained yes; no new APIs/features
yes; applies cleanly to current 7.0 and should be straightforward for
stable trees containing the driver.

Record 9.3: Exception category applies: hardware-specific DMI
quirk/workaround in an existing driver.

Record 9.4: Decision is to backport to stable trees that contain the AMD
YC machine driver, with minor context adjustment where needed.

## Verification
- [Phase 1] Parsed fetched commit
  `0e60d96616640ffcf51b81a87c71e30d92385a93`: confirmed subject, tags,
  author, committer, and 7-line stat.
- [Phase 2] Read `sound/soc/amd/yc/acp6x-mach.c`: confirmed
  `yc_acp_quirk_table[]` and `acp6x_probe()` DMI behavior.
- [Phase 3] Ran local history/blame checks: nearby blame was not useful
  for original introduction; verified file absent in `v5.15` and present
  in `v5.16+`.
- [Phase 4] Ran `b4 dig -c`, `-a`, `-w`, and saved/read mbox: confirmed
  lore thread, two submissions, maintainer recipients, and Mark Brown
  application to `for-7.1`.
- [Phase 5] Read `pci-acp6x.c`: confirmed PCI probe registers
  `acp_yc_mach`, which invokes the machine driver probe.
- [Phase 6] Checked stable tags and entries: no `Bravo 15 C7VE` in
  checked stable/current trees; patch applies cleanly to current 7.0
  tree.
- [Phase 7] Checked Kconfig/Makefile: confirmed `SND_SOC_AMD_YC_MACH` is
  the relevant config and exists in `v6.1`/`v6.6`.
- [Phase 8] Impact assessment is based on verified probe flow plus the
  commit’s reported Bugzilla/user report.
- UNVERIFIED: Direct Bugzilla contents could not be fetched due Anubis.
  Exact original file introduction commit was not determined from local
  history, but tag presence verifies stable relevance.

**YES**

 sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index 2f7a51d7eb115..daa6b9a526565 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -479,6 +479,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "Bravo 15 B7ED"),
 		}
 	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "Micro-Star International Co., Ltd."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Bravo 15 C7VE"),
+		}
+	},
 	{
 		.driver_data = &acp6x_card,
 		.matches = {
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] powerpc/pasemi: Drop redundant res assignment

[Sasha Levin]

From: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

[ Upstream commit f583bd5f64d40e083dde5bb22846c4d93e59d471 ]

Return value of pas_add_bridge() is not used, so code can be simplified
to fix W=1 clang warnings:

  arch/powerpc/platforms/pasemi/pci.c:275:6: error: variable 'res' set but not used [-Werror,-Wunused-but-set-variable]

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260317130823.240279-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record 1.1: Subsystem `powerpc/pasemi`; action verb `Drop`; intent is to
remove an unused local variable assignment in PA Semi PCI init.

Record 1.2: Tags found: `Signed-off-by: Krzysztof Kozlowski`, `Signed-
off-by: Madhavan Srinivasan`, `Link: https://patch.msgid.link/2026031713
0823.240279-4-krzysztof.kozlowski@oss.qualcomm.com`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.

Record 1.3: The commit explicitly describes a Clang `W=1` build warning
promoted to an error: `variable 'res' set but not used
[-Werror,-Wunused-but-set-variable]`. No runtime symptom, crash, data
corruption, or user-visible functional failure is described.

Record 1.4: This is not a hidden runtime bug fix. It is a build-warning
cleanup that can matter when building powerpc with warning-as-error
settings.

### Phase 2: Diff Analysis
Record 2.1: One file changed: `arch/powerpc/platforms/pasemi/pci.c`, `1
insertion(+), 2 deletions(-)`. Only `pas_pci_init()` is modified. Scope
is single-file surgical.

Record 2.2: Before: `pas_pci_init()` declared `int res;` and assigned
`res = pas_add_bridge(np);`, then never read `res`. After: it still
calls `pas_add_bridge(np);` but does not assign the return value. The
execution path and side effects are unchanged.

Record 2.3: Bug category: build warning/build error under specific
compiler options. Mechanism: remove unused-but-set variable. No resource
lifetime, locking, memory safety, reference counting, or logic behavior
changes.

Record 2.4: Fix quality is obviously correct by inspection: the function
call remains, only the unused local storage is removed. Regression risk
is very low because runtime behavior is unchanged.

### Phase 3: Git History Investigation
Record 3.1: `git blame` on current stable code shows the exact changed
lines are present in the checked-out stable tree. Deeper history shows
the unused `res` assignment was introduced by `250a93501d626`
(`powerpc/pasemi: Search for PCI root bus by compatible property`),
first described by `git describe` as `v4.19-rc1~110^2~83`.

Record 3.2: No `Fixes:` tag is present. Manual history identified
`250a93501d626` as the introducing commit for the exact unused
assignment pattern.

Record 3.3: Recent file history shows only the candidate commit and
unrelated treewide allocation changes in `next-20260508`; no
prerequisite pasemi PCI refactor was found.

Record 3.4: The author has other powerpc cleanup commits nearby,
including the sibling PS3 warning fix. `MAINTAINERS` identifies Madhavan
Srinivasan and Michael Ellerman as powerpc maintainers; Madhavan
committed this patch.

Record 3.5: The sibling commit `8333e4916040e` is part of the same
cleanup series but is independent. This pasemi patch applies standalone
to the current 7.0.5 checkout.

### Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c f583bd5f64d40` found the original submission by
patch-id. It found the January submission and the March resend
corresponding to the commit `Link:`. Direct WebFetch to
lore/patch.msgid.link was blocked by Anubis.

Record 4.2: `b4 dig -w` showed appropriate powerpc maintainers and
LLVM/compiler-warning stakeholders were copied: Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy, Nathan Chancellor,
LLVM list, linuxppc-dev, and others.

Record 4.3: No bug report link or reporter tag exists. The thread
describes a compiler warning/build-cleanliness issue, not a runtime bug
report.

Record 4.4: The patch is part of a two-patch series with `powerpc/ps3:
Drop redundant result assignment`; the other patch is the same class of
cleanup and is not a dependency.

Record 4.5: The downloaded thread contains no `stable` mention. A direct
lore stable search was attempted but blocked by Anubis, so no stable-
list archive result could be independently verified.

### Phase 5: Code Semantic Analysis
Record 5.1: Modified function: `pas_pci_init()`.

Record 5.2: Callers: `pas_pci_init()` is assigned to `.discover_phbs` in
the PA Semi machine descriptor in
`arch/powerpc/platforms/pasemi/setup.c`. `pas_add_bridge()` is static
and, in `next-20260508`, is called only from `pas_pci_init()`.

Record 5.3: Relevant callees in the affected path include
`pci_set_flags()`, `of_find_compatible_node()`, `pas_add_bridge()`, and
`of_node_put()`. `pas_add_bridge()` allocates/configures the PCI
controller and scans OF ranges/ISA bridge state.

Record 5.4: Reachability is boot-time/platform-init only for PA Semi
systems. It is not syscall-reachable and has no unprivileged runtime
trigger.

Record 5.5: Similar pattern found: sibling commit `8333e4916040e`
removes an unused assignment in PS3 platform code for the same warning
class.

### Phase 6: Stable Tree Analysis
Record 6.1: The exact unused `res = pas_add_bridge(np);` pattern exists
in verified tags `v4.19`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.17`, `v6.18`, `v6.19`, and `v7.0`. It was not present in the same
form in `v4.14` or `v4.9`.

Record 6.2: Backport difficulty is clean for the current 7.0.5 tree,
verified by `git format-patch -1 --stdout f583bd5f64d40 | git apply
--check`. Older stable trees may need minor context adjustment because
surrounding code differs in older releases.

Record 6.3: No earlier same-subject fix exists in `v7.0`; related same-
series warning fixes were found only in `next-20260508`.

### Phase 7: Subsystem Context
Record 7.1: Subsystem is `arch/powerpc/platforms/pasemi`, a platform-
specific powerpc PCI init path. Criticality is peripheral/platform-
specific, not core kernel.

Record 7.2: Recent pasemi file history is low churn. This is mature
platform code with little recent activity.

### Phase 8: Impact And Risk
Record 8.1: Affected population: PA Semi powerpc platform builders,
especially Clang `W=1` builds with powerpc `-Werror` behavior.

Record 8.2: Trigger condition is build-time only. No runtime trigger and
no unprivileged-user trigger were verified.

Record 8.3: Failure mode is build failure under specific warning/error
settings, not crash/corruption/deadlock. Severity is medium for affected
builders, low for runtime users.

Record 8.4: Benefit is narrow but real under the stable build-fix
exception. Risk is extremely low because the generated runtime behavior
should be unchanged: the same function call remains and only an unused
local assignment is removed.

### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes a verified compiler
warning/error class; code exists across many stable-era releases; patch
is tiny, standalone, and behavior-preserving; applies cleanly to current
stable checkout. Evidence against: no runtime bug, no default-build
failure was verified, no stable nomination, platform-specific impact.
Unresolved: direct stable lore search was blocked, and I did not run a
full Clang `W=1` build.

Record 9.2: Stable rules checklist: obviously correct: yes by
inspection; tested: no explicit `Tested-by` and no local full build;
fixes a real issue: yes as a build-warning/error issue under specific
settings; important: only under build-fix exception, not runtime-
critical; small/contained: yes, 3-line single-function change; no new
feature/API: yes; applies to stable: current 7.0.5 yes, older trees
likely simple but not all tested.

Record 9.3: Exception category: build fix. This is the only reason to
take it; it is not a runtime bug fix.

Record 9.4: Decision: backport as a low-risk build fix for Clang
`W=1`/powerpc warning-as-error builds. The benefit is narrow, but the
patch is minimal, standalone, and behavior-preserving.

## Verification
- [Phase 1] `git show --format=fuller --stat --patch f583bd5f64d40`
  verified commit message, tags, and exact diff.
- [Phase 2] Diff verified one file, one function, `1 insertion`, `2
  deletions`.
- [Phase 3] `git blame` and `git show 250a93501d626` verified the unused
  assignment pattern was introduced by `250a93501d626`, described as
  before `v4.19-rc1`.
- [Phase 4] `b4 dig -c`, `-a`, `-w`, and `b4 mbox` verified the patch
  submission, resend, recipients, and lack of candidate-specific stable
  tags in the downloaded thread.
- [Phase 5] `rg` and `git grep` verified `pas_pci_init()` call placement
  and `pas_add_bridge()` call sites.
- [Phase 6] `git grep` verified the pattern in `v4.19`, `v5.10`,
  `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.17`, `v6.18`, `v6.19`, and
  `v7.0`; `git apply --check` verified clean apply to current 7.0.5.
- [Phase 7] `MAINTAINERS` verified powerpc maintainers and subsystem
  ownership.
- [Phase 8] `arch/powerpc/Kconfig.debug` and `arch/powerpc/Kbuild`
  verified powerpc warning-as-error configuration exists.
- UNVERIFIED: I did not run a full Clang `W=1` build, and direct lore
  stable search was blocked by Anubis.

**YES**

 arch/powerpc/platforms/pasemi/pci.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index 60f990a336c47..2df9552746529 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -272,13 +272,12 @@ void __init pas_pci_init(void)
 {
 	struct device_node *root = of_find_node_by_path("/");
 	struct device_node *np;
-	int res;
 
 	pci_set_flags(PCI_SCAN_ALL_PCIE_DEVS);
 
 	np = of_find_compatible_node(root, NULL, "pasemi,rootbus");
 	if (np) {
-		res = pas_add_bridge(np);
+		pas_add_bridge(np);
 		of_node_put(np);
 	}
 	of_node_put(root);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] cgroup/cpuset: move PF_EXITING check before __GFP_HARDWALL in cpuset_current_node_allowed()

[Sasha Levin]

From: Chen Wandun <chenwandun@lixiang.com>

[ Upstream commit dde2f938d02f2c740d49bb5113dea941f941026a ]

Since prepare_alloc_pages() unconditionally adds __GFP_HARDWALL for the
fast path when cpusets are enabled, the __GFP_HARDWALL check in
cpuset_current_node_allowed() causes the PF_EXITING escape path to be
skipped on the first allocation attempt.  This makes it unreachable in
the common case, so dying tasks can get stuck in direct reclaim or even
trigger OOM while trying to exit, despite being allowed to allocate from
any node.

Move the PF_EXITING check before __GFP_HARDWALL so that dying tasks
can allocate memory from any node to exit quickly, even when cpusets
are enabled.

Also update the function comment to reflect the actual behavior of
prepare_alloc_pages() and the corrected check ordering.

Signed-off-by: Chen Wandun <chenwandun@lixiang.com>
Acked-by: Michal Koutný <mkoutny@suse.com>
Acked-by: Waiman Long <longman@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `cgroup/cpuset`; action verb is “move”;
claimed intent is to move the `PF_EXITING` allowance before the
`__GFP_HARDWALL` rejection in `cpuset_current_node_allowed()` so exiting
tasks can allocate outside their cpuset and finish exiting.

Step 1.2 Record: Tags present in `dde2f938d02f2`:
- `Signed-off-by: Chen Wandun <chenwandun@lixiang.com>`
- `Acked-by: Michal Koutný <mkoutny@suse.com>`
- `Acked-by: Waiman Long <longman@redhat.com>`
- `Signed-off-by: Tejun Heo <tj@kernel.org>`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Link:`, or
`Cc: stable@vger.kernel.org` tags in the committed message.

Step 1.3 Record: The body describes a real liveness/allocation bug:
`prepare_alloc_pages()` sets `__GFP_HARDWALL` when cpusets are enabled,
so the existing hardwall rejection returns `false` before the later
`PF_EXITING` escape is reached. The described failure mode is dying
tasks getting stuck in direct reclaim or triggering OOM while trying to
exit.

Step 1.4 Record: This is a hidden bug fix despite the subject saying
“move”: it restores an existing intended exception for `PF_EXITING`
tasks that was unreachable for hardwall allocations.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed, `kernel/cgroup/cpuset.c`, 8
insertions and 6 deletions. The only functional change is inside
`cpuset_current_node_allowed()`. Scope is single-file, surgical.

Step 2.2 Record: Before, for a node outside `current->mems_allowed`, the
code checked `tsk_is_oom_victim()`, then rejected `__GFP_HARDWALL`, then
checked `PF_EXITING`. After, `PF_EXITING` is checked before
`__GFP_HARDWALL`. Comment updates match the behavior change.

Step 2.3 Record: Bug category is logic/liveness correctness in memory
allocation policy. The broken mechanism was an intended “dying task may
allocate anywhere” path being shadowed by an earlier hardwall return.

Step 2.4 Record: The fix is obviously correct by inspection: it only
reorders two independent boolean exits, introduces no locking, no data
structure changes, and no API changes. Regression risk is very low; the
only behavioral relaxation is for tasks already marked `PF_EXITING`.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the hardwall rejection is old cpuset
logic from `9bf2229f881767` in 2005; the `PF_EXITING` allowance was
added by `5563e77078d8` in 2005; the OOM-victim allowance was added by
`c596d9f320aa` in 2007. `prepare_alloc_pages()` currently sets
`*alloc_gfp |= __GFP_HARDWALL`; that structure was introduced by
`9cd7555875bb` in 2017, and checked tags show equivalent hardwall first-
attempt behavior exists at least back to `v4.4`.

Step 3.2 Record: No `Fixes:` tag, so there was no specific target commit
to follow.

Step 3.3 Record: Recent `kernel/cgroup/cpuset.c` history shows normal
cpuset churn and a 2025 rename from `cpuset_node_allowed()` to
`cpuset_current_node_allowed()` in `8adce0857769`. That rename is a
backport context issue for older trees, not a semantic dependency.

Step 3.4 Record: `git log --author='Chen Wandun' -10 linux-next/master
-- kernel/cgroup/cpuset.c mm/page_alloc.c` found this commit and one
unrelated page allocator simplification. The author is not shown as the
subsystem maintainer in the checked history; the patch was acked/applied
by cgroup maintainers/reviewers.

Step 3.5 Record: No functional prerequisite found. Older stable branches
may need the function-name/context adjusted because the function is
named `cpuset_node_allowed()` or `__cpuset_node_allowed()` there.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c dde2f938d02f2` found the original
submission:
`https://patch.msgid.link/20260507105434.3266234-1-
chenwandun@lixiang.com`
`b4 dig -a` found only v1.

Step 4.2 Record: `b4 dig -w` showed the patch was sent to Chen Wandun,
Waiman Long, Chen Ridong, Tejun Heo, Johannes Weiner, Michal Koutný,
`cgroups@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.

Step 4.3 Record: No separate bug-report link or `Reported-by:` tag. The
thread includes Chen Ridong asking how it was found; the author replied
it was found while reviewing cpuset node-allowed logic during
investigation of a memory allocation issue, not as that investigation’s
root cause.

Step 4.4 Record: Thread review: Michal Koutný acked and said it “makes
sense,” while noting OOM could eventually select the task and bypass
hardwall, so this expedites rather than necessarily being the only
unblock. Waiman Long acked. Chen Ridong gave `Reviewed-by` in the
thread. Tejun Heo applied it to `cgroup/for-7.1-fixes`. No NAKs or
objections found.

Step 4.5 Record: WebFetch for lore/stable was blocked by Anubis;
WebSearch found no useful stable-specific objection or discussion. This
is an external-search limitation.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `cpuset_current_node_allowed()`.

Step 5.2 Record: Callers verified: `__cpuset_zone_allowed()` wraps it in
`include/linux/cpuset.h`; `get_page_from_freelist()` and reclaim retry
logic call `__cpuset_zone_allowed()` when cpusets are enabled and
`ALLOC_CPUSET` is set.

Step 5.3 Record: Key callees in `cpuset_current_node_allowed()` are
`in_interrupt()`, `node_isset()`, `tsk_is_oom_victim()`,
`nearest_hardwall_ancestor()`, `task_cs()`, and `spin_lock_irqsave()`
around ancestor scanning.

Step 5.4 Record: Reachability verified through the allocator:
`prepare_alloc_pages()` sets `__GFP_HARDWALL`;
`__alloc_frozen_pages_noprof()` calls `prepare_alloc_pages()` then
`get_page_from_freelist()`. `PF_EXITING` is set in `exit_signals()`
during `do_exit()` before later exit cleanup. I did not verify a
specific later cleanup function that always allocates; the allocator
path and `PF_EXITING` timing are verified.

Step 5.5 Record: Similar pattern found: `c596d9f320aa` allowed OOM-
killed tasks to allocate anywhere to avoid exit/deadlock problems, and
current `show_mem()` treats `PF_EXITING` as an exception allowed outside
node filters.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked `v4.4`, `v4.9`, `v4.14`, `v4.19`, `v5.4`,
`v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, and `v7.0`; all checked trees
have the old ordering where `__GFP_HARDWALL` returns before
`PF_EXITING`, and allocator code setting/using `__GFP_HARDWALL`.

Step 6.2 Record: `git apply --check` of the upstream patch succeeds on
the current `v7.0.9` checkout with line offsets. Older branches need at
most minor context/name adjustment because the function name differs,
but the relevant body is present.

Step 6.3 Record: No separate alternative technical fix for this bug was
found by subject/bug-text searches. I did not use any branch-
selection/pipeline presence as decision evidence.

## Phase 7: Subsystem Context
Step 7.1 Record: Subsystem is cgroup/cpuset with page allocator
interaction. Criticality is important to core: it affects memory
allocation behavior for systems using cpusets, especially NUMA/cgroup-
managed systems.

Step 7.2 Record: The cpuset file has active recent development, but the
affected allocation policy logic is mature and present across many
stable-era tags.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems with cpusets enabled where
exiting tasks allocate while outside their allowed memory nodes or while
their allowed nodes are depleted. This is config/setup-specific, not
universal.

Step 8.2 Record: Trigger requires `PF_EXITING`, cpusets enabled, and an
allocation path where hardwall cpuset filtering checks a node outside
`current->mems_allowed`. Exiting is user-triggerable, but cpuset
placement usually depends on administrator/container-manager
configuration.

Step 8.3 Record: Failure mode is high severity: direct reclaim stalls
and possible OOM while a task is trying to exit. The thread reviewer
caveat means this may expedite exit in some OOM cases rather than prove
every instance is permanently stuck, but the liveness benefit is real.

Step 8.4 Record: Benefit is high for affected systems; risk is very low
because the change is a two-line ordering fix plus comments and only
broadens allocation eligibility for dying tasks.

## Phase 9: Final Synthesis
Step 9.1 Record:
Evidence for backporting: fixes a real allocation/liveness bug; small
one-function change; no API or feature addition; acknowledged by cgroup
reviewers; present in many stable-era tags; clean on `v7.0`; older trees
have the same logic.
Evidence against: no explicit `Fixes:`/`Cc: stable`/`Reported-
by`/`Tested-by`; no concrete reproducer in commit or thread; older trees
may need minor context adjustment.
Unresolved: I could not use WebFetch on lore/stable due Anubis; I did
not verify behavior earlier than `v4.4`; I did not run runtime tests.

Step 9.2 Stable rules:
1. Obviously correct and tested? Obviously correct by inspection; no
   explicit test tag.
2. Fixes a real bug? Yes, unreachable `PF_EXITING` allocation escape
   under hardwall cpuset filtering.
3. Important issue? Yes, can cause direct reclaim stalls or OOM during
   task exit.
4. Small and contained? Yes, one file, one function, 8 insertions/6
   deletions mostly comments.
5. No new features/APIs? Yes.
6. Can apply to stable? Yes for current `v7.0`; older trees likely need
   minor backport context due function naming.

Step 9.3 Exception category: No special exception category; this is a
normal bug fix.

Step 9.4 Decision: Backport. The fix restores intended dying-task
allocation behavior, is narrowly scoped, has strong reviewer confidence,
and addresses a serious liveness failure with minimal regression risk.

## Verification
- Phase 1: Parsed `git show --format=fuller` for `dde2f938d02f2`;
  confirmed tags and absence of `Fixes:`/`Reported-by:`/`Tested-by:`.
- Phase 2: Inspected the diff; confirmed only `kernel/cgroup/cpuset.c`
  changes and functional reorder in `cpuset_current_node_allowed()`.
- Phase 3: Ran `git blame` on `kernel/cgroup/cpuset.c` and
  `mm/page_alloc.c`; inspected historical commits `5563e77078d8`,
  `c596d9f320aa`, `9bf2229f8817`, `9cd7555875bb`, and `8adce0857769`.
- Phase 4: Ran `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and saved/read the
  mbox; confirmed v1 only, maintainer/reviewer acks, and no NAKs.
- Phase 5: Used repository search and file reads to trace
  `cpuset_current_node_allowed()` through `__cpuset_zone_allowed()` into
  `get_page_from_freelist()` and allocator preparation.
- Phase 6: Used `git grep` on stable tags from `v4.4` through `v7.0`;
  confirmed the old ordering and allocator hardwall behavior exist. Ran
  `git apply --check` successfully on current `v7.0.9`.
- Phase 7: Checked recent cpuset history to assess activity and context.
- Phase 8: Verified `PF_EXITING` is set in `exit_signals()` during
  `do_exit()` before later exit cleanup.
- UNVERIFIED: Lore/stable WebFetch was blocked by Anubis; no runtime
  reproducer or test result was found; exact pre-`v4.4` introduction was
  not verified.

**YES**

 kernel/cgroup/cpuset.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 1335e437098e8..d2d2c7126638a 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -4171,11 +4171,11 @@ static struct cpuset *nearest_hardwall_ancestor(struct cpuset *cs)
  * current's mems_allowed, yes.  If it's not a __GFP_HARDWALL request and this
  * node is set in the nearest hardwalled cpuset ancestor to current's cpuset,
  * yes.  If current has access to memory reserves as an oom victim, yes.
- * Otherwise, no.
+ * If the current task is PF_EXITING, yes. Otherwise, no.
  *
  * GFP_USER allocations are marked with the __GFP_HARDWALL bit,
  * and do not allow allocations outside the current tasks cpuset
- * unless the task has been OOM killed.
+ * unless the task has been OOM killed or is exiting.
  * GFP_KERNEL allocations are not so marked, so can escape to the
  * nearest enclosing hardwalled ancestor cpuset.
  *
@@ -4189,7 +4189,9 @@ static struct cpuset *nearest_hardwall_ancestor(struct cpuset *cs)
  * The first call here from mm/page_alloc:get_page_from_freelist()
  * has __GFP_HARDWALL set in gfp_mask, enforcing hardwall cpusets,
  * so no allocation on a node outside the cpuset is allowed (unless
- * in interrupt, of course).
+ * in interrupt, of course).  The PF_EXITING check must therefore
+ * come before the __GFP_HARDWALL check, otherwise a dying task
+ * would be blocked on the fast path.
  *
  * The second pass through get_page_from_freelist() doesn't even call
  * here for GFP_ATOMIC calls.  For those calls, the __alloc_pages()
@@ -4199,6 +4201,7 @@ static struct cpuset *nearest_hardwall_ancestor(struct cpuset *cs)
  *	in_interrupt - any node ok (current task context irrelevant)
  *	GFP_ATOMIC   - any node ok
  *	tsk_is_oom_victim   - any node ok
+ *	PF_EXITING   - any node ok (let dying task exit quickly)
  *	GFP_KERNEL   - any node in enclosing hardwalled cpuset ok
  *	GFP_USER     - only nodes in current tasks mems allowed ok.
  */
@@ -4218,11 +4221,10 @@ bool cpuset_current_node_allowed(int node, gfp_t gfp_mask)
 	 */
 	if (unlikely(tsk_is_oom_victim(current)))
 		return true;
-	if (gfp_mask & __GFP_HARDWALL)	/* If hardwall request, stop here */
-		return false;
-
 	if (current->flags & PF_EXITING) /* Let dying task have memory */
 		return true;
+	if (gfp_mask & __GFP_HARDWALL)	/* If hardwall request, stop here */
+		return false;
 
 	/* Not hardwall and node outside mems_allowed: scan up cpusets */
 	spin_lock_irqsave(&callback_lock, flags);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] drm/amd/ras: Fix CPER ring debugfs read overflow

[Sasha Levin]

From: Xiang Liu <xiang.liu@amd.com>

[ Upstream commit 6bbede02dc62a1021aeeae87ab243bd7a93c61d2 ]

The legacy CPER debugfs reader can reach the payload path without a
valid pointer snapshot. The remaining user byte count is also treated as
the ring occupancy in dwords, so reads past the header can copy more than
requested.

Take the CPER lock before sampling pointers. Resample rptr/wptr for
payload reads, bound the payload copy by available dwords and the
remaining user size, and advance the file position for each dword copied.

Signed-off-by: Xiang Liu <xiang.liu@amd.com>
Reviewed-by: Tao Zhou <tao.zhou1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 1e40ef87ffdc291e05ccdade8b9170cc9c1c4249)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Records

Step 1.1 Record: Subsystem `drm/amd/ras`; action verb `Fix`; claimed
intent is preventing CPER ring debugfs read overflow.

Step 1.2 Record: Tags present: `Signed-off-by: Xiang Liu
<xiang.liu@amd.com>`, `Reviewed-by: Tao Zhou <tao.zhou1@amd.com>`,
`Signed-off-by: Alex Deucher <alexander.deucher@amd.com>`, and a cherry-
pick line. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Link:`, or `Cc:
stable`.

Step 1.3 Record: Commit body describes two concrete bugs: CPER payload
reads can proceed without a valid rptr/wptr snapshot, and byte `size` is
treated as dword ring occupancy, allowing copies beyond the requested
read count.

Step 1.4 Record: Not hidden; this is an explicit memory-safety/user-copy
bounds fix.

Step 2.1 Record: One file changed,
`drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c`; one function changed,
`amdgpu_debugfs_ring_read`; roughly +13/-? surgical single-function
change.

Step 2.2 Record: Before, CPER locking and pointer sampling happened only
when `*pos < 12`; payload-only reads used uninitialized `early[]`.
Before, payload loop copied one dword while decrementing `size` by one,
although `size` is bytes. After, CPER reads lock before sampling,
resample pointers for payload, compute available dwords separately, cap
reads by `size >> 2`, and advance `*pos`.

Step 2.3 Record: Bug category is memory safety / bounds correctness plus
synchronization. Mechanism: debugfs `read()` could return/copy more
bytes than requested and could use invalid CPER ring pointers on reads
starting past the header.

Step 2.4 Record: Fix quality is good: small, local, no API change.
Regression risk is low; it only changes CPER debugfs reads. Holding
`cper.ring_lock` for payload-only reads matches the existing intent to
serialize with `amdgpu_cper_ring_write`.

Step 3.1 Record: `git blame` shows the CPER payload reader came from
`5a1428242952f2` (`drm/amdgpu: read CPER ring via debugfs`), first
contained by `v6.15-rc1`; the partial CPER lock came from
`8652920d2c0024`.

Step 3.2 Record: No `Fixes:` tag to follow. I inspected the introducing
commits manually: `5a1428242952f2` added the affected CPER payload
reader; `8652920d2c0024` added the existing CPER ring mutex but only
around the header path.

Step 3.3 Record: Related history includes `4d614ce8ffd75` adding the
CPER ring buffer, `a6d9d192903ea` adding CPER writes, `d6f9bbce18762`
fixing CPER ring remaining-size computation, and `93c19634f72fb` fixing
a separate uniras CPER debugfs user-buffer overflow.

Step 3.4 Record: Xiang Liu has multiple AMDGPU/RAS CPER commits in this
area. Alex Deucher committed the patch per the commit tags and is the
AMDGPU maintainer path in local history.

Step 3.5 Record: Dependencies are the existing CPER ring/debugfs code.
The affected code exists in this v7.0.y checkout and in tags `v6.15`
through `v7.0`; it is absent from `v6.14` by pattern check.

Step 4.1 Record: `b4 dig -c 1e40ef...` failed because the commit object
is not present locally. Web searches did not find the exact target
subject/body; they found related AMDGPU CPER debugfs patches and the
uniras buffer-overflow bug report.

Step 4.2 Record: `b4 dig -w` also failed for the same reason. Commit
tags still show AMDGPU review by Tao Zhou and commit by Alex Deucher.

Step 4.3 Record: No direct bug report found for this exact patch.
Related Dan Carpenter report verified a similar CPER debugfs user-buffer
overflow in `amdgpu_ras_cper_debugfs_read`, not this legacy reader.

Step 4.4 Record: Related CPER series context verified on freedesktop
archives: CPER debugfs read and CPER mutex patches were part of a v2
AMDGPU CPER series.

Step 4.5 Record: No stable-specific discussion found for the exact
target terms.

Step 5.1 Record: Modified function: `amdgpu_debugfs_ring_read`.

Step 5.2 Record: Callers are debugfs file operations:
`amdgpu_debugfs_ring_fops.read` and, for SR-IOV,
`amdgpu_debugfs_virt_ring_read`, which calls `amdgpu_debugfs_ring_read`.

Step 5.3 Record: Key callees are `amdgpu_ring_get_rptr`,
`amdgpu_ring_get_wptr`, `put_user`, and CPER lock operations. CPER
writes use `amdgpu_cper_ring_write`, which takes the same
`cper.ring_lock`.

Step 5.4 Record: Reachability is via
`/sys/kernel/debug/dri/*/amdgpu_ring_cper`, created by
`amdgpu_debugfs_ring_init` for registered rings. `amdgpu_ring_init`
registers rings in `adev->rings`, and `amdgpu_debugfs_init` iterates
those rings.

Step 5.5 Record: Similar pattern found: separate uniras CPER reader
overflow fixed by `93c19634f72fb`.

Step 6.1 Record: Buggy legacy CPER debugfs reader exists in `v6.15`,
`v6.16`, `v6.17`, `v6.18`, `v6.19`, and `v7.0`; not found in `v6.14`.

Step 6.2 Record: Expected backport difficulty is low for trees
containing the CPER reader. I could not complete a meaningful `git apply
--check` because my hand-built check patch was malformed, but the
current file matches the relevant pre-fix logic.

Step 6.3 Record: Related uniras fix exists locally, but it does not fix
the legacy `amdgpu_debugfs_ring_read` CPER path.

Step 7.1 Record: Subsystem is AMDGPU DRM/RAS driver code. Criticality is
driver-specific, not core kernel-wide.

Step 7.2 Record: Subsystem is active; local history shows multiple
CPER/RAS changes around v6.15-v6.19.

Step 8.1 Record: Affected users are AMDGPU systems with CPER ring
enabled and debugfs CPER ring reads.

Step 8.2 Record: Trigger is reading the CPER ring debugfs file,
especially payload reads past the 12-byte header or small/count-limited
reads. Unprivileged triggerability depends on debugfs mount permissions
and was not verified.

Step 8.3 Record: Failure mode is user-copy beyond requested read size
and possible invalid ring indexing from missing pointer snapshot.
Severity: HIGH for memory-safety correctness, reduced by debugfs-only
exposure.

Step 8.4 Record: Benefit is meaningful for affected AMDGPU debugfs users
because it prevents incorrect user copies and invalid CPER ring reads.
Risk is low: small, contained, no feature/API change.

## Stable Rules

1. Obviously correct and tested: mostly yes by inspection and maintainer
   review tag; no explicit `Tested-by`.
2. Fixes a real bug: yes, byte count vs dword count and missing pointer
   snapshot are verified in the code.
3. Important issue: yes, memory-safety/user-copy overflow from a
   readable debugfs file.
4. Small and contained: yes, one function in one driver file.
5. No new features/APIs: yes.
6. Can apply to stable: yes for v6.15+ trees containing the CPER debugfs
   reader; not applicable to v6.14 and older.

## Verification

- Phase 1: Parsed provided commit message and tags; no `Fixes`,
  `Reported-by`, `Link`, or stable tag present.
- Phase 2: Compared provided diff with current
  `amdgpu_debugfs_ring_read` implementation; verified `size` is bytes
  and old CPER loop decrements it as dwords.
- Phase 3: Ran `git blame` on the affected function; identified
  `5a1428242952f2` and `8652920d2c0024`.
- Phase 3: Ran `git show` on related commits `4d614ce8ffd75`,
  `5a1428242952f2`, `8652920d2c0024`, `d6f9bbce18762`, `527e3d40339b`,
  `93c19634f72fb`, and `a91d91b600479`.
- Phase 4: Ran `b4 dig`; it failed because the target commit object is
  unavailable in this checkout.
- Phase 4: Web searched exact subject/body; no direct target lore found.
  Fetched related freedesktop CPER series and Dan Carpenter uniras
  overflow report.
- Phase 5: Used repo search/read to trace debugfs fops, ring debugfs
  creation, CPER writer locking, and ring registration.
- Phase 6: Checked tags `v6.14` through `v7.0`; verified affected code
  starts at `v6.15`.
- Phase 8: Verified debugfs exposure through
  `debugfs_create_file_size(..., 0444, ...)`; did not verify system
  mount permissions, so unprivileged exploitability remains unverified.

This is a small, well-scoped memory-safety fix for code present in
stable trees starting at v6.15. It should be backported to affected
stable trees.

**YES**

 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 29 +++++++++++++++++-------
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index 4638a686a84e7..bebd72178cc13 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
@@ -572,8 +572,9 @@ static ssize_t amdgpu_debugfs_ring_read(struct file *f, char __user *buf,
 					size_t size, loff_t *pos)
 {
 	struct amdgpu_ring *ring = file_inode(f)->i_private;
-	uint32_t value, result, early[3];
+	u32 value, result, early[3] = { 0 };
 	uint64_t p;
+	u32 avail_dw, start_dw, read_dw;
 	loff_t i;
 	int r;
 
@@ -585,10 +586,10 @@ static ssize_t amdgpu_debugfs_ring_read(struct file *f, char __user *buf,
 
 	result = 0;
 
-	if (*pos < 12) {
-		if (ring->funcs->type == AMDGPU_RING_TYPE_CPER)
-			mutex_lock(&ring->adev->cper.ring_lock);
+	if (ring->funcs->type == AMDGPU_RING_TYPE_CPER)
+		mutex_lock(&ring->adev->cper.ring_lock);
 
+	if (*pos < 12) {
 		early[0] = amdgpu_ring_get_rptr(ring) & ring->buf_mask;
 		early[1] = amdgpu_ring_get_wptr(ring) & ring->buf_mask;
 		early[2] = ring->wptr & ring->buf_mask;
@@ -620,13 +621,24 @@ static ssize_t amdgpu_debugfs_ring_read(struct file *f, char __user *buf,
 			*pos += 4;
 		}
 	} else {
+		early[0] = amdgpu_ring_get_rptr(ring) & ring->buf_mask;
+		early[1] = amdgpu_ring_get_wptr(ring) & ring->buf_mask;
+
 		p = early[0];
 		if (early[0] <= early[1])
-			size = (early[1] - early[0]);
+			avail_dw = early[1] - early[0];
 		else
-			size = ring->ring_size - (early[0] - early[1]);
+			avail_dw = ring->buf_mask + 1 - (early[0] - early[1]);
 
-		while (size) {
+		start_dw = (*pos > 12) ? ((*pos - 12) >> 2) : 0;
+		if (start_dw >= avail_dw)
+			goto out;
+
+		p = (p + start_dw) & ring->ptr_mask;
+		avail_dw -= start_dw;
+		read_dw = min_t(u32, avail_dw, size >> 2);
+
+		while (read_dw) {
 			if (p == early[1])
 				goto out;
 
@@ -639,9 +651,10 @@ static ssize_t amdgpu_debugfs_ring_read(struct file *f, char __user *buf,
 
 			buf += 4;
 			result += 4;
-			size--;
+			read_dw--;
 			p++;
 			p &= ring->ptr_mask;
+			*pos += 4;
 		}
 	}
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] scsi: smartpqi: Silence a recursive lock warning

[Sasha Levin]

From: Tomas Henzl <thenzl@redhat.com>

[ Upstream commit d65efdf467ff935e35dfe6aa9a7ab93f17ac07ee ]

On systems with multiple controllers debug kernel shows

  WARNING: possible recursive locking detected

during shutdown.

Each controller does have its own ctrl_info (and mutex) and that isn't
correctly recognized by debug kernel.  Suppress the warning by releasing
the mutex at the end of pqi_shutdown().

Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Acked-by: Don Brace <don.brace@microchip.com>
Link: https://patch.msgid.link/20260414124118.23661-1-thenzl@redhat.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
Backport this to stable trees that contain the mutex-based
`pqi_ctrl_block_device_reset()` shutdown path, verified in `v5.15`,
`v6.1`, `v6.6`, `v6.12`, `v6.16`, and `v6.19`. Do not apply it as-is to
`v5.10`, where that helper only sets `block_device_reset = true` and no
`pqi_ctrl_unblock_device_reset()` helper exists.

This is a one-line fix for an imbalanced `lun_reset_mutex` lock in
`pqi_shutdown()`. The direct user-visible symptom is a lockdep “possible
recursive locking detected” warning during shutdown/reboot on systems
with multiple smartpqi controllers. The impact is mostly debug-kernel
noise rather than data loss or a production crash, but the patch
corrects real locking hygiene, is tiny, subsystem-reviewed, and has very
low risk.

## Phase Walkthrough
Phase 1:
- Record 1.1: subsystem `scsi: smartpqi`; action `Silence`; intent is to
  stop a recursive lock warning during shutdown.
- Record 1.2: tags present: `Signed-off-by: Tomas Henzl`, `Acked-by: Don
  Brace`, `Link:
  https://patch.msgid.link/20260414124118.23661-1-thenzl@redhat.com`,
  `Signed-off-by: Martin K. Petersen`. No `Fixes:`, no `Reported-by:`,
  no `Cc: stable`.
- Record 1.3: message describes debug kernels warning on multi-
  controller systems because distinct per-controller mutexes are not
  recognized as distinct after shutdown leaves one held.
- Record 1.4: hidden bug fix: yes. It is described as silencing a
  warning, but the code adds a missing unlock for a mutex acquired
  earlier in the same function.

Phase 2:
- Record 2.1: one file, `drivers/scsi/smartpqi/smartpqi_init.c`, one
  insertion in `pqi_shutdown()`. Single-file surgical fix.
- Record 2.2: before, `pqi_shutdown()` locked
  `ctrl_info->lun_reset_mutex` via `pqi_ctrl_block_device_reset()` and
  returned after `pqi_reset()` without unlocking. After, it unlocks via
  `pqi_ctrl_unblock_device_reset()`.
- Record 2.3: bug category is synchronization/lock balancing. The
  changed helper is verified as
  `mutex_unlock(&ctrl_info->lun_reset_mutex)`.
- Record 2.4: fix quality is high: one existing helper call, no new API,
  no refactor. Main risk is allowing a reset waiter to proceed late in
  shutdown; Tomas explicitly discussed this risk on-list and said he
  checked it.

Phase 3:
- Record 3.1: blame shows the shutdown call to
  `pqi_ctrl_block_device_reset()` is old, but `9fa8202336096` changed
  the helper to a mutex-based block/unblock model. That is the relevant
  introduction point for the missing unlock.
- Record 3.2: no `Fixes:` tag, so no tagged introducing commit to
  follow.
- Record 3.3: recent file history shows normal smartpqi churn, including
  fixes and device-ID updates; no prerequisite for this one-line helper
  call was identified for v5.15+ style code.
- Record 3.4: Tomas Henzl has SCSI commits in history but no recent
  smartpqi commits found; Don Brace is listed as smartpqi maintainer and
  acked the patch.
- Record 3.5: dependency is the existing
  `pqi_ctrl_unblock_device_reset()` helper. It exists in v5.15+ verified
  tags, not in v5.10.

Phase 4:
- Record 4.1: candidate commit hash was not available locally, so `b4
  dig -c` could not be used for this candidate. `b4 mbox` and `b4 am`
  using the Link fetched the original thread.
- Record 4.2: original recipients were `linux-scsi` and Don Brace; Don
  Brace acked it; Martin Petersen applied it.
- Record 4.3: external thread and an earlier related LKML post show a
  real lockdep splat with call trace through `__do_sys_reboot ->
  device_shutdown -> pci_device_shutdown -> pqi_shutdown`.
- Record 4.4: no newer v2/v3 was reported by `b4 mbox -c`; thread had
  six messages. A separate 2025 lockdep-key proposal for the same
  warning was found, but it is not present in this tree.
- Record 4.5: web search found no relevant stable-list discussion.

Phase 5:
- Record 5.1: modified function: `pqi_shutdown()`.
- Record 5.2: caller is PCI driver `.shutdown = pqi_shutdown`; this is
  reached from PCI/device shutdown during reboot/poweroff paths.
- Record 5.3: relevant callees are `pqi_wait_until_ofa_finished()`,
  `pqi_scsi_block_requests()`, `pqi_ctrl_block_device_reset()`,
  `pqi_ctrl_block_requests()`, `pqi_ctrl_wait_until_quiesced()`,
  `pqi_flush_cache()`, `pqi_crash_if_pending_command()`, `pqi_reset()`,
  and now `pqi_ctrl_unblock_device_reset()`.
- Record 5.4: verified external call trace reaches `pqi_shutdown()` from
  reboot. Trigger requires multiple smartpqi controllers and a
  debug/lockdep kernel.
- Record 5.5: similar lock/unlock pairing exists in OFA and
  suspend/resume paths; shutdown was the unmatched case.

Phase 6:
- Record 6.1: verified `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.16`, and
  `v6.19` have mutex-based block/unblock helpers and shutdown lacks the
  final unblock. Verified `v5.10` does not have the mutex helper.
- Record 6.2: expected backport difficulty is clean or trivial for
  v5.15+ style trees because the exact helper and shutdown context
  exist. v5.10 is not applicable as-is.
- Record 6.3: no related fix already present in the checked local tree;
  `lun_reset_key` proposal is absent.

Phase 7:
- Record 7.1: subsystem is SCSI storage driver, `smartpqi`; criticality
  is driver-specific but storage-related.
- Record 7.2: subsystem is active; recent history shows ongoing fixes,
  device IDs, and driver updates.

Phase 8:
- Record 8.1: affected users are systems with Microchip/Microsemi
  SmartPQI controllers, especially multiple controllers with
  debug/lockdep kernels.
- Record 8.2: trigger is shutdown/reboot. The verified external trace
  shows reboot path; unprivileged triggerability was not verified.
- Record 8.3: failure mode is lockdep warning/lock imbalance, severity
  medium-low in production terms but valid for debug-kernel correctness.
- Record 8.4: benefit is moderate for affected systems and CI/debug
  kernels; risk is very low because this is one line using an existing
  helper after a matching lock.

Phase 9:
- Record 9.1: evidence for backporting: real lock imbalance,
  reproducible lockdep warning, one-line fix, maintainer ack, existing
  helper, verified affected stable baselines v5.15+. Evidence against:
  symptom is mainly debug warning, not crash/data corruption; v5.10 not
  applicable as-is.
- Record 9.2: stable rules: obviously correct yes; fixes a real bug yes;
  important issue borderline but acceptable due lockdep warning and tiny
  risk; small/contained yes; no new features/APIs yes; applies to v5.15+
  style trees likely clean/trivial.
- Record 9.3: no exception category applies.
- Record 9.4: risk-benefit favors backporting for applicable stable
  trees.

## Verification
- Phase 1: Parsed supplied commit message and `b4 am` output; confirmed
  tags and absence of `Fixes:`/stable/Reported-by.
- Phase 2: Read `smartpqi_init.c`; confirmed
  `pqi_ctrl_block_device_reset()` is `mutex_lock()` and
  `pqi_ctrl_unblock_device_reset()` is `mutex_unlock()`.
- Phase 3: Used `git blame`, `git show 0530736e40a069`, and `git show
  9fa8202336096d`; confirmed helper semantics changed to mutex model in
  the shutdown/suspend update.
- Phase 4: `WebFetch` to `patch.msgid.link` was blocked by Anubis; `b4
  mbox`/`b4 am` fetched the lore thread successfully. `b4 am` reported
  the patch applies cleanly to current tree.
- Phase 4: Read lore mirror; confirmed Bart’s “patch looks fine”
  comment, Tomas’s risk discussion, Don Brace’s ack, and Martin
  Petersen’s apply notice.
- Phase 5: Used exact searches and file reads to trace `.shutdown =
  pqi_shutdown`, SCSI reset handlers, and related lock users.
- Phase 6: Used version tags to verify affected code in `v5.15+` and
  non-applicability to `v5.10`.
- Phase 7: Checked `MAINTAINERS`; confirmed Don Brace maintains
  smartpqi.
- Phase 8: External LKML mirror provided the concrete lockdep call trace
  and trigger conditions.
- Unverified: I did not build-test the patch and did not verify stable
  branch-specific conflicts beyond version-tag code presence.

**YES**

 drivers/scsi/smartpqi/smartpqi_init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/smartpqi/smartpqi_init.c b/drivers/scsi/smartpqi/smartpqi_init.c
index b4ed991976d06..2026ac645d6ab 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -9427,6 +9427,7 @@ static void pqi_shutdown(struct pci_dev *pci_dev)
 
 	pqi_crash_if_pending_command(ctrl_info);
 	pqi_reset(ctrl_info);
+	pqi_ctrl_unblock_device_reset(ctrl_info);
 }
 
 static void pqi_process_lockup_action_param(void)
-- 
2.53.0

[PATCH AUTOSEL 7.0] io_uring: defer linked-timeout chain splice out of hrtimer context

[Sasha Levin]

From: Jens Axboe <axboe@kernel.dk>

[ Upstream commit 49ae66eb8c27375075ffa308cfd4bf25af335d41 ]

io_link_timeout_fn() is the hrtimer callback that fires when a linked
timeout expires. It currently calls io_remove_next_linked(prev) under
ctx->timeout_lock to splice the timeout request out of the link chain.
This is the only chain-mutation site that runs without ctx->uring_lock,
because hrtimer callbacks cannot take a mutex. Defer the splicing until
the task_work callback.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record: subsystem `io_uring`; action verb `defer`; intent is to move
linked-timeout chain splicing out of `io_link_timeout_fn()` hrtimer
context and into task_work.

Record: tags found only `Signed-off-by: Jens Axboe <axboe@kernel.dk>`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Cc: stable`,
or external `Link:` in the upstream commit.

Record: the body describes a locking bug: `io_link_timeout_fn()` mutates
the linked request chain under `ctx->timeout_lock` but without
`ctx->uring_lock`; hrtimer callbacks cannot take the mutex, so mutation
is deferred to task_work.

Record: this is a real hidden bug fix despite not saying “fix”: it
corrects an unsynchronized linked-list mutation in an hrtimer callback.

## Phase 2: Diff Analysis
Record: one file changed, `io_uring/timeout.c`, 14 insertions and 2
deletions. Modified functions: `__io_disarm_linked_timeout()`,
`io_req_task_link_timeout()`, `io_link_timeout_fn()`. Scope is single-
file surgical locking/race fix.

Record: before, `io_link_timeout_fn()` called
`io_remove_next_linked(prev)` directly from hrtimer context under only
`timeout_lock`. After, the timer claims the timeout, stores
`timeout->prev`, and queues task_work; `io_req_task_link_timeout()` then
splices `req` out of `prev->link` if the normal completion path did not
already do so.

Record: `__io_disarm_linked_timeout()` now detects `timeout->head ==
NULL`, meaning the timer already claimed the timeout, and avoids
cancel/list removal in that race.

Record: bug category is synchronization/race on linked request chain
mutation. Fix quality is good but series-sensitive: patch 3/3
(`a65855ec34aed`) is needed to keep `io_kill_timeouts()` walking chains
under `uring_lock` after this patch changes where splicing happens.

## Phase 3: Git History Investigation
Record: blame shows the relevant linked-timeout code and
`io_remove_next_linked()` originated mainly from `59915143e89f`
(“io_uring: move timeout opcodes and handling into its own file”), first
contained around `v6.0-rc1`; later timeout-lock changes include
`020b40f35624`, and `__io_disarm_linked_timeout()` changes include
`78967aabf613`, first around `v6.16-rc1`.

Record: no `Fixes:` tag exists, so there was no tagged introducer to
follow.

Record: recent history shows this is patch 2/3 in a linked-request
locking series:
`20c39819a276` locks `io_wq_free_work()` chain walking,
`49ae66eb8c27` defers linked-timeout splicing,
`a65855ec34ae` keeps `uring_lock` across `io_kill_timeouts()`.

Record: Jens Axboe is listed in `MAINTAINERS` as the `IO_URING`
maintainer and authored the commit.

## Phase 4: Mailing List And External Research
Record: `b4 dig -c 49ae66eb8c27` found the lore submission at
`https://patch.msgid.link/20260511182217.226763-3-axboe@kernel.dk`.

Record: `b4 dig -a` found only v1 of the 3-patch series. `b4 dig -w`
showed recipients were Jens Axboe and `io-uring@vger.kernel.org`.

Record: the saved mbox contains the cover letter “[PATCHSET 0/3] Linked
request fix”, stating chain iteration must hold either `uring_lock` or
`timeout_lock`, and modification should be buttoned up. No replies,
NAKs, review tags, or stable nominations were present in the mbox.

Record: direct `WebFetch` of lore and stable search pages was blocked by
Anubis, so no web-side stable discussion could be verified.

## Phase 5: Code Semantic Analysis
Record: key functions are `io_link_timeout_fn()`,
`io_req_task_link_timeout()`, `__io_disarm_linked_timeout()`, and
`io_remove_next_linked()`.

Record: call/reachability tracing verified `IORING_OP_LINK_TIMEOUT` uses
`io_link_timeout_prep()` in `io_uring/opdef.c`; prep installs
`io_link_timeout_fn()` as the hrtimer callback, and linked timeouts are
queued on `ctx->ltimeout_list`.

Record: task_work runners in `io_uring/tw.c` execute callbacks while
holding `ctx->uring_lock` in normal, fallback, and local-work paths.
This verifies the deferred splice runs in a mutex-protected context.

Record: similar pattern search found the hrtimer callback was the unique
changed direct chain mutation site in this diff; the related series
covers other chain walking gaps.

## Phase 6: Stable Tree Analysis
Record: `git merge-base --is-ancestor` verified the old timeout split
commit exists in `v6.19.14` and `v6.6.140`; the candidate itself is not
in `v7.0.9` or `v6.19.14`.

Record: `git show`/`rg` verified the buggy `io_link_timeout_fn()`
pattern exists in `v7.0.9`, `v6.19.14`, `v6.15`, `v6.12.90`, `v6.6.140`,
and in older `v5.15` under `fs/io_uring.c`.

Record: `git diff 49ae^..49ae | git apply --check` succeeded on the
current `v7.0.9` checkout. Older trees have API/path differences such as
task_work signature and `spin_lock` vs `raw_spin_lock`, so they need
manual backporting.

## Phase 7: Subsystem Context
Record: subsystem is `io_uring`, a core async I/O userspace API.
Criticality is IMPORTANT: not universal like MM/VFS, but reachable from
userspace and widely used.

Record: `git log origin/master --oneline -20 -- io_uring` shows high
activity, including this linked-request locking series and other recent
fixes.

## Phase 8: Impact And Risk
Record: affected users are systems using io_uring linked requests with
`IORING_OP_LINK_TIMEOUT`.

Record: trigger is a timing race between linked-timeout hrtimer expiry
and other linked-chain completion/cancel paths; this is reachable from
userspace via io_uring submissions.

Record: verified failure class is unsynchronized linked-list/request-
chain mutation. No crash report was verified, but the protected object
is request-chain state, so the stability risk is request chain
corruption, wrong cancellation/completion, or follow-on memory lifetime
bugs.

Record: benefit is high for affected io_uring users because it closes a
real locking gap in request lifetime/chain handling. Risk is low-medium:
the patch is small, but should be backported with the adjacent locking
fixes, especially `a65855ec34aed`.

## Phase 9: Final Synthesis
Record: evidence for backporting: real race fix, userspace-reachable
io_uring path, single-file 16-line patch, authored by subsystem
maintainer, applies cleanly to `v7.0.9`, and the buggy pattern exists
across active stable/LTS tags checked.

Record: evidence against/concerns: no reporter/test tag, no explicit
stable tag, no verified crash trace, and the commit is part of a 3-patch
locking series; backporting only this patch without the follow-up
cancel-path lock change can leave the locking story incomplete.

Record: stable rules: obviously correct by code inspection with the
series context; fixes a real synchronization bug; important because it
affects request-chain mutation in a userspace API; small and contained;
no new feature/API; applies cleanly to `v7.0.9`, with older trees
needing backport adjustment.

Record: no automatic exception category applies; this is not a device
ID, quirk, DT, build, or documentation fix.

## Verification
- [Phase 1] `git show -s` confirmed subject, body, author, and absence
  of tags beyond Jens’s SOB.
- [Phase 2] `git show --patch 49ae66eb8c27` confirmed
  `io_uring/timeout.c` only, 14 insertions/2 deletions.
- [Phase 3] `git blame` confirmed relevant code history; `git describe
  --contains` placed `59915143e89f` around `v6.0-rc1` and `78967aabf613`
  around `v6.16-rc1`.
- [Phase 3] `git log` confirmed related commits `20c39819a276` and
  `a65855ec34ae`.
- [Phase 4] `b4 dig` found the exact patch submission and v1 3-patch
  series; saved mbox showed no review replies or stable nomination.
- [Phase 5] `rg` and `git show` traced `IORING_OP_LINK_TIMEOUT` prep,
  hrtimer setup, task_work execution, and task_work locking.
- [Phase 6] stable tag checks verified the buggy pattern exists in
  checked stable/LTS tags; `git apply --check` succeeded on current
  `v7.0.9`.
- [Phase 7] `MAINTAINERS` verified Jens Axboe maintains `IO_URING`.
- [Phase 8] failure mode is verified as a locking/race bug; concrete
  crash symptoms are UNVERIFIED.

The commit should be backported, preferably together with the adjacent
linked-request locking series commits needed for a complete invariant.

**YES**

 io_uring/timeout.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/io_uring/timeout.c b/io_uring/timeout.c
index e3815e3465dde..4ee1c21e1b15f 100644
--- a/io_uring/timeout.c
+++ b/io_uring/timeout.c
@@ -245,6 +245,10 @@ static struct io_kiocb *__io_disarm_linked_timeout(struct io_kiocb *req,
 	struct io_timeout *timeout = io_kiocb_to_cmd(link, struct io_timeout);
 
 	io_remove_next_linked(req);
+
+	/* If this is NULL, then timer already claimed it and will complete it */
+	if (!timeout->head)
+		return NULL;
 	timeout->head = NULL;
 	if (hrtimer_try_to_cancel(&io->timer) != -1) {
 		list_del(&timeout->list);
@@ -328,6 +332,14 @@ static void io_req_task_link_timeout(struct io_tw_req tw_req, io_tw_token_t tw)
 	int ret;
 
 	if (prev) {
+		/*
+		 * splice the linked timeout out of prev's chain if the regular
+		 * completion path didn't already do it.
+		 */
+		if (prev->link == req)
+			prev->link = req->link;
+		req->link = NULL;
+
 		if (!tw.cancel) {
 			struct io_cancel_data cd = {
 				.ctx		= req->ctx,
@@ -362,10 +374,10 @@ static enum hrtimer_restart io_link_timeout_fn(struct hrtimer *timer)
 
 	/*
 	 * We don't expect the list to be empty, that will only happen if we
-	 * race with the completion of the linked work.
+	 * race with the completion of the linked work. Splice of prev is
+	 * done in io_req_task_link_timeout(), if needed.
 	 */
 	if (prev) {
-		io_remove_next_linked(prev);
 		if (!req_ref_inc_not_zero(prev))
 			prev = NULL;
 	}
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] io_uring: validate user-controlled cq.head in io_cqe_cache_refill()

[Sasha Levin]

From: Zizhi Wo <wozizhi@huawei.com>

[ Upstream commit f44d38a31f1802b7222adaea9ee69f9d280f698a ]

A fuzzing run reproduced an unkillable io_uring task stuck at ~100% CPU:

[root@fedora io_uring_stress]# ps -ef | grep io_uring
root  1240  1  99 13:36 ?  00:01:35 [io_uring_stress] <defunct>

The task loops inside io_cqring_wait() and never returns to userspace,
and SIGKILL has no effect.

This is caused by the CQ ring exposing rings->cq.head to userspace as
writable, while the authoritative tail lives in kernel-private
ctx->cached_cq_tail. io_cqe_cache_refill() computes free space as an
unsigned subtraction:

    free = ctx->cq_entries - min(tail - head, ctx->cq_entries);

If userspace keeps head within [0, tail], the subtraction is well
defined and min() just acts as a defensive clamp. But if userspace
advances head past tail, (tail - head) wraps to a huge value, free
becomes 0, and io_cqe_cache_refill() fails. The CQE is pushed onto the
overflow list and IO_CHECK_CQ_OVERFLOW_BIT is set.

The wait loop in io_cqring_wait() relies on an invariant: refill() only
fails when the CQ is *physically* full, in which case rings->cq.tail has
been advanced to iowq->cq_tail and io_should_wake() returns true. The
tampered head breaks this: refill() fails while the ring is not full, no
OCQE is copied in, rings->cq.tail never catches up, io_should_wake()
stays false, and io_cqring_wait_schedule() keeps returning early because
IO_CHECK_CQ_OVERFLOW_BIT is still set. The result is a tight retry loop
that never returns to userspace.

Introduce io_cqring_queued() as the single point that converts the
(tail, head) pair into a trustworthy queued count. Since the real
head/tail distance is bounded by cq_entries (far below 2^31), a signed
comparison reliably detects userspace moving head past tail; in that
case treat the queue as empty so callers see the full cache as free and
forward progress is preserved.

Suggested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Zizhi Wo <wozizhi@huawei.com>
Link: https://patch.msgid.link/20260514021847.4062782-1-wozizhi@huaweicloud.com
[axboe: fixup commit message, kill 'queued' var, and keep it all in
io_uring.c]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record: Subsystem `io_uring`; action verb `validate`; intent is to
validate a user-controlled CQ head value used by
`io_cqe_cache_refill()`.

Record: Tags found: `Suggested-by: Jens Axboe`, `Signed-off-by: Zizhi
Wo`, `Link: https://patch.msgid.link/20260514021847.4062782-1-
wozizhi@huaweicloud.com`, maintainer edit note from Jens, `Signed-off-
by: Jens Axboe`. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-
by`, or `Cc: stable` tags were present.

Record: The commit describes a fuzzed, reproducible user-visible
failure: an `io_uring` task spins at about 100% CPU inside
`io_cqring_wait()`, never returns to userspace, and ignores `SIGKILL`.
Root cause is that userspace can write `rings->cq.head`; if it advances
`head` past the kernel-private `ctx->cached_cq_tail`, unsigned
subtraction wraps, `io_cqe_cache_refill()` sees no free space, overflow
stays set, and the wait loop keeps retrying.

Record: This is not hidden cleanup. It is an explicit bug fix for a
userspace-triggerable livelock/unkillable task.

## Phase 2: Diff Analysis
Record: One file changed: `io_uring/io_uring.c`, 17 insertions and 5
deletions. Modified/added functions: new `io_cqring_queued()`, modified
`io_fill_nop_cqe()`, modified `io_cqe_cache_refill()`. Scope is a
single-file surgical fix.

Record: Before, free CQ space was computed as `ctx->cq_entries -
min(__io_cqring_events(ctx), ctx->cq_entries)`, where
`__io_cqring_events()` is `cached_cq_tail - user_head`. If `user_head >
cached_cq_tail`, that unsigned subtraction wraps and is clamped to
`cq_entries`, making `free` zero.

Record: After, `io_cqring_queued()` casts the tail-head difference to
signed `int`; non-negative values are clamped to `cq_entries`, while
negative values are treated as zero queued entries. `io_fill_nop_cqe()`
uses the same trusted queued-count helper.

Record: Bug category is logic/correctness with user-controlled index
validation failure, causing an overflow-path livelock. It is not a
feature, API, refactor, or hardware enablement.

Record: Fix quality is good: for valid rings it preserves existing
behavior; for invalid `head > tail` it chooses forward progress.
Regression risk is low because the helper is local and affects only CQ
free-space calculation. The only semantic change is for corrupted user
CQ head state.

## Phase 3: Git History Investigation
Record: `git blame` shows the affected free-space calculation in
`io_cqe_cache_refill()` comes from `faf88dde060f74` (`io_uring: don't
inline __io_get_cqe()`), first contained in `v6.0-rc1~181^2~85`. The
overflow ordering guard comes from `aa1df3a360a0c5` (`io_uring: fix CQE
reordering`), first contained in `v6.1-rc1~135^2~10`. The later
`cqe32`/NOP path comes from `e26dca67fde19`, first contained in
`v6.18-rc1~137^2~45`.

Record: No `Fixes:` tag is present, so there was no tagged introducing
commit to follow.

Record: Recent file history shows multiple `io_uring` fixes around
CQ/ring handling, including `61a11cf481272` protecting lockless
`ctx->rings` accesses and `a7d755ed9ce97` fixing overflow CQE
reordering. No prerequisite specific to this helper was identified.

Record: Author Zizhi Wo has other kernel commits, but no recent local
`io_uring` commits found. Jens Axboe is the `IO_URING` maintainer in
`MAINTAINERS` and applied the final patch with edits.

Record: Dependencies: the fix depends only on existing
`ctx->cached_cq_tail`, `ctx->cq_entries`, `READ_ONCE(rings->cq.head)`,
and `min()`. It can be backported standalone, though older stable trees
need context adjustment because the exact function signature and file
layout differ.

## Phase 4: Mailing List And External Research
Record: `b4 dig -c f44d38a31f1802b7222adaea9ee69f9d280f698a` found the
original v2 submission at `https://patch.msgid.link/20260514021847.40627
82-1-wozizhi@huaweicloud.com`.

Record: `b4 dig -a` found v1 and v2. v1 was
`20260513063254.1122354-1-wozizhi@huaweicloud.com`; v2 was the submitted
version that matches the final fix concept. Jens reviewed v1 and said
snapshotting `tail` before a possible NOP fill looked wrong, and noted
the refill path had the same unsigned issue. v2 addressed this by
introducing a helper used by both paths.

Record: `b4 dig -w` showed the right recipients: Jens Axboe, Pavel
Begunkov, `io-uring@vger.kernel.org`, `linux-kernel@vger.kernel.org`,
and related Huawei contacts.

Record: The v2 mbox shows Jens applied it and then further edited it by
moving the helper into `io_uring.c`, removing the now-unused `queued`
variable, and trimming the comments/message. No NAK was found. No stable
nomination was found in the fetched thread.

Record: WebFetch access to lore search pages and git.kernel.org was
blocked by Anubis, so stable-list web search could not be verified
through WebFetch. Local `git log --grep` on sampled stable branches
found no existing exact stable commit.

## Phase 5: Code Semantic Analysis
Record: Key functions: `io_cqring_queued()`, `io_fill_nop_cqe()`,
`io_cqe_cache_refill()`.

Record: Callers: `io_cqe_cache_refill()` is called by
`io_get_cqe_overflow()` in `io_uring/io_uring.h`, which feeds normal CQE
posting, auxiliary CQEs, request completions, multishot completions,
message-ring completions, and overflow flushing. `io_cqring_wait()` is
reached from `SYSCALL_DEFINE6(io_uring_enter)` when
`IORING_ENTER_GETEVENTS` is used.

Record: Callees/side effects: the affected code reads the user-writable
CQ head, computes queue occupancy/free space, sets
`ctx->cqe_cached`/`ctx->cqe_sentinel`, and decides whether completions
go directly to the CQ ring or the overflow list.

Record: Reachability is verified from userspace through
`io_uring_enter()`. The provided reproduction ran as root; unprivileged
triggerability was not independently verified, but the affected state is
controlled by the userspace owner of the mmaped CQ ring.

Record: Similar pattern found: `__io_cqring_events()` in current code
and stable branches computes `cached_cq_tail - READ_ONCE(cq.head)`, so
the unsigned wrap condition is real in the relevant code paths.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Record: The buggy free-space logic exists in sampled stable trees:
`stable/linux-6.1.y` has it in `__io_get_cqe()`, and
`stable/linux-6.6.y`, `stable/linux-6.12.y`, `stable/linux-6.18.y`, and
`stable/linux-6.19.y` have it in `io_cqe_cache_refill()` or equivalent.
The specific min/free logic was introduced for v6.0-rc1, so v6.1+ stable
trees are affected.

Record: `stable/linux-5.15.y` has an older `io_get_cqe()` form using
`__io_cqring_events(ctx) == ctx->cq_entries`, not the same `min(tail -
head, cq_entries)` free-space calculation. I did not verify that the
exact livelock fixed here applies to 5.15, so this decision is driven by
verified v6.1+ evidence.

Record: Expected backport difficulty: low to moderate. 6.18/6.19 are
close but may lack the exact split into `wait.c`/`wait.h` seen in
current 7.0; 6.6/6.12 need a smaller adaptation because there is no
`cqe32`/NOP path; 6.1 needs the helper folded into the older
`__io_get_cqe()` path. The semantic fix is standalone.

Record: No related fix already present was found by exact subject search
in sampled stable branches.

## Phase 7: Subsystem And Maintainer Context
Record: Subsystem is `io_uring`, a core async I/O userspace API.
Criticality is IMPORTANT/CORE-adjacent because it is syscall reachable
and used by databases, storage/network software, runtimes, and fuzzers.

Record: Subsystem activity is high: recent local history shows many
`io_uring` fixes and refactors. The patch was handled by Jens Axboe,
listed maintainer for `IO_URING`.

## Phase 8: Impact And Risk Assessment
Record: Affected users are systems using `io_uring`; trigger requires a
userspace process manipulating its CQ head and waiting for completions.
The reproduction is a fuzzing/stress case with direct userspace control
of the mapped CQ ring.

Record: Trigger likelihood is not “everyday normal app behavior”, but it
is syscall/userspace reachable and can create an unkillable high-CPU
task. Unprivileged triggerability was not independently verified beyond
normal `io_uring` userspace reachability.

Record: Failure mode is HIGH severity: livelock/tight retry loop, 100%
CPU, no return to userspace, and `SIGKILL` ineffective per the commit
and mailing-list patch.

Record: Benefit is high for affected stable trees because it prevents a
userspace-triggered unkillable task. Risk is low because the change is
small, local, and only changes behavior for invalid user-controlled CQ
head state. Risk/benefit strongly favors backporting.

## Phase 9: Final Synthesis
Record: Evidence for backporting: real fuzzed bug; clear root cause;
userspace-reachable path; severe livelock/unkillable task; small local
fix; maintainer-reviewed evolution from v1 to v2; final maintainer-
applied version; verified affected code in v6.1+ stable branches.

Record: Evidence against backporting: no explicit `Cc: stable`, no
`Fixes:` tag, no `Tested-by`, and exact patch may need small branch-
specific backport adjustments. These are not enough to outweigh the
verified bug severity and small fix.

Record: Unresolved questions: exact applicability to 5.15 was not
established; exact clean-apply status on each stable branch was not
tested; unprivileged triggerability beyond ordinary userspace `io_uring`
access was not independently proven.

Stable rules checklist:
1. Obviously correct and tested: mostly yes by inspection and maintainer
   review; no explicit `Tested-by` and no local runtime test.
2. Fixes a real bug: yes, fuzzed livelock/unkillable task.
3. Important issue: yes, high-severity CPU spin and unkillable wait.
4. Small and contained: yes, one file, 17 insertions and 5 deletions.
5. No new feature/API: yes, static helper only.
6. Can apply to stable: yes with likely minor backport adjustments for
   older branches.

Exception category: none; this is a direct bug fix, not a device ID,
quirk, DT, build, or documentation exception.

Decision: backport to affected stable trees, especially v6.1+ where the
buggy free-space calculation was verified. Avoid claiming 5.15 without a
separate targeted analysis/backport.

## Verification
- [Phase 1] Parsed commit object
  `f44d38a31f1802b7222adaea9ee69f9d280f698a` with `git show`; confirmed
  subject, tags, and 17/5 diffstat.
- [Phase 2] Inspected the candidate diff with `git show`; confirmed new
  `io_cqring_queued()` and replacements in `io_fill_nop_cqe()` and
  `io_cqe_cache_refill()`.
- [Phase 3] Ran `git blame` on affected lines; confirmed key code came
  from `faf88dde060f74`, `aa1df3a360a0c5`, and `e26dca67fde19`.
- [Phase 3] Ran `git describe --contains`; confirmed first containment
  around v6.0-rc1, v6.1-rc1, and v6.18-rc1 respectively.
- [Phase 4] Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; confirmed
  v1/v2 patch history, recipients, and maintainer involvement.
- [Phase 4] Fetched v1/v2 mboxes with `b4 mbox`; confirmed Jens’ v1
  concern and v2 application with edits.
- [Phase 5] Used `rg` and file reads to trace `io_cqe_cache_refill()`
  through CQE posting and `io_uring_enter()`/`IORING_ENTER_GETEVENTS`.
- [Phase 6] Checked stable branches with `git blame`; verified affected
  logic in sampled v6.1, v6.6, v6.12, v6.18, and v6.19 branches.
- [Phase 7] Checked `MAINTAINERS`; verified Jens Axboe is listed
  maintainer for `IO_URING`.
- [Phase 8] Verified failure mode from commit message and mailing-list
  patch body; did not independently run the fuzzer or reproducer.
- UNVERIFIED: exact clean apply on every stable tree, exact
  applicability to 5.15, and unprivileged triggerability.

**YES**

 io_uring/io_uring.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index a72efb3a62bac..431d157e81595 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -680,13 +680,27 @@ static struct io_overflow_cqe *io_alloc_ocqe(struct io_ring_ctx *ctx,
 	return ocqe;
 }
 
+/*
+ * Compute queued CQEs for free-space calculation, clamped to cq_entries.
+ */
+static unsigned int io_cqring_queued(struct io_ring_ctx *ctx)
+{
+	struct io_rings *rings = io_get_rings(ctx);
+	int diff;
+
+	diff = (int)(ctx->cached_cq_tail - READ_ONCE(rings->cq.head));
+	if (diff >= 0)
+		return min((unsigned int)diff, ctx->cq_entries);
+	return 0;
+}
+
 /*
  * Fill an empty dummy CQE, in case alignment is off for posting a 32b CQE
  * because the ring is a single 16b entry away from wrapping.
  */
 static bool io_fill_nop_cqe(struct io_ring_ctx *ctx, unsigned int off)
 {
-	if (__io_cqring_events(ctx) < ctx->cq_entries) {
+	if (io_cqring_queued(ctx) < ctx->cq_entries) {
 		struct io_uring_cqe *cqe = &ctx->rings->cqes[off];
 
 		cqe->user_data = 0;
@@ -707,7 +721,7 @@ bool io_cqe_cache_refill(struct io_ring_ctx *ctx, bool overflow, bool cqe32)
 {
 	struct io_rings *rings = ctx->rings;
 	unsigned int off = ctx->cached_cq_tail & (ctx->cq_entries - 1);
-	unsigned int free, queued, len;
+	unsigned int free, len;
 
 	/*
 	 * Posting into the CQ when there are pending overflowed CQEs may break
@@ -727,9 +741,7 @@ bool io_cqe_cache_refill(struct io_ring_ctx *ctx, bool overflow, bool cqe32)
 		off = 0;
 	}
 
-	/* userspace may cheat modifying the tail, be safe and do min */
-	queued = min(__io_cqring_events(ctx), ctx->cq_entries);
-	free = ctx->cq_entries - queued;
+	free = ctx->cq_entries - io_cqring_queued(ctx);
 	/* we need a contiguous range, limit based on the current array offset */
 	len = min(free, ctx->cq_entries - off);
 	if (len < (cqe32 + 1))
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] platform/x86: asus-nb-wmi: add DMI quirk for ASUS Zenbook Duo UX8407AA

[Sasha Levin]

From: Paolo Pisati <p.pisati@gmail.com>

[ Upstream commit 2997606dd17729404cef9821ce66dd037b6019eb ]

Use the existing zenbook duo keyboard quirk for the UX8407AA model too.

Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
Reviewed-by: Denis Benato <denis.benato@linux.dev>
Link: https://patch.msgid.link/20260508070956.62201-1-p.pisati@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `platform/x86: asus-nb-wmi`; action verb
`add`; intent is to add a DMI match for `ASUS Zenbook Duo UX8407AA` to
reuse an existing Zenbook Duo keyboard quirk.

Step 1.2 Record: Tags found: `Signed-off-by: Paolo Pisati`, `Reviewed-
by: Denis Benato`, `Link:
https://patch.msgid.link/20260508070956.62201-1-p.pisati@gmail.com`,
`Reviewed-by: Ilpo Järvinen`, `Signed-off-by: Ilpo Järvinen`. No
`Fixes:` tag and no explicit stable tag in the commit.

Step 1.3 Record: The commit body says only: “Use the existing zenbook
duo keyboard quirk for the UX8407AA model too.” The underlying quirk was
verified in local history: it suppresses spurious WLAN key events on
Zenbook Duo keyboards, avoiding unintended wireless/rfkill behavior.

Step 1.4 Record: This is a hardware quirk addition, not disguised
cleanup. It fixes model-specific behavior by making an already-existing
workaround apply to another DMI-identified ASUS model.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `drivers/platform/x86/asus-nb-wmi.c`,
9 insertions, no removals. Modified area: `asus_quirks[]` DMI table.
Scope: single-file surgical hardware quirk.

Step 2.2 Record: Before, UX8407AA did not match `asus_quirks[]`, so
`quirk_asus_zenbook_duo_kbd` was not selected for that model. After,
matching DMI vendor/product strings select `quirk_asus_zenbook_duo_kbd`.

Step 2.3 Record: Bug category is hardware workaround/DMI quirk. Verified
quirk behavior: `quirk_asus_zenbook_duo_kbd` sets `key_wlan_event =
ASUS_WMI_KEY_IGNORE`; `asus_nb_wmi_key_filter()` maps WMI codes `0x5D`,
`0x5E`, and `0x5F` to that quirk value when set; without the quirk,
those codes remain `KEY_WLAN` events.

Step 2.4 Record: Fix quality is high: 9-line DMI table entry, no new
API, no shared logic change. Regression risk is very low and limited to
systems whose DMI strings match `DMI_SYS_VENDOR=ASUS` and
`DMI_PRODUCT_NAME=Zenbook Duo UX8407AA`.

## Phase 3: Git History Investigation
Step 3.1 Record: Blame around the table showed the existing UX8406MA
quirk entry came from `9286dfd5735b` and UX8406CA from `7dc6b2d3b550`.
Blame of the quirk definition showed `quirk_asus_zenbook_duo_kbd` was
introduced by `9286dfd5735b`, later converted to `key_wlan_event =
ASUS_WMI_KEY_IGNORE` by `132bfcd24925`.

Step 3.2 Record: No `Fixes:` tag is present, so there is no introducer
tag to follow.

Step 3.3 Record: Recent related history includes `9286dfd5735b` fixing
spurious rfkill on UX8406MA, `7dc6b2d3b550` adding UX8406CA, and later
key handling fixes `132bfcd24925` and `225d1ee0f5ba`. The candidate is
standalone where `quirk_asus_zenbook_duo_kbd` exists.

Step 3.4 Record: `git log --author="Paolo Pisati" -10 --
drivers/platform/x86` showed no prior local platform-x86 commits by this
author. The patch was reviewed by Denis Benato and Ilpo Järvinen; Ilpo
committed it.

Step 3.5 Record: Dependency is the existing Zenbook Duo keyboard quirk.
Verified present in releases `v6.12` and newer in this repo; absent from
`v6.6`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 2997606dd17729404cef9821ce66dd037b6019eb`
found the exact lore thread at the patch message-id URL. `b4 dig -a`
showed only v1, so no newer revision was found.

Step 4.2 Record: `b4 dig -w` showed recipients included Corentin Chary,
Luke D. Jones, Denis Benato, Hans de Goede, Ilpo Järvinen, and
`platform-driver-x86@vger.kernel.org`. The patch received `Reviewed-by`
from Denis Benato and Ilpo Järvinen.

Step 4.3 Record: No separate bug report or `Reported-by` tag was found
in the commit. The b4-fetched thread contained Denis’s review and Ilpo’s
applied notice, but no detailed user report.

Step 4.4 Record: No multi-patch series; b4 identified this as a single-
patch v1 series. Related local commits are the previous Zenbook Duo
quirk additions and key handling corrections.

Step 4.5 Record: Direct `WebFetch` searches on lore/stable were blocked
by Anubis. I could not verify stable-list discussion via WebFetch. `b4`
did successfully fetch the exact patch thread.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified data structure: `asus_quirks[]`. Existing
functions involved by flow: `dmi_matched()`, `asus_nb_wmi_quirks()`,
`asus_nb_wmi_key_filter()`, and `asus_wmi_handle_event_code()`.

Step 5.2 Record: `asus_nb_wmi_quirks()` is wired through
`.detect_quirks` in `asus_nb_wmi_driver`; `asus_wmi_add()` calls
`detect_quirks()` during driver probe. `asus_nb_wmi_key_filter()` is
wired through `.key_filter`; `asus_wmi_handle_event_code()` calls it
before reporting input events.

Step 5.3 Record: Key callees/operations: `dmi_check_system(asus_quirks)`
performs DMI matching; `dmi_matched()` assigns `quirks =
dmi->driver_data`; event handling calls `sparse_keymap_report_event()`
unless the filter changes the code to `ASUS_WMI_KEY_IGNORE`.

Step 5.4 Record: Reachability is from ASUS WMI platform driver probe and
ACPI/WMI event notifications on matching ASUS notebook hardware. This is
hardware/model-specific, not a general syscall-triggered path.

Step 5.5 Record: Similar patterns found: UX8406MA and UX8406CA already
use `quirk_asus_zenbook_duo_kbd`; ROG Z13 uses the same DMI table
pattern with vendor `ASUS`.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: `git grep` over tags showed
`quirk_asus_zenbook_duo_kbd` exists in `v6.12`, `v6.15`, `v6.16`,
`v6.17`, `v6.18`, `v6.19`, and `v7.0`; it was not present in `v6.1` or
`v6.6`. UX8406CA exists from `v6.16`; ROG Z13 context exists from
`v6.17`.

Step 6.2 Record: `git apply --check` against the current tree succeeded.
Expected backport difficulty: clean for trees with matching nearby
context; minor context adjustment for trees where UX8406CA or ROG Z13
entries are absent, but the quirk symbol exists.

Step 6.3 Record: No existing UX8407AA entry or related UX8407AA fix was
found in local `git log --grep="UX8407AA"`.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is `drivers/platform/x86`, ASUS notebook WMI
driver. Criticality: peripheral/driver-specific, affecting users of the
ASUS Zenbook Duo UX8407AA.

Step 7.2 Record: The subsystem and file are active: recent local history
includes multiple ASUS WMI quirk/keymap fixes and platform-x86 changes.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected population is driver-specific: users of ASUS
Zenbook Duo UX8407AA with `asus-nb-wmi`.

Step 8.2 Record: Trigger is hardware-specific WMI keyboard attach/detach
or wireless-console events. I verified the relevant event codes are
mapped as `KEY_WLAN` unless the quirk rewrites them to ignore.

Step 8.3 Record: Failure mode is unintended WLAN/rfkill-style input
events on this model. Severity is medium: user-visible connectivity
disruption, not a crash, data corruption, or security issue.

Step 8.4 Record: Benefit is high for affected hardware and low globally.
Risk is very low: a DMI-only quirk entry using existing behavior,
isolated to one model string.

## Phase 9: Final Synthesis
Evidence for backporting: this is exactly the stable-accepted hardware
quirk category; it is small, reviewed, isolated, uses existing code, and
fixes real model-specific input/rfkill behavior for affected hardware.

Evidence against backporting: no explicit `Cc: stable`, no separate bug
report in the thread, and older stable trees without
`quirk_asus_zenbook_duo_kbd` need prerequisites or are not applicable.

Stable rules checklist: obviously correct: yes; fixes real hardware
behavior: yes; important enough for affected users: yes, though not
critical; small and contained: yes, 9 insertions in one DMI table; no
new APIs/features: yes; applies to stable: yes for current tree, likely
minor context-only adjustments for some older applicable trees.

Exception category: hardware-specific DMI quirk/workaround, which is a
standard stable exception.

## Verification
- [Phase 1] Parsed commit metadata from `git show
  2997606dd17729404cef9821ce66dd037b6019eb`.
- [Phase 2] Verified diff is one DMI entry in
  `drivers/platform/x86/asus-nb-wmi.c`.
- [Phase 3] Ran `git blame` on the DMI table and quirk definition;
  identified existing quirk history.
- [Phase 3] Checked related commits `9286dfd5735b`, `7dc6b2d3b550`,
  `132bfcd24925`, `225d1ee0f5ba`.
- [Phase 4] Ran `b4 dig -c`, `b4 dig -a`, `b4 dig -w`; found exact v1
  patch thread and recipients.
- [Phase 4] Ran `b4 mbox`/`b4 am` by message-id; confirmed Denis review
  and Ilpo applied notice.
- [Phase 5] Used `rg` and file reads to trace `detect_quirks`,
  `key_filter`, and event reporting.
- [Phase 6] Used `git grep` over version tags to verify which releases
  contain the existing quirk machinery.
- [Phase 6] Ran `git apply --check`; candidate applies cleanly to the
  current tree.
- UNVERIFIED: Direct lore/stable search results, because WebFetch was
  blocked by Anubis.
- UNVERIFIED: Actual UX8407AA firmware DMI strings beyond the submitted
  patch and maintainer review.

This should be backported to stable trees where the existing Zenbook Duo
keyboard quirk is present, with trivial context adjustment if needed.

**YES**

 drivers/platform/x86/asus-nb-wmi.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index b4677c5bba5b4..8005c088e9eee 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -544,6 +544,15 @@ static const struct dmi_system_id asus_quirks[] = {
 		},
 		.driver_data = &quirk_asus_zenbook_duo_kbd,
 	},
+	{
+		.callback = dmi_matched,
+		.ident = "ASUS Zenbook Duo UX8407AA",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUS"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Zenbook Duo UX8407AA"),
+		},
+		.driver_data = &quirk_asus_zenbook_duo_kbd,
+	},
 	{
 		.callback = dmi_matched,
 		.ident = "ASUS ROG Z13",
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] powerpc/pseries/htmdump: Free the global buffers in htmdump module exit

[Sasha Levin]

From: Athira Rajeev <atrajeev@linux.ibm.com>

[ Upstream commit 54d54f33813d7911555226b4220737177a2ba8d6 ]

htmdump modules uses global memory buffers to capture
details like capabilities, status of specified HTM, read the
trace buffer. These are initialized during module init and
hence needs to be freed in module exit.

Patch adds freeing of the memory in module exit. The change
also includes minor clean up for the variable name. The
read call back for the debugfs interface file saves filp->private_data
to local variable name which is same as global variable
name for the memory buffers. Rename these local variable
names.

Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260314132432.25581-1-atrajeev@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Summary
This commit fixes a real resource leak in
`arch/powerpc/platforms/pseries/htmdump.c`: `htm_status_buf`,
`htm_info_buf`, and `htm_caps_buf` are each allocated with
`kmalloc(PAGE_SIZE, GFP_KERNEL)` during module/debugfs initialization,
but only `htm_buf` is freed in `htmdump_exit()`. The patch adds the
three missing `kfree()` calls. The local-variable renames are cleanup
and are also used by the following two patches in the same posted
series.

The benefit is modest because the leak is on module unload, not a hot
path, and the feature is PowerPC pseries/debugfs-specific. But it is a
real leak in a `default m` module, the fix is trivial, isolated, and low
risk. For stable trees that contain the v6.16-era `htmstatus`,
`htminfo`, and `htmcaps` additions, this is suitable.

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record 1.1: Subsystem is `powerpc/pseries/htmdump`; action verb is
`Free`; claimed intent is freeing global HTM debugfs buffers during
module exit.

Record 1.2: Tags in the supplied commit message: `Signed-off-by: Athira
Rajeev <atrajeev@linux.ibm.com>`, `Signed-off-by: Madhavan Srinivasan
<maddy@linux.ibm.com>`, `Link:
https://patch.msgid.link/20260314132432.25581-1-atrajeev@linux.ibm.com`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
or `Cc: stable@vger.kernel.org` tag was present in this commit.

Record 1.3: The body describes global memory buffers initialized in
module init and not freed in module exit. The user-visible symptom is
unreclaimed kernel memory after unloading the module. No crash, stack
trace, reporter, affected-version statement, or reproducer is given.

Record 1.4: This is a hidden cleanup-style bug fix: the functional
change is missing resource release on module exit.

### Phase 2: Diff Analysis
Record 2.1: One file changed:
`arch/powerpc/platforms/pseries/htmdump.c`, 17 insertions and 14
deletions in the posted patch. Modified functions are `htmdump_read()`,
`htmstatus_read()`, `htminfo_read()`, `htmcaps_read()`, and
`htmdump_exit()`. Scope is single-file surgical.

Record 2.2: The read-callback hunks rename local variables from names
shadowing globals to `*_data`; behavior is unchanged. The exit hunk
changes `htmdump_exit()` from freeing only `htm_buf` to freeing
`htm_buf`, `htm_status_buf`, `htm_info_buf`, and `htm_caps_buf`.

Record 2.3: Bug category is resource leak. Verified allocations are
three `PAGE_SIZE` buffers for status/info/caps in
`htmdump_init_debugfs()` without corresponding frees before this patch.

Record 2.4: Fix quality is high: `kfree(NULL)` is safe, the buffers are
global module-owned allocations, and debugfs removal already happens
before freeing. Regression risk is very low. The only non-functional
churn is local-variable rename.

### Phase 3: Git History Investigation
Record 3.1: `git blame` on the current stable checkout points the
relevant lines at the repository boundary merge `f3f5edc5e41e0`, so I
followed explicit commit objects. `htm_status_buf` was added by
`627cf584f4c3`, `htm_info_buf` by `dea7384e14e7`, and `htm_caps_buf` by
`143a2584627c`, all described by `git describe --contains`/history as
v6.16-rc1-era commits.

Record 3.2: Candidate has no `Fixes:` tag, so no direct Fixes target
applies. Related series patches 2/3 and 3/3 have `Fixes:` tags for
`dea7384e14e7` and `627cf584f4c3`, but this patch does not depend on
those fixes.

Record 3.3: Recent `htmdump` history shows the v6.16 additions for
status/info/setup/flags/caps and a header include fix. The candidate is
patch 1/3 in a series; patch 1 is standalone, while patches 2/3 and 3/3
textually build on its variable renames.

Record 3.4: Author Athira Rajeev authored the original htmdump expansion
commits; Madhavan Srinivasan committed them. This was verified from `git
show` for the status/info/caps commits.

Record 3.5: No prerequisite is needed for patch 1 beyond the buffers
existing. An isolated `git apply --check` of patch 1 succeeds on the
current 7.0 stable checkout.

### Phase 4: Mailing List And External Research
Record 4.1: `b4 dig` could not be meaningfully run because the candidate
commit object/hash is not present in the checked-out refs; `b4 dig -h`
confirmed it requires `-c <commitish>`. I used `b4 mbox -c` with
message-id `20260314132432.25581-1-atrajeev@linux.ibm.com`; it fetched a
3-message thread and reported no newer revision.

Record 4.2: Original recipients from the mbox were
`maddy@linux.ibm.com`, `linuxppc-dev@lists.ozlabs.org`, and CCs
including `hbathini`, `sshegde`, and IBM HTM-related recipients. No
review replies, NAKs, or stable nominations were present in the fetched
mbox.

Record 4.3: No `Reported-by` or bug-report link exists for this
candidate. `WebFetch` to lore/patch.msgid was blocked by Anubis, but `b4
mbox` successfully fetched the thread.

Record 4.4: The patch is part of a 3-patch series. Patch 1 fixes exit
cleanup; patch 2 fixes `htminfo_read()` offset handling; patch 3 fixes
`htmstatus_read()` offset handling. Patch 1 can apply standalone, and
later patches depend textually on its renames.

Record 4.5: Stable-specific lore WebFetch was blocked by Anubis.
WebSearch for the exact subject and stable context found no specific
stable discussion. Local `git log --grep` checks of `v6.18`, `v6.19`,
`v7.0`, and `linux-rolling-stable` found no exact-subject match.

### Phase 5: Code Semantic Analysis
Record 5.1: Modified functions are `htmdump_read()`, `htmstatus_read()`,
`htminfo_read()`, `htmcaps_read()`, and `htmdump_exit()`.

Record 5.2: Callers/entry points are verified through file operations
and module macros: `htmdump_exit()` is registered with `module_exit()`,
reads are reached through debugfs files created by
`debugfs_create_file()` with the corresponding fops.

Record 5.3: Key callees are `debugfs_remove_recursive()`, `kfree()`,
`htm_hcall_wrapper()`, `virt_to_phys()`, and
`simple_read_from_buffer()`. The functional fix only adds `kfree()`
calls in exit.

Record 5.4: Reachability is module lifecycle and debugfs based. The leak
triggers on module unload after successful allocation of the
status/info/caps buffers. Unprivileged triggering was not verified and
is not relied on; Kconfig shows `HTMDUMP` is `tristate`, `default m`,
and depends on `PPC_PSERIES && DEBUG_FS`.

Record 5.5: Similar pattern found: `htm_buf` was already freed in
`htmdump_exit()`, while the three later-added global buffers were not.

### Phase 6: Stable Tree Analysis
Record 6.1: `v6.15` has `htmdump.c` with only `htm_buf`; `v6.16`,
`v6.17`, `v6.18`, `v6.19`, and `v7.0` have the three additional buffers
and only free `htm_buf`. So the bug affects stable trees containing the
v6.16 htmdump expansions, not older trees lacking those buffers.

Record 6.2: Backport difficulty is low for affected trees. The patch’s
base blob matches `v6.16`/`v6.17`/current 7.0 content for the relevant
file, and isolated patch 1 applies cleanly to the current checkout.

Record 6.3: No exact-subject related fix was found in checked `v6.18`,
`v6.19`, `v7.0`, or `linux-rolling-stable`.

### Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is PowerPC pseries platform driver/debugfs
support. Criticality is peripheral/platform-specific, not core kernel-
wide.

Record 7.2: `git log -20 v7.0 -- arch/powerpc/platforms/pseries` shows
active pseries development, but this particular fix is contained to
`htmdump.c`.

### Phase 8: Impact And Risk
Record 8.1: Affected users are PowerPC pseries users with
`CONFIG_HTMDUMP` enabled, primarily using the debugfs HTM dump module.

Record 8.2: Trigger is successful module initialization followed by
module exit/unload. Repeated load/unload can accumulate unreclaimed
pages until reboot. This is not verified as unprivileged-triggerable.

Record 8.3: Failure mode is kernel memory/resource leak, three
`PAGE_SIZE` allocations per unload for the later buffers. Severity is
medium: real and persistent until reboot, but not a crash/security/data-
corruption fix and not a hot path.

Record 8.4: Benefit is moderate for affected stable users; risk is very
low because the functional change is only three `kfree()` calls after
debugfs removal.

### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: real resource leak, affects stable
trees v6.16 and newer that contain the expanded htmdump module, fix is
tiny and obviously correct, isolated patch applies cleanly. Evidence
against: peripheral platform-specific module, leak occurs on module
unload rather than common runtime path, no reporter/testing/stable tags
in this patch. Unresolved: no full lore review discussion was available
beyond the 3-patch mbox; direct WebFetch lore pages were blocked.

Record 9.2: Stable rules checklist: obviously correct yes; fixes a real
bug yes; important enough is borderline but acceptable as a real
resource leak with very low regression risk; small and contained yes; no
new feature/API yes; applies to affected stable trees yes for current
7.0 and likely cleanly where file matches v6.16+.

Record 9.3: No automatic exception category applies: this is not a
device ID, quirk, DT update, build fix, or documentation-only fix.

Record 9.4: Decision is YES for stable trees that contain
`htm_status_buf`, `htm_info_buf`, and `htm_caps_buf`.

## Verification
- Phase 1: Parsed supplied commit message and b4-fetched patch 1;
  confirmed no `Fixes:`, `Reported-by`, `Tested-by`, review, or stable
  tag in patch 1.
- Phase 2: Read `arch/powerpc/platforms/pseries/htmdump.c`; confirmed
  allocations and missing frees; inspected patch hunks from
  `/tmp/htmdump-20260314.mbx`.
- Phase 3: Ran `git blame -L 410,485`; followed explicit commits
  `627cf584f4c3`, `dea7384e14e7`, and `143a2584627c` with `git show`;
  checked author/subsystem history.
- Phase 4: `b4 mbox -c` fetched the 3-message thread; direct `WebFetch`
  lore URLs were blocked; WebSearch found no exact stable discussion.
- Phase 5: Used `rg`, `ReadFile`, and Kconfig/Makefile/docs to verify
  module/debugfs reachability and `CONFIG_HTMDUMP` as `tristate`,
  `default m`.
- Phase 6: Checked `v6.15`, `v6.16`, `v6.17`, `v6.18`, `v6.19`, and
  `v7.0` file contents; isolated patch 1 passed `git apply --check`.
- Phase 8: Verified failure mode from concrete `kmalloc(PAGE_SIZE)`
  allocations and missing matching `kfree()` calls.
- Unverified: whether every downstream stable branch has identical
  context; direct stable-list lore search was blocked by Anubis.

**YES**

 arch/powerpc/platforms/pseries/htmdump.c | 31 +++++++++++++-----------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/htmdump.c b/arch/powerpc/platforms/pseries/htmdump.c
index 742ec52c9d4df..93f0cc2dc7fb6 100644
--- a/arch/powerpc/platforms/pseries/htmdump.c
+++ b/arch/powerpc/platforms/pseries/htmdump.c
@@ -86,7 +86,7 @@ static ssize_t htm_return_check(long rc)
 static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_buf = filp->private_data;
+	void *htm_buf_data = filp->private_data;
 	unsigned long page, read_size, available;
 	loff_t offset;
 	long rc, ret;
@@ -100,7 +100,7 @@ static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
 	 * - last three values are address, size and offset
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_DUMP_DATA, virt_to_phys(htm_buf),
+				   htmtype, H_HTM_OP_DUMP_DATA, virt_to_phys(htm_buf_data),
 				   PAGE_SIZE, page);
 
 	ret = htm_return_check(rc);
@@ -112,7 +112,7 @@ static ssize_t htmdump_read(struct file *filp, char __user *ubuf,
 	available = PAGE_SIZE;
 	read_size = min(count, available);
 	*ppos += read_size;
-	return simple_read_from_buffer(ubuf, count, &offset, htm_buf, available);
+	return simple_read_from_buffer(ubuf, count, &offset, htm_buf_data, available);
 }
 
 static const struct file_operations htmdump_fops = {
@@ -226,7 +226,7 @@ static int htmstart_get(void *data, u64 *val)
 static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_status_buf = filp->private_data;
+	void *htm_status_data = filp->private_data;
 	long rc, ret;
 	u64 *num_entries;
 	u64 to_copy;
@@ -238,7 +238,7 @@ static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
 	 * - last three values as addr, size and offset
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_STATUS, virt_to_phys(htm_status_buf),
+				   htmtype, H_HTM_OP_STATUS, virt_to_phys(htm_status_data),
 				   PAGE_SIZE, 0);
 
 	ret = htm_return_check(rc);
@@ -255,13 +255,13 @@ static ssize_t htmstatus_read(struct file *filp, char __user *ubuf,
 	 * So total count to copy is:
 	 * 32 bytes (for first 7 fields) + (number of HTM entries * entry size)
 	 */
-	num_entries = htm_status_buf + 0x10;
+	num_entries = htm_status_data + 0x10;
 	if (htmtype == 0x2)
 		htmstatus_flag = 0x8;
 	else
 		htmstatus_flag = 0x6;
 	to_copy = 32 + (be64_to_cpu(*num_entries) * htmstatus_flag);
-	return simple_read_from_buffer(ubuf, count, ppos, htm_status_buf, to_copy);
+	return simple_read_from_buffer(ubuf, count, ppos, htm_status_data, to_copy);
 }
 
 static const struct file_operations htmstatus_fops = {
@@ -273,7 +273,7 @@ static const struct file_operations htmstatus_fops = {
 static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_info_buf = filp->private_data;
+	void *htm_info_data = filp->private_data;
 	long rc, ret;
 	u64 *num_entries;
 	u64 to_copy;
@@ -284,7 +284,7 @@ static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
 	 * - last three values as addr, size and offset
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_DUMP_SYSPROC_CONF, virt_to_phys(htm_info_buf),
+				   htmtype, H_HTM_OP_DUMP_SYSPROC_CONF, virt_to_phys(htm_info_data),
 				   PAGE_SIZE, 0);
 
 	ret = htm_return_check(rc);
@@ -301,15 +301,15 @@ static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
 	 * So total count to copy is:
 	 * 32 bytes (for first 5 fields) + (number of HTM entries * entry size)
 	 */
-	num_entries = htm_info_buf + 0x10;
+	num_entries = htm_info_data + 0x10;
 	to_copy = 32 + (be64_to_cpu(*num_entries) * 16);
-	return simple_read_from_buffer(ubuf, count, ppos, htm_info_buf, to_copy);
+	return simple_read_from_buffer(ubuf, count, ppos, htm_info_data, to_copy);
 }
 
 static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
 			     size_t count, loff_t *ppos)
 {
-	void *htm_caps_buf = filp->private_data;
+	void *htm_caps_data = filp->private_data;
 	long rc, ret;
 
 	/*
@@ -319,7 +319,7 @@ static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
 	 *   and zero
 	 */
 	rc = htm_hcall_wrapper(htmflags, nodeindex, nodalchipindex, coreindexonchip,
-				   htmtype, H_HTM_OP_CAPABILITIES, virt_to_phys(htm_caps_buf),
+				   htmtype, H_HTM_OP_CAPABILITIES, virt_to_phys(htm_caps_data),
 				   0x80, 0);
 
 	ret = htm_return_check(rc);
@@ -328,7 +328,7 @@ static ssize_t htmcaps_read(struct file *filp, char __user *ubuf,
 		return ret;
 	}
 
-	return simple_read_from_buffer(ubuf, count, ppos, htm_caps_buf, 0x80);
+	return simple_read_from_buffer(ubuf, count, ppos, htm_caps_data, 0x80);
 }
 
 static const struct file_operations htminfo_fops = {
@@ -482,6 +482,9 @@ static void __exit htmdump_exit(void)
 {
 	debugfs_remove_recursive(htmdump_debugfs_dir);
 	kfree(htm_buf);
+	kfree(htm_status_buf);
+	kfree(htm_info_buf);
+	kfree(htm_caps_buf);
 }
 
 module_init(htmdump_init);
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] HID: sony: add missing size validation for SMK-Link remotes

[Sasha Levin]

From: Rosalie Wanders <rosalie@mailbox.org>

[ Upstream commit a4170b63eda999d20ad6dc39ddc3ce5c1ac619e6 ]

This commit adds the missing size validation for SMK-Link remotes in
sony_raw_event(), this prevents a malicious device from allowing
hid-sony to read out of bounds of the provided buffer.

I do not own these devices so the size check only forces that the buffer
is large enough for nsg_mrxu_parse_report().

Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

Phase 1, commit message forensics. Record: subsystem `HID: sony`; action
`add`; intent is missing size validation for SMK-Link remotes. Tags
present: `Signed-off-by: Rosalie Wanders`, `Signed-off-by: Jiri Kosina`;
no `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable`. Body says a malicious device can make `hid-
sony` read beyond the provided buffer in `sony_raw_event()`. This is a
direct memory-safety bug, not a hidden cleanup.

Phase 2, diff analysis. Record: one file, `drivers/hid/hid-sony.c`, 2
insertions and 3 deletions; only `sony_raw_event()` changes. Before: any
`NSG_MRXU_REMOTE` report with `rd[0] == 0x02` called
`nsg_mrxu_parse_report()`. After: it only does so when `size >= 12`.
`nsg_mrxu_parse_report()` reads through `rd[11]`, including `rd[offset +
10]` with `offset = 1`, so the minimum size is verified by code. Bug
category: bounds check / out-of-bounds read. Fix quality: surgical and
obviously correct; the only behavioral change is rejecting malformed
short reports before parsing.

Phase 3, git history. Record: upstream commit is
`a4170b63eda999d20ad6dc39ddc3ce5c1ac619e6`, authored by Rosalie Wanders
and committed by HID maintainer Jiri Kosina. Blame shows the NSG-MRxU
parser and unchecked call were introduced by `b7289cb1cf99d` (`HID:
sony: Add touchpad support for NSG-MR5U and NSG-MR7U remotes`), first
described by `git describe` as `v4.17-rc1~118^2~2^2`. No `Fixes:` tag to
follow. Recent history shows an adjacent independent HID Sony size-
validation fix for Rock Band 3 Pro instruments, but no dependency for
this patch. Author has multiple recent `hid-sony` commits.

Phase 4, mailing list and external research. Record: `b4 dig -c
a4170b63eda99` found the exact lore submission at
`https://patch.msgid.link/20260412010806.7997-2-rosalie@mailbox.org`.
`b4 dig -a` showed only v1, no later revision. `b4 dig -w` showed Jiri
Kosina, Benjamin Tissoires, `linux-input`, and `linux-kernel` were
included. Full thread mbox shows Jiri replied: “Applied to
hid.git#for-7.1/upstream-fixes, thanks.” No NAKs, objections, explicit
stable request, or reviewer-suggested changes found. Direct WebFetch to
lore was blocked by Anubis, but `b4` fetched the thread successfully.

Phase 5, semantic analysis. Record: key functions are `sony_raw_event()`
and `nsg_mrxu_parse_report()`. `sony_raw_event()` is registered as the
HID driver `.raw_event` callback. HID core calls `.raw_event` from
`__hid_input_report()` before `hid_report_raw_event()`’s later report-
size validation, so driver-local parsing must validate `size` itself.
Lower HID layers such as USB HID call `hid_input_report()` with device-
provided lengths. `nsg_mrxu_parse_report()` is only called from
`sony_raw_event()` in this file. Similar pattern found: adjacent
upstream commit `12bd440b66ed8` adds a size check before another `rd[]`
access in the same function.

Phase 6, stable tree analysis. Record: the buggy NSG code exists in
checked stable branches `4.19.y`, `5.4.y`, `5.10.y`, `5.15.y`, `6.1.y`,
`6.6.y`, `6.12.y`, `6.18.y`, `6.19.y`, and `7.0.y`; `git merge-base
--is-ancestor b7289cb1cf99d4 <branch>` confirmed the introducing commit
is in each. Exact patch apply-check succeeded on `7.0.y`; older branches
failed exact context due file drift, but the required backport is a
trivial one-condition change at the same unchecked call site. No
existing stable branch log entry for this exact SMK-Link fix was found
in the checked branches.

Phase 7, subsystem context. Record: subsystem is HID input driver code,
specifically `drivers/hid/hid-sony.c`; criticality is driver-specific
but security-relevant for systems using or exposed to spoofed SMK-
Link/Sony HID devices. `MAINTAINERS` lists HID core as maintained by
Jiri Kosina and Benjamin Tissoires; Jiri committed and applied the
patch. The file has moderate recent activity, including HID Sony fixes
and device support work.

Phase 8, impact and risk. Record: affected users are `CONFIG_HID_SONY`
systems with SMK-Link NSG-MR5U/NSG-MR7U remote support, or systems that
accept a malicious/spoofed matching HID device. Trigger is a report with
ID byte `0x02` and length below 12. Failure mode is an out-of-bounds
read from the supplied report buffer; severity HIGH because it is
device-triggerable kernel memory-safety behavior. Benefit is high for
affected systems; risk is very low because valid reports of length >= 12
keep identical behavior and malformed short reports stop before unsafe
parsing.

Phase 9, synthesis. Evidence for backporting: real OOB read, malicious-
device trigger described in commit body, parser byte accesses verify the
needed bound, bug exists since v4.17-era code and is present in many
stable branches, fix is a one-line functional bounds check, maintainer
applied it to HID upstream fixes. Evidence against: no explicit `Tested-
by`, author says they do not own the hardware, and older stable trees
need a small context backport. Unresolved: no public crash report or
syzbot report found; no hardware test evidence found.

## Stable Rules

1. Obviously correct and tested: obviously correct by code inspection;
   no explicit `Tested-by` and no hardware ownership, but maintainer
   accepted it as an upstream fix.
2. Fixes a real bug: yes, verified unchecked parser reads up to
   `rd[11]`.
3. Important issue: yes, device-triggerable kernel out-of-bounds read.
4. Small and contained: yes, one function in one driver.
5. No new features/APIs: yes.
6. Can apply to stable: yes for `7.0.y` directly; older stable branches
   need trivial context adjustment.

No exception category is needed; this is a normal memory-safety fix.

## Verification

- Phase 1: parsed `git show a4170b63eda99`; confirmed tags and absence
  of `Fixes:`, reports, review, stable Cc.
- Phase 2: inspected diff and `nsg_mrxu_parse_report()`; confirmed
  `rd[11]` maximum access and added `size >= 12`.
- Phase 3: ran `git blame`, `git log -S`, `git show b7289cb1cf99d4`, and
  author history checks.
- Phase 4: ran `b4 dig -c`, `-a`, `-w`, `b4 am`, and full `b4 mbox`;
  confirmed v1-only thread and maintainer apply reply.
- Phase 5: used `rg` and `ReadFile` on HID core and `hid-sony`;
  confirmed `.raw_event` call path and lower-layer `hid_input_report()`
  entry.
- Phase 6: checked stable branch code, ancestry of `b7289cb1cf99d4`,
  exact apply-checks, and stable logs for this subject.
- Phase 7: checked `MAINTAINERS` for HID maintainers and subsystem
  ownership.
- Phase 8: mapped trigger and severity from verified parser accesses and
  HID input path.
- Unverified: actual hardware testing on SMK-Link remotes; exact clean
  application to older stable trees without a tiny backport adjustment.

**YES**

 drivers/hid/hid-sony.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index a89af14e4acc6..02baaf84e9792 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -1035,10 +1035,9 @@ static int sony_raw_event(struct hid_device *hdev, struct hid_report *report,
 		sixaxis_parse_report(sc, rd, size);
 	} else if ((sc->quirks & MOTION_CONTROLLER_BT) && rd[0] == 0x01 && size == 49) {
 		sixaxis_parse_report(sc, rd, size);
-	} else if ((sc->quirks & NAVIGATION_CONTROLLER) && rd[0] == 0x01 &&
-			size == 49) {
+	} else if ((sc->quirks & NAVIGATION_CONTROLLER) && rd[0] == 0x01 && size == 49) {
 		sixaxis_parse_report(sc, rd, size);
-	} else if ((sc->quirks & NSG_MRXU_REMOTE) && rd[0] == 0x02) {
+	} else if ((sc->quirks & NSG_MRXU_REMOTE) && rd[0] == 0x02 && size >= 12) {
 		nsg_mrxu_parse_report(sc, rd, size);
 		return 1;
 	} else if ((sc->quirks & RB4_GUITAR_PS4_USB) && rd[0] == 0x01 && size == 64) {
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] HID: ft260: validate i2c input report length

[Sasha Levin]

From: Michael Zaidman <michael.zaidman@gmail.com>

[ Upstream commit 80c4bbb2b38513e9c3d84805fa61a0ee16d79c45 ]

Add two checks to ft260_raw_event() to prevent out-of-bounds reads
from malicious or malfunctioning devices:

First, reject reports shorter than the 2-byte header (report ID +
length fields). Without this, even accessing xfer->length on a
1-byte report is an OOB read.

Second, validate xfer->length against the actual data capacity of
the received HID report. Each I2C data report ID (0xD0 through
0xDE) defines a different report size in the HID descriptor, so the
available payload varies per report. A corrupted length field could
cause memcpy to read beyond the report buffer.

Reported-by: Sebastián Josué Alba Vives <sebasjosue84@gmail.com>
Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
This should be backported. It is a small, single-driver HID fix for a
real out-of-bounds read in `ft260_raw_event()`, reachable from FT260 USB
HID input reports before HID core report-size validation runs. The
benefit is high because the failure mode is memory-safety/security
relevant; the regression risk is low because valid reports are unchanged
and only malformed reports are rejected.

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record: subsystem `HID: ft260`; action verb `validate`; intent is to
validate I2C input report length.

Record: tags in commit `80c4bbb2b38513e9c3d84805fa61a0ee16d79c45`:
`Reported-by: Sebastián Josué Alba Vives <sebasjosue84@gmail.com>`,
`Signed-off-by: Michael Zaidman <michael.zaidman@gmail.com>`, `Signed-
off-by: Jiri Kosina <jkosina@suse.com>`. No `Fixes:`, `Link:`, `Cc:
stable`, `Tested-by`, `Reviewed-by`, or `Acked-by` in the committed
message.

Record: bug description is explicit: malicious or malfunctioning
FT260-compatible HID devices can send too-short reports or corrupted
length fields, causing OOB reads. Symptom/failure mode is OOB heap read
before/inside `memcpy()`. No affected version listed in commit body.

Record: this is not a hidden fix; it is directly described as a memory-
safety fix.

### Phase 2: Diff Analysis
Record: one file changed, `drivers/hid/hid-ft260.c`, `14` insertions and
`2` deletions. Only `ft260_raw_event()` is modified. Scope is single-
file surgical.

Record: before, `ft260_raw_event()` cast `data` to `struct
ft260_i2c_input_report` and accessed `xfer->report`/`xfer->length`
without checking `size`; then `memcpy()` used `xfer->length` after
checking only destination capacity. After, it rejects reports shorter
than the 2-byte header and rejects `xfer->length > size - offsetof(...,
data)` before copying.

Record: bug category is memory safety: OOB read on truncated input and
OOB source read on corrupted length. No locking, API, or feature
behavior changes.

Record: fix quality is strong: minimal, obvious bounds checks
immediately before the unsafe accesses/copy. Regression risk is low;
only malformed reports are rejected. The use of actual `size` avoids the
earlier reviewed problem of rejecting valid short FT260 report IDs.

### Phase 3: Git History Investigation
Record: `git blame` shows the vulnerable header access and `memcpy()`
came from `6a82582d9fa4` (`HID: ft260: add usb hid to i2c host bridge
driver`, first contained around `v5.13-rc1`). The destination-buffer
check came from `b7121e3c04440` (`HID: ft260: skip unexpected HID input
reports`, first contained around `v6.2-rc1`).

Record: no `Fixes:` tag, so Step 3.2 is not applicable.

Record: recent file history shows related FT260 fixes and enhancements,
including `b7121e3c04440`, but no prerequisite needed for the new
source-length/header validation. For older `5.15.y`/`6.1.y`, the exact
patch context does not apply because `b7121e3c04440` is absent, but the
fix itself is still conceptually standalone.

Record: author Michael Zaidman is listed in `MAINTAINERS` as FT260
maintainer and has a long FT260 commit history. Jiri Kosina committed
the patch and is listed as HID core maintainer.

### Phase 4: Mailing List And External Research
Record: `b4 dig -c 80c4bbb2b3851` found the matching submission at `http
s://patch.msgid.link/20260411062437.279838-1-michael.zaidman@gmail.com`.

Record: `b4 dig -a` showed prior versions/discussion. The original
reporter’s v1/v2 were Cc’d to stable and had a too-broad `size < 64`
approach. Review identified that valid FT260 reports can be shorter,
leading to Michael’s final per-driver fix using the header size and
actual report size.

Record: `b4 dig -w` showed Michael Zaidman, Jiri Kosina, Benjamin
Tissoires, linux-input, linux-kernel, and the reporter on the final
submission.

Record: saved lore mbox shows Jiri applied the final patch to
`hid.git#for-7.1/upstream-fixes`. The thread also contains Michael’s
hardware test note: tested on FT260 with I2C-attached EEPROM behind
PCA9548 muxes, including small and larger reads.

Record: stable-specific history exists in the earlier reporter
submissions, including `Cc: stable@vger.kernel.org` and explicit
OOB/security rationale. No NAK remained against the final version.

### Phase 5: Code Semantic Analysis
Record: modified function is `ft260_raw_event()`.

Record: callers traced manually: `ft260_raw_event()` is registered as
`.raw_event`; HID core calls `hdrv->raw_event()` in
`__hid_input_report()` before `hid_report_raw_event()` performs report-
size checks. USB HID paths call `hid_input_report()` from
interrupt/control completion paths.

Record: callees/side effects: `ft260_raw_event()` copies HID I2C
response payload into `dev->read_buf`, advances `read_idx`, and
completes the waiting I2C read when enough data arrives.

Record: reachability: normal FT260 I2C reads go through `i2c_adapter`
operations (`ft260_i2c_xfer()` / `ft260_smbus_xfer()` ->
`ft260_i2c_read()`), while the malformed input itself is supplied by the
USB HID device. Userspace reachability depends on system I2C access
permissions; unprivileged trigger was not verified.

Record: similar pattern in this function is unique for the FT260 I2C
input report copy. Related HID OOB fixes exist in recent HID history,
supporting the general risk class but not required for this patch.

### Phase 6: Stable Tree Analysis
Record: `drivers/hid/hid-ft260.c` exists in `stable/linux-5.15.y`,
`6.1.y`, `6.6.y`, `6.12.y`, and current `v7.0.9` checkout; it does not
exist in `4.19.y`, `5.4.y`, or `5.10.y`.

Record: the buggy code pattern exists in `5.15.y`, `6.1.y`, `6.6.y`, and
`6.12.y`; none contain `80c4bbb2b3851`.

Record: patch applies cleanly to `6.6.y`, `6.12.y`, and current `v7.0.9`
using a temporary index. It does not apply unchanged to `5.15.y` or
`6.1.y` because those lack `b7121e3c04440` context, so older branches
need a small manual backport.

Record: no alternate stable fix for this exact validation was found.

### Phase 7: Subsystem And Maintainer Context
Record: subsystem is HID driver for an FTDI USB HID-to-I2C bridge.
Criticality is driver-specific but security-relevant for systems using
that hardware or exposed USB ports.

Record: subsystem/file activity is active; recent HID history includes
several OOB fixes, and FT260 has ongoing maintenance by Michael Zaidman.

### Phase 8: Impact And Risk
Record: affected population is driver/config/hardware-specific: systems
with `CONFIG_HID_FT260` and FT260 or malicious FT260-emulating USB HID
devices.

Record: trigger is a malformed HID input report from the device,
especially during/around I2C read handling. Physical or device-level
control is required; unprivileged local trigger was not verified.

Record: failure mode is OOB heap read, with reporter discussion noting
possible data exposure through the I2C read buffer. Severity: HIGH,
security-relevant memory safety.

Record: benefit is high for affected systems; risk is low because the
patch is small, contained, and only rejects malformed reports.

### Phase 9: Final Synthesis
Evidence for backporting: real OOB read; malicious/malfunctioning device
trigger; HID raw_event is called before HID core size validation;
maintainer-authored final fix; hardware test notes; one function and one
file; no new API or feature; applies cleanly to current 7.0 and newer
stable branches.

Evidence against/backport concerns: older `5.15.y` and `6.1.y` need
manual context adjustment; `4.19.y`, `5.4.y`, and `5.10.y` lack the
driver. No `Fixes:` tag, but that is not a negative signal here.

Stable rules checklist: obviously correct and tested: yes, by code
inspection and submission test notes. Fixes a real bug: yes, OOB reads.
Important issue: yes, memory safety/security. Small and contained: yes,
`14+/2-` in one function. No new features/APIs: yes. Can apply to
stable: yes for 6.6/6.12/7.0; minor backport needed for 5.15/6.1.

Exception categories: none; this is a direct memory-safety bug fix, not
a device ID/quirk/build/doc exception.

## Verification
- [Phase 1] `git show --format=fuller --no-patch 80c4bbb2b3851`:
  confirmed subject, message, author/committer, and tags.
- [Phase 2] `git show --function-context 80c4bbb2b3851 --
  drivers/hid/hid-ft260.c`: confirmed only `ft260_raw_event()` changes
  and exact bounds checks.
- [Phase 3] `git blame -L 1065,1085 80c4bbb2b3851^ -- drivers/hid/hid-
  ft260.c`: confirmed vulnerable lines originated in `6a82582d9fa4` and
  related destination check in `b7121e3c04440`.
- [Phase 3] `git show` on `6a82582d9fa4` and `b7121e3c04440`: confirmed
  driver introduction and related unexpected-report fix.
- [Phase 4] `b4 dig -c`, `-a`, `-w`, and `-m`: found final lore thread,
  revisions, recipients, maintainer apply message, and test notes.
- [Phase 4] WebFetch/Spinics: confirmed earlier stable-cc’d reporter
  patches and review discussion about avoiding a blanket 64-byte check.
- [Phase 5] Read `drivers/hid/hid-core.c`: confirmed `raw_event` runs
  before `hid_report_raw_event()` size validation.
- [Phase 5] Searched FT260 call paths: confirmed registration as
  `.raw_event`, USB HID input path, and I2C adapter read paths.
- [Phase 6] `git ls-tree` and `git grep` against stable branches:
  confirmed affected code exists in `5.15.y+` branches checked, absent
  from older listed branches.
- [Phase 6] Temporary-index `git apply --check`: clean for `6.6.y`,
  `6.12.y`, and current `v7.0.9`; fails unchanged for `5.15.y`/`6.1.y`,
  requiring minor backport.
- [Phase 7] `MAINTAINERS` search: confirmed Michael Zaidman maintains
  FT260 and Jiri/Benjamin maintain HID core.
- UNVERIFIED: whether an unprivileged local user can trigger this on a
  given distro; that depends on USB access, I2C device permissions, and
  deployment policy.

**YES**

 drivers/hid/hid-ft260.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
index 333341e80b0ec..70e2eedb465af 100644
--- a/drivers/hid/hid-ft260.c
+++ b/drivers/hid/hid-ft260.c
@@ -1068,10 +1068,22 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,
 	struct ft260_device *dev = hid_get_drvdata(hdev);
 	struct ft260_i2c_input_report *xfer = (void *)data;
 
+	if (size < offsetof(struct ft260_i2c_input_report, data)) {
+		hid_err(hdev, "short report %d\n", size);
+		return -1;
+	}
+
 	if (xfer->report >= FT260_I2C_REPORT_MIN &&
 	    xfer->report <= FT260_I2C_REPORT_MAX) {
-		ft260_dbg("i2c resp: rep %#02x len %d\n", xfer->report,
-			  xfer->length);
+		ft260_dbg("i2c resp: rep %#02x len %d size %d\n",
+			  xfer->report, xfer->length, size);
+
+		if (xfer->length > size -
+		    offsetof(struct ft260_i2c_input_report, data)) {
+			hid_err(hdev, "report %#02x: length %d exceeds HID report size\n",
+				xfer->report, xfer->length);
+			return -1;
+		}
 
 		if ((dev->read_buf == NULL) ||
 		    (xfer->length > dev->read_len - dev->read_idx)) {
-- 
2.53.0

[PATCH AUTOSEL 7.0] io_uring: hold uring_lock across io_kill_timeouts() in cancel path

[Sasha Levin]

From: Jens Axboe <axboe@kernel.dk>

[ Upstream commit a65855ec34aed84e1e5b4aea0323cc1745f83a5c ]

io_uring_try_cancel_requests() dropped ctx->uring_lock before calling
io_kill_timeouts(), which walks each timeout's link chain via
io_match_task() to test REQ_F_INFLIGHT. With chain mutation now
serialized by ctx->uring_lock, that walk needs the lock too.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `io_uring`; action verb `hold`; intent is to keep
`ctx->uring_lock` held while `io_kill_timeouts()` walks timeout link
chains in the cancel path.

Record 1.2: Tags present: `Signed-off-by: Jens Axboe <axboe@kernel.dk>`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable@vger.kernel.org` tags were present in the commit
message I verified from upstream commit
`a65855ec34aed84e1e5b4aea0323cc1745f83a5c`.

Record 1.3: The commit body describes a locking bug:
`io_uring_try_cancel_requests()` dropped `ctx->uring_lock` before
`io_kill_timeouts()`, but `io_kill_timeouts()` calls `io_match_task()`
and walks linked requests to inspect `REQ_F_INFLIGHT`. The root cause
stated by the author is that after linked-chain mutation is serialized
by `ctx->uring_lock`, this read-side traversal also needs that lock. No
crash log, reproducer, affected kernel version, or user report is
included.

Record 1.4: This is a hidden synchronization bug fix, despite the
subject not saying “fix”. It changes lock coverage around an existing
linked-list traversal and matches a race-condition pattern.

## Phase 2: Diff Analysis
Record 2.1: One file changed: `io_uring/cancel.c`, 1 insertion and 1
deletion. One function changed: `io_uring_try_cancel_requests()`. Scope
is a single-file, single-hunk surgical locking fix.

Record 2.2: Before: `ctx->uring_lock` was unlocked after canceling
deferred files, poll, waitid, futex, and uring_cmd requests, then
`io_kill_timeouts()` ran unlocked. After: `io_kill_timeouts()` runs
before unlocking `ctx->uring_lock`. The affected path is cancellation
during io_uring task/ring teardown, including exit/exec/SQPOLL/ring-exit
paths verified in callers.

Record 2.3: Bug category is synchronization/race condition. The specific
mechanism is an unlocked traversal of a linked request chain in
`io_kill_timeouts()`/`io_match_task()` while related chain mutation is
intended to be serialized by `ctx->uring_lock`.

Record 2.4: Fix quality is high if applied with its series dependency:
it is minimal, changes no data structures or APIs, and only extends an
already-held mutex over one additional cancel helper. Regression risk is
low but not zero because it extends lock scope over code that takes
`completion_lock` and `timeout_lock`; this risk is mitigated by patch
2/3 moving linked-timeout chain splicing out of hrtimer context.

## Phase 3: Git History Investigation
Record 3.1: `git blame` on current `io_uring/cancel.c` shows the old
unlock-before-`io_kill_timeouts()` code came from `ffce324364318`
(`io_uring/cancel: move cancelation code from io_uring.c to cancel.c`),
first contained in `v6.19`. The timeout chain walk in `io_match_task()`
was introduced by `59915143e89f`, first contained in `v6.0`.

Record 3.2: No `Fixes:` tag is present, so there was no Fixes target to
follow.

Record 3.3: Recent history shows this commit follows `49ae66eb8c273`
(`io_uring: defer linked-timeout chain splice out of hrtimer context`)
and is part of the same linked-request locking series. Recent current-
branch churn in these files is low: current `HEAD` after `v7.0` has only
`93a9caab11350` touching these files.

Record 3.4: Jens Axboe is listed in `MAINTAINERS` as the `IO_URING`
maintainer and has extensive recent io_uring commits in local history.
This is maintainer-authored.

Record 3.5: Dependency found: upstream parent `49ae66eb8c273` is patch
2/3, and `20c39819a276` is patch 1/3. The candidate’s rationale
explicitly depends on patch 2/3’s serialization change. I verified the
full 3-patch series applies cleanly to the current tree.

## Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c a65855ec34ae...` found the original patch at
`https://patch.msgid.link/20260511182217.226763-4-axboe@kernel.dk`. Lore
mirror confirms it was `[PATCH 3/3]` in `[PATCHSET 0/3] Linked request
fix`. `b4 dig -a` found only v1; no newer revision was found.

Record 4.2: `b4 dig -w` showed recipients were Jens Axboe and `io-
uring@vger.kernel.org`. No separate reviewer/acked/tested tags were
found.

Record 4.3: No `Reported-by` or bug-report `Link` tag exists. I found no
syzbot, bugzilla, or user report for this exact commit.

Record 4.4: Related patches are patch 1/3 (`20c39819a276`, hold
`uring_lock` in `io_wq_free_work()`) and patch 2/3 (`49ae66eb8c273`,
defer linked-timeout splice out of hrtimer context). The series cover
letter says it closes gaps where iterating a chain must hold either
`uring_lock` or `timeout_lock`, and modifying an existing chain must
hold both.

Record 4.5: Stable-list search was limited by lore.kernel.org bot
protection, and web search did not find stable-specific discussion for
this exact commit. No stable-specific objection was found.

## Phase 5: Code Semantic Analysis
Record 5.1: Modified function: `io_uring_try_cancel_requests()`.

Record 5.2: Callers verified: `io_ring_exit_work()` calls
`io_uring_try_cancel_requests(ctx, NULL, true, false)` during ring exit;
`io_uring_cancel_generic()` calls it during task cancellation;
`sqpoll.c` calls `io_uring_cancel_generic(true, sqd)` for SQPOLL
shutdown; `fs/exec.c` reaches this via `io_uring_task_cancel()`;
`kernel/exit.c` reaches it via `io_uring_files_cancel()`.

Record 5.3: Key callees around the fix: `io_cancel_defer_files()`,
`io_poll_remove_all()`, `io_waitid_remove_all()`,
`io_futex_remove_all()`, `io_uring_try_cancel_uring_cmd()`, then
`io_kill_timeouts()`. `io_kill_timeouts()` takes `completion_lock` and
`timeout_lock`, iterates `ctx->timeout_list`, calls `io_match_task()`,
and flushes killed timeouts.

Record 5.4: Reachability is verified from userspace lifecycle
operations: io_uring rings/requests can reach cancellation via process
exit, exec, SQPOLL thread shutdown, or ring teardown. Whether
unprivileged users can create io_uring instances on a given deployment
depends on config/sysctl and was not separately verified.

Record 5.5: Similar patterns found: nearby cancel walkers such as
`io_cancel_remove_all()` and `io_poll_remove_all()` assert or run under
`ctx->uring_lock`; `io_match_task_safe()` exists to protect linked-
timeout walks, and patch 1/3 fixes another unlocked link-chain walk in
`io_wq_free_work()`.

## Phase 6: Stable Tree Analysis
Record 6.1: The exact pre-fix `io_uring/cancel.c` pattern exists in
local `v6.19`, `v7.0`, and current `HEAD`. `v6.18` does not have this
exact `io_kill_timeouts()` call in `io_uring/cancel.c`. The refactor
commit `ffce324364318` is an ancestor of `v6.19`, `v7.0`, and `HEAD`,
but not `v6.18`.

Record 6.2: Backport difficulty is low for `v6.19+` style trees: `git
apply --check` succeeded for the candidate alone and for the full
3-patch series on the current tree.

Record 6.3: No alternate stable fix for this exact locking gap was found
in local history or web search.

## Phase 7: Subsystem Context
Record 7.1: Subsystem is `io_uring`, a core async I/O subsystem
reachable through userspace syscalls when enabled. Criticality is
IMPORTANT to CORE depending on deployment, because it affects process
exit/exec and ring teardown correctness for io_uring users.

Record 7.2: Subsystem activity is high; recent local history shows many
io_uring changes by Jens Axboe and others. This patch was pulled into
Linus’ tree for `v7.1-rc4` as part of io_uring fixes.

## Phase 8: Impact And Risk
Record 8.1: Affected users are systems with `CONFIG_IO_URING` and
workloads using linked io_uring requests/timeouts, especially during
cancellation/teardown paths.

Record 8.2: Trigger conditions are linked request/timeouts plus
cancellation paths such as exit, exec, SQPOLL shutdown, or ring exit.
The exact race timing was not reproduced here.

Record 8.3: Failure mode is a locking/data-race hazard on linked
request-chain traversal. No crash report is verified, so I rate severity
as MEDIUM-HIGH rather than proven CRITICAL: cancellation races in
io_uring can lead to missed cancellation or unsafe traversal, but this
specific commit message does not document an observed oops/UAF.

Record 8.4: Benefit is high when backporting the linked-request locking
series, because it completes the lock invariant introduced by patch 2/3.
Risk is low: 1-line lock-scope adjustment, no new API, no feature, no
data structure change. Risk rises if cherry-picked without understanding
the series, so it should be queued with `20c39819a276` and
`49ae66eb8c273`.

## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: real synchronization bug;
maintainer-authored; included in an upstream fixes pull; tiny and
contained; applies cleanly; affects userspace-reachable cancellation
paths; needed to complete a 3-patch linked-chain locking invariant.
Evidence against: no reported crash/reproducer; patch is part 3/3 and
should not be treated as an isolated standalone semantic fix; older
stable trees before the `cancel.c` refactor need separate backport
analysis.

Record 9.2: Stable rules checklist: obviously correct and tested by
upstream integration: yes, with dependency caveat. Fixes a real bug:
yes, a verified locking race/gap. Important issue: yes enough for
stable, because it is a race in io_uring linked request cancellation,
though no crash is documented. Small and contained: yes, 1 insertion/1
deletion in one function. No new features/APIs: yes. Can apply to
stable: yes for current `v6.19+` style trees; full series apply-check
passed on this tree.

Record 9.3: No automatic exception category applies; this is not a
device ID, quirk, DT, build, or documentation fix.

Record 9.4: Decision: backport, but queue it with the preceding linked-
request locking patches, especially `49ae66eb8c273`, because this
commit’s locking rationale depends on that series invariant.

## Verification
- [Phase 1] Verified upstream commit
  `a65855ec34aed84e1e5b4aea0323cc1745f83a5c` message and tags via GitHub
  API and Gitiles.
- [Phase 2] Verified diff is 1 insertion/1 deletion in
  `io_uring/cancel.c`, moving `mutex_unlock(&ctx->uring_lock)` after
  `io_kill_timeouts()`.
- [Phase 3] Ran `git blame` on `io_uring/cancel.c` and
  `io_uring/timeout.c`; identified `ffce324364318`, `59915143e89f`,
  `6971253f0787`, and `a9c83a0ab66a` as relevant historical commits.
- [Phase 3] Verified containing tags: `ffce324364318` present from
  `v6.19`; candidate and series commits first contained in `v7.1-rc4`.
- [Phase 4] Ran `b4 dig -c`, `-a`, and `-w`; found the lore message ID,
  v1-only series, and original recipients.
- [Phase 4] Fetched lore.gnuweeb mirror for patch 0/3, 1/3, 2/3, and
  3/3; confirmed series context and dependency.
- [Phase 5] Used code search and file reads to trace callers from
  `kernel/exit.c`, `fs/exec.c`, `sqpoll.c`, `io_ring_exit_work()`, and
  `io_uring_cancel_generic()`.
- [Phase 6] Checked `v6.18`, `v6.19`, `v7.0`, and `HEAD` for the exact
  code pattern; verified current tree and `v6.19+` have the old unlock-
  before-timeout call.
- [Phase 6] Ran `git apply --check` for the candidate and the full
  3-patch series; both apply cleanly to the current tree.
- [Phase 7] Verified `MAINTAINERS` lists Jens Axboe as `IO_URING`
  maintainer.
- [Phase 8] Verified the failure class from actual code paths and series
  discussion; no runtime reproducer or observed crash was found.
- UNVERIFIED: Whether older pre-`v6.19` stable trees have an equivalent
  bug in the pre-refactor `io_uring.c` layout.
- UNVERIFIED: Any stable-list discussion, because lore.kernel.org/stable
  fetch was blocked and web search found no exact stable discussion.

**YES**

 io_uring/cancel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/io_uring/cancel.c b/io_uring/cancel.c
index 65e04063e343b..1d8928c829b61 100644
--- a/io_uring/cancel.c
+++ b/io_uring/cancel.c
@@ -554,8 +554,8 @@ __cold bool io_uring_try_cancel_requests(struct io_ring_ctx *ctx,
 	ret |= io_waitid_remove_all(ctx, tctx, cancel_all);
 	ret |= io_futex_remove_all(ctx, tctx, cancel_all);
 	ret |= io_uring_try_cancel_uring_cmd(ctx, tctx, cancel_all);
-	mutex_unlock(&ctx->uring_lock);
 	ret |= io_kill_timeouts(ctx, tctx, cancel_all);
+	mutex_unlock(&ctx->uring_lock);
 	if (tctx)
 		ret |= io_run_task_work() > 0;
 	else
-- 
2.53.0

[PATCH AUTOSEL 7.0] platform/x86: hp-wmi: Add support for Victus 16-r0xxx (8BC2)

[Sasha Levin]

From: Haichen Feng <2806891994@qq.com>

[ Upstream commit a59e45221df82e8a6246c617615c1ccc12e3545d ]

The HP Victus 16-r0xxx (board ID: 8BC2) has the same WMI as other Victus
S boards, but requires quirks for correctly switching thermal profile.

Add the DMI board name to victus_s_thermal_profile_boards[] table and
map it to omen_v1_thermal_params.

Testing on board 8BC2 confirmed that platform profile is registered
successfully and fan RPMs are readable and controllable.

Signed-off-by: Haichen Feng <2806891994@qq.com>
Link: https://patch.msgid.link/tencent_8E29805D8DC7B6005244C3433C62DD9DF606@qq.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record: Subsystem is `platform/x86: hp-wmi`; action verb is `Add
support`; intent is a DMI hardware quirk for HP Victus 16-r0xxx board
`8BC2`.

Record: Tags found: `Signed-off-by: Haichen Feng`, `Link: https://patch.
msgid.link/tencent_8E29805D8DC7B6005244C3433C62DD9DF606@qq.com`,
`Reviewed-by: Ilpo Järvinen`, `Signed-off-by: Ilpo Järvinen`. No
`Fixes:`, `Reported-by:`, `Tested-by:`, or `Cc: stable`.

Record: Body says board `8BC2` has the same WMI behavior as other Victus
S boards but needs quirks for correct thermal profile switching. The
author reports testing on board `8BC2`: platform profile registered, fan
RPMs readable and controllable.

Record: This is a hardware quirk / DMI board enablement, not a hidden
memory-safety bug.

### Phase 2: Diff Analysis
Record: One file changed: `drivers/platform/x86/hp/hp-wmi.c`, 4
insertions. Modified object: `victus_s_thermal_profile_boards[]`. Scope:
single-file surgical DMI table addition.

Record: Before: `8BC2` did not match
`victus_s_thermal_profile_boards[]`. After: `8BC2` matches and gets
`.driver_data = &omen_v1_thermal_params`.

Record: Bug category is hardware workaround / DMI quirk. Mechanism:
`setup_active_thermal_profile_params()` uses `dmi_first_match()` on this
table, sets `is_victus_s_board = true`, and selects board-specific
thermal parameters. Without the entry, the Victus S-specific platform
profile and hwmon fan paths are not selected for this board.

Record: Fix quality is high: 4-line table entry, no API change, no
locking/memory lifetime change. Regression risk is very low and limited
to machines whose DMI board name is exactly `8BC2`.

### Phase 3: Git History Investigation
Record: `git blame` around the table shows the DMI table/refactor came
from `8ca7515d3c76` and nearby board entries came from prior hp-wmi
board-support commits. `git grep` against the candidate parent found no
existing `8BC2` entry.

Record: No `Fixes:` tag, so no introducing commit to follow.

Record: Recent file history shows many similar hp-wmi board additions
and fixes, including `8BCA`, `8C76`, `8A4D`, and Victus S support
commits. The candidate is standalone relative to its parent.

Record: `git log --author='Haichen Feng'` found no prior local hp-wmi
commits. The patch was reviewed and committed by Ilpo Järvinen, who also
appears in hp-wmi history.

Record: Dependency: the exact patch expects the `dmi_system_id` table
with `driver_data` and `omen_v1_thermal_params`. That exists in
`v7.0`/`v7.0.9`; older `v6.18`/`v6.19` have an older string table, and
`v6.12` and older checked tags did not show this Victus S table.

### Phase 4: Mailing List And External Research
Record: `b4 dig -c a59e45221df82e8a6246c617615c1ccc12e3545d` found the
original patch at the provided message-id URL.

Record: `b4 dig -C -a` found revisions v1, v2, and v4. Review history
shows v1 was asked to place `8BC2` in sorted order, v3/v4 discussion
asked for a proper commit message and a new thread for b4 tooling. The
standalone v4 was accepted by Ilpo, with applied commit
`a59e45221df82e8a6246c617615c1ccc12e3545d`.

Record: `b4 dig -w` showed the patch went to Haichen Feng, Ilpo
Järvinen, Hans de Goede, `linux-kernel`, and `platform-driver-x86`.

Record: No stable-specific request or rejection was found. `WebFetch`
for lore search pages was blocked by Anubis, so stable-list search via
web is unverified.

### Phase 5: Code Semantic Analysis
Record: Key functions affected indirectly:
`setup_active_thermal_profile_params()`,
`is_victus_s_thermal_profile()`, `thermal_profile_setup()`,
`platform_profile_victus_s_set_ec()`, and hwmon fan handlers.

Record: Callers: `hp_wmi_init()` calls
`setup_active_thermal_profile_params()` before probing; platform profile
and hwmon callbacks use `is_victus_s_thermal_profile()` to choose Victus
S behavior.

Record: Callees include `dmi_first_match()`, `ec_read()`,
`hp_wmi_perform_query()`, and `devm_platform_profile_register()`.

Record: Reachability: the path is reached during hp-wmi module
init/probe and through user-visible platform profile and hwmon
operations after registration. Impact is board-specific, not universal.

Record: Similar patterns exist in the same table: `8BCA`, `8BCD`,
`8C76`, and `8C78` map to `omen_v1_thermal_params`.

### Phase 6: Cross-Referencing And Stable Tree Analysis
Record: Checked tags: `v7.0` and `v7.0.9` contain the required struct
DMI table and lack `8BC2`; `v6.18`/`v6.19` contain an older string-table
Victus S implementation; `v6.12`, `v6.6`, `v6.1`, `v5.15`, and `v5.10`
did not show the same target code.

Record: `git apply --check` of the candidate diff succeeded on current
`v7.0.9`, so expected backport difficulty for `7.0.y` is clean. Older
trees would need either prerequisites or a different backport, and the
exact tested `omen_v1_thermal_params` mapping is not directly applicable
to the older string table.

Record: No related stable alternative fix for `8BC2` was found in
checked local history.

### Phase 7: Subsystem And Maintainer Context
Record: Subsystem is `drivers/platform/x86/hp`, a platform/laptop driver
subsystem. Criticality is peripheral but user-visible for affected HP
hardware.

Record: File history is active, with multiple recent hp-wmi board quirks
and fixes. The review/commit path involved Ilpo Järvinen from the
platform-drivers-x86 maintainership path.

### Phase 8: Impact And Risk Assessment
Record: Affected population is users of HP Victus 16-r0xxx board `8BC2`
with hp-wmi enabled.

Record: Trigger condition is boot/probe and subsequent platform profile
or hwmon fan use on that exact DMI board. Unprivileged triggerability
beyond ordinary sysfs exposure was not established and is not needed for
this decision.

Record: Failure mode is missing/incorrect platform profile and fan
control support on affected hardware, not a crash/corruption bug.
Severity is medium for affected users.

Record: Benefit is high for affected hardware because it enables tested
thermal profile/fan behavior. Risk is very low because the change is a
single exact DMI match.

### Phase 9: Final Synthesis
Record: Evidence for backporting: it is a hardware-specific DMI quirk,
explicitly tested on the target board by the submitter, reviewed/applied
by the subsystem maintainer path, and only affects board `8BC2`.

Record: Evidence against: it is hardware enablement rather than a
crash/security/data-corruption fix, and older stable trees may not have
the exact prerequisite table structure.

Record: Stable rules: obviously correct yes; fixes a real board support
problem yes; important enough under the hardware quirk exception yes;
small and contained yes; no new API yes; clean apply verified for
`v7.0.9`, older applicability requires tree-specific handling.

Record: Exception category applies: hardware quirk / DMI board entry to
an existing driver.

## Verification
- [Phase 1] `git show a59e45221df82...` confirmed subject, tags, 4-line
  diff, and commit body.
- [Phase 2] Diff confirmed only `victus_s_thermal_profile_boards[]` is
  changed.
- [Phase 3] `git blame` and `git log` verified table history and related
  hp-wmi board entries.
- [Phase 4] `b4 dig`, `b4 mbox`, and local mbox reads verified review
  history, v1/v2/v4 revisions, maintainer feedback, and final
  acceptance.
- [Phase 5] `rg`/file reads verified the DMI table drives Victus S
  platform profile and hwmon fan code paths.
- [Phase 6] tag checks verified exact applicability to `v7.0.y` and
  structural mismatch in older checked trees.
- [Phase 8] Impact/risk is based on exact DMI matching and code-path
  inspection.
- UNVERIFIED: lore stable search pages via `WebFetch` were blocked by
  Anubis; no independent hardware test was performed here beyond the
  author’s commit-message report.

This should be backported to stable trees that contain the matching hp-
wmi DMI table infrastructure, especially `7.0.y`. It is the classic
stable-acceptable hardware quirk: tiny, reviewed, board-specific, and
low risk.

**YES**

 drivers/platform/x86/hp/hp-wmi.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/hp/hp-wmi.c b/drivers/platform/x86/hp/hp-wmi.c
index 62fd2fe0d8d0e..71e0100455d9a 100644
--- a/drivers/platform/x86/hp/hp-wmi.c
+++ b/drivers/platform/x86/hp/hp-wmi.c
@@ -194,6 +194,10 @@ static const struct dmi_system_id victus_s_thermal_profile_boards[] __initconst
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8BBE") },
 		.driver_data = (void *)&victus_s_thermal_params,
 	},
+	{
+		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8BC2") },
+		.driver_data = (void *)&omen_v1_thermal_params,
+	},
 	{
 		.matches = { DMI_MATCH(DMI_BOARD_NAME, "8BCA") },
 		.driver_data = (void *)&omen_v1_thermal_params,
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] i2c: acpi: Add ELAN0678 to i2c_acpi_force_100khz_device_ids

[Sasha Levin]

From: Niels Franke <nielsfranke@gmail.com>

[ Upstream commit 9998e388be9930c106eb5904c23ecf2162407527 ]

The ELAN0678 touchpad (04F3:3195) found in the Lenovo ThinkPad X13
exhibits excessive smoothing when the I2C bus runs at 400KHz, making
the touchpad feel sluggish when plugged into AC power. This is the
same issue previously fixed for ELAN06FA.

The device's ACPI table (Lenovo TP-R22) specifies 0x00061A80 (400KHz)
for the I2cSerialBusV2 descriptor. Forcing the bus to 100KHz eliminates
the sluggish behavior.

Signed-off-by: Niels Franke <nielsfranke@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
[wsa: kept the sorting]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

Step 1.1 - Subject:
Record: Subsystem `i2c: acpi`; action verb `Add`; intent is to add ACPI
HID `ELAN0678` to the existing 100 kHz forced-speed quirk table.

Step 1.2 - Tags:
Record: `Signed-off-by: Niels Franke <nielsfranke@gmail.com>`; `Acked-
by: Mika Westerberg <mika.westerberg@linux.intel.com>`; maintainer note
`[wsa: kept the sorting]`; `Signed-off-by: Wolfram Sang
<wsa+renesas@sang-engineering.com>`. No `Fixes:`, `Reported-by:`,
`Tested-by:`, `Link:`, or `Cc: stable@vger.kernel.org` tags.

Step 1.3 - Body:
Record: The bug is real hardware misbehavior: ELAN0678 touchpad
`04F3:3195` on Lenovo ThinkPad X13 becomes sluggish/excessively smoothed
when ACPI-described I2C speed is 400 kHz. The commit says forcing 100
kHz eliminates it. Root cause is a bad/not-working speed choice for this
device, matching the earlier ELAN06FA workaround.

Step 1.4 - Hidden bug fix:
Record: Yes. Although phrased as “Add”, this is a hardware
workaround/quirk for a user-visible input-device malfunction, not new
feature work.

## Phase 2: Diff Analysis

Step 2.1 - Inventory:
Record: One file changed: `drivers/i2c/i2c-core-acpi.c`, `+1/-0`. It
adds `{ "ELAN0678", 0 }` to `i2c_acpi_force_100khz_device_ids`. Scope is
a single-file, one-line hardware quirk.

Step 2.2 - Code flow:
Record: Before, ELAN0678 used the normal ACPI/min-speed path and could
run at the 400 kHz speed from firmware. After, when
`i2c_acpi_lookup_speed()` sees an ACPI device matching `ELAN0678`, it
sets `lookup->force_speed = I2C_MAX_STANDARD_MODE_FREQ`, causing
`i2c_acpi_find_bus_speed()` to return 100 kHz.

Step 2.3 - Bug mechanism:
Record: Hardware workaround. The broken condition is a known-not-working
I2C bus speed for a specific ACPI HID. The fix reuses the existing
forced-100-kHz mechanism.

Step 2.4 - Fix quality:
Record: Obviously correct and minimal. It only affects machines exposing
ACPI HID `ELAN0678`. Regression risk is very low: affected devices will
run slower I2C, intentionally matching the verified workaround; all
other devices are unchanged.

## Phase 3: Git History

Step 3.1 - Blame:
Record: `git blame` on `origin/master` shows the new line is commit
`9998e388be993`; the 100 kHz table and `ELAN06FA` handling came from
`bfd74cd1fbc026`, first contained around `v6.14-rc1`; `DLL0945` came
from `0b7c9528facdb5`, first contained around `v6.17-rc1`.

Step 3.2 - Fixes tag:
Record: Not applicable; no `Fixes:` tag is present.

Step 3.3 - File history:
Record: Recent file history shows related quirks `ELAN06FA` and
`DLL0945`, plus unrelated treewide allocation conversions. No
prerequisite structural change is needed where the 100 kHz table already
exists.

Step 3.4 - Author context:
Record: Local history shows Niels Franke has this one I2C commit on
`origin/master`. The patch was acked by Mika Westerberg, listed in
`MAINTAINERS` as I2C ACPI maintainer, and committed by Wolfram Sang.

Step 3.5 - Dependencies:
Record: Standalone for stable branches that already have
`i2c_acpi_force_100khz_device_ids`. For branches lacking the table, it
depends on the earlier ELAN06FA forced-100-kHz infrastructure.

## Phase 4: Mailing List And External Research

Step 4.1 - Original discussion:
Record: `b4 dig -c 9998e388be993` found the original submission at
`https://patch.msgid.link/20260418053719.15766-1-nielsfranke@gmail.com`.
The mirror thread shows v1 only, Mika Westerberg acked it, and Wolfram
Sang applied it to `for-current` while keeping sort order. No objections
or NAKs found.

Step 4.2 - Reviewers/recipients:
Record: `b4 dig -w` shows recipients included Niels Franke,
`westeri@kernel.org`, Wolfram Sang, `linux-i2c`, `linux-acpi`, and
`linux-kernel`. This reached the relevant I2C ACPI maintainer and lists.

Step 4.3 - Bug report:
Record: No separate `Reported-by` or bug tracker link in the commit. The
commit message itself documents affected hardware, ACPI table speed, and
the tested workaround. Web search also found unrelated ELAN0678 user
reports, but I did not rely on those for the final decision.

Step 4.4 - Series context:
Record: `b4 dig -a` shows a single v1 patch, not a multi-patch series.

Step 4.5 - Stable discussion:
Record: Direct lore stable fetch was blocked by Anubis; web search found
no specific stable-list discussion for ELAN0678. Stable branch git logs
sampled do not yet contain ELAN0678.

## Phase 5: Code Semantic Analysis

Step 5.1 - Key functions:
Record: The diff changes only the ACPI ID table, but behavior flows
through `i2c_acpi_lookup_speed()` and `i2c_acpi_find_bus_speed()`.

Step 5.2 - Callers:
Record: `i2c_acpi_find_bus_speed()` is called by multiple I2C bus
drivers, including DesignWare, USBIO, SynQuacer, LS2X, Zhaoxin, and AMD
MP2. For DesignWare, `dw_i2c_plat_probe()` and PCI probe paths call
`i2c_dw_fw_parse_and_configure()`, which calls the ACPI speed lookup
during controller setup.

Step 5.3 - Callees:
Record: The relevant code calls `acpi_walk_namespace()`,
`i2c_acpi_do_lookup()`, and `acpi_match_device_ids()`; if matched, it
returns the forced speed to bus-driver timing configuration.

Step 5.4 - Reachability:
Record: Reachable during I2C adapter/controller initialization on ACPI
systems. On affected Lenovo hardware, this path controls the bus speed
used for the touchpad.

Step 5.5 - Similar patterns:
Record: Verified sibling quirks `ELAN06FA` and `DLL0945` in the same
table, both addressing touchpad sluggishness at higher I2C speed.

## Phase 6: Stable Tree Analysis

Step 6.1 - Buggy code in stable:
Record: Sampled stable branches `5.10.y`, `5.15.y`, `6.6.y`, `6.12.y`,
`6.15.y` through `7.0.y` already contain the 100 kHz quirk table with
`ELAN06FA`/`DLL0945`, but not `ELAN0678`. `5.4.y` has ACPI speed lookup
but not the forced-100-kHz table in the sampled state.

Step 6.2 - Backport difficulty:
Record: Clean or trivial for branches with both `DLL0945` and `ELAN06FA`
adjacent. Branches lacking `DLL0945` or the table may need a trivial
context adjustment or dependency backport.

Step 6.3 - Related fixes already stable:
Record: Stable branches sampled already carry related ELAN06FA/DLL0945
quirks, but no ELAN0678 equivalent.

## Phase 7: Subsystem Context

Step 7.1 - Subsystem:
Record: `drivers/i2c/i2c-core-acpi.c`, I2C ACPI support. Criticality is
important for affected ACPI laptop hardware, but not universal/core.

Step 7.2 - Activity:
Record: File history shows active maintenance and recent hardware quirk
additions. The patch was accepted through the I2C maintainer path.

## Phase 8: Impact And Risk

Step 8.1 - Affected users:
Record: Users of systems exposing the ELAN0678 ACPI touchpad,
specifically verified by commit message for Lenovo ThinkPad X13.

Step 8.2 - Trigger:
Record: Triggered when the I2C bus is configured at 400 kHz for this
device, including via the Lenovo TP-R22 ACPI `I2cSerialBusV2`
descriptor. This is normal boot/device setup, not an obscure manual
path.

Step 8.3 - Severity:
Record: Medium severity user-visible hardware malfunction: sluggish
touchpad/input behavior. Not a crash, security issue, or data
corruption.

Step 8.4 - Risk-benefit:
Record: Benefit is high for affected laptops because it restores usable
touchpad behavior. Risk is very low because it is a one-line ACPI HID-
specific quirk using existing logic.

## Phase 9: Final Synthesis

Step 9.1 - Evidence:
Record: For backporting: real hardware bug, existing quirk mechanism,
one-line scoped change, maintainer ack, accepted by I2C maintainer,
stable branches already carry analogous quirks. Against backporting: no
explicit stable tag, no separate bug report link, not a critical
crash/security fix. Unresolved: exact applicability to every older
stable branch; `5.4.y` would need more than this one-line context.

Step 9.2 - Stable rules:
Record: Obviously correct: yes. Tested: commit states forcing 100 kHz
eliminates the issue, though no `Tested-by` tag. Real bug: yes, touchpad
sluggishness. Important enough: yes under hardware quirk/workaround
practice. Small/contained: yes, one line. No new APIs/features: yes.
Applies to stable: yes for branches with the existing table; trivial
adjustment/dependency for older divergent branches.

Step 9.3 - Exception:
Record: This falls squarely under the stable hardware quirk/workaround
exception.

Step 9.4 - Decision:
Record: Backport. The risk is tiny and the fix is exactly the sort of
targeted hardware workaround stable trees routinely carry.

## Verification

- Phase 1: Parsed `git show --format=fuller --stat --patch
  9998e388be993`; confirmed subject, body, tags, and one-line diff.
- Phase 2: Read `drivers/i2c/i2c-core-acpi.c`; confirmed
  `i2c_acpi_force_100khz_device_ids` is checked by
  `i2c_acpi_lookup_speed()` and returns 100 kHz through
  `i2c_acpi_find_bus_speed()`.
- Phase 3: Ran `git blame` on the relevant lines; confirmed commits for
  `ELAN06FA`, `DLL0945`, and `ELAN0678`.
- Phase 3: Ran `git describe --contains`; confirmed first-containing
  release positions for related mainline commits.
- Phase 4: Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; found original
  v1 submission, no later revisions, and relevant recipients.
- Phase 4: Fetched the public mirror thread; confirmed Mika Westerberg’s
  ack and Wolfram Sang’s application note.
- Phase 5: Used semantic search, `rg`, and file reads; confirmed
  DesignWare and other I2C bus drivers call `i2c_acpi_find_bus_speed()`.
- Phase 6: Used `git grep` and stable branch logs; confirmed sampled
  stable branches contain related forced-speed quirks but not ELAN0678.
- Phase 8: Failure mode is verified from the commit message and lore
  thread: sluggish/excessively smoothed touchpad at 400 kHz, fixed by
  100 kHz.
- UNVERIFIED: Direct `lore.kernel.org/stable` content was blocked by
  Anubis, so I could not independently inspect stable-list discussion
  there.

**YES**

 drivers/i2c/i2c-core-acpi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
index 2cbd31f77667a..28c0e4884a7f2 100644
--- a/drivers/i2c/i2c-core-acpi.c
+++ b/drivers/i2c/i2c-core-acpi.c
@@ -371,6 +371,7 @@ static const struct acpi_device_id i2c_acpi_force_100khz_device_ids[] = {
 	 * a 400KHz frequency. The root cause of the issue is not known.
 	 */
 	{ "DLL0945", 0 },
+	{ "ELAN0678", 0 },
 	{ "ELAN06FA", 0 },
 	{}
 };
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] KVM: VMX: introduce module parameter to disable CET

[Sasha Levin]

From: Paolo Bonzini <pbonzini@redhat.com>

[ Upstream commit 2d5d3fc593c9b7e41bee86175d7b9e11f470072e ]

There have been reports of host hangs caused by CET virtualization.
Until these are analyzed further, introduce a module parameter that
makes it possible to easily disable it.

Link: https://lore.kernel.org/all/85548beb-1486-40f9-beb4-632c78e3360b@proxmox.com/
Cc: David Riley <d.riley@proxmox.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

Step 1.1 Record: subsystem `KVM: VMX`; action verb `introduce`; summary:
add a VMX module parameter to disable CET virtualization.

Step 1.2 Record: tags present:
- `Link:` `https://lore.kernel.org/all/85548beb-1486-40f9-beb4-
  632c78e3360b@proxmox.com/`
- `Cc:` `David Riley <d.riley@proxmox.com>`
- `Signed-off-by:` `Paolo Bonzini <pbonzini@redhat.com>`
- No `Fixes:` tag.
- No `Reported-by:` or `Tested-by:` tag in the commit itself.

Step 1.3 Record: the commit says CET virtualization has caused host
hangs, and the parameter is a mitigation while the reports are analyzed.
The linked report describes Windows Server 2026 with VBS/HVCI on an
Intel Xeon Gold 6426Y hanging in early boot with watchdog hard/soft
lockups on the host. The root cause is not identified in the commit or
linked report.

Step 1.4 Record: this is a real bug workaround, not a hidden
resource/lifetime fix. It does not fix the underlying CET bug by
default; it gives affected administrators a supported way to disable the
problematic VMX CET virtualization path.

## Phase 2: Diff Analysis

Step 2.1 Record: files changed:
- `arch/x86/kvm/vmx/capabilities.h`: +1 extern declaration.
- `arch/x86/kvm/vmx/vmx.c`: +15/-2.
- Total: 2 files, 16 insertions, 2 deletions.
- Functions modified: `vmx_set_constant_host_state()`,
  `vmx_get_initial_vmentry_ctrl()`, `vmx_get_initial_vmexit_ctrl()`,
  `vmx_set_cpu_caps()`, `vmx_hardware_setup()`.
- Scope: small, VMX-only, surgical change.

Step 2.2 Record:
- New global `enable_cet` defaults to true and is exposed via
  `module_param_named(cet, enable_cet, bool, 0444)`.
- `vmx_set_constant_host_state()` used raw hardware support via
  `cpu_has_load_cet_ctrl()`; after the patch it uses `enable_cet`, so
  disabling CET also avoids programming host CET VMCS fields.
- `vmx_get_initial_vmentry_ctrl()` and `vmx_get_initial_vmexit_ctrl()`
  now clear CET load controls when disabled.
- `vmx_set_cpu_caps()` now hides guest `SHSTK`/`IBT` when `enable_cet`
  is false.
- `vmx_hardware_setup()` clears `enable_cet` if hardware lacks CET VM-
  entry support, preserving the old hardware-gating behavior.

Step 2.3 Record: bug category is operational workaround for severe KVM
host hang. Mechanism: disable advertising and using VMX CET
virtualization state through one read-mostly knob; no locking,
refcounting, memory safety, or endian change.

Step 2.4 Record: fix quality is good for a mitigation. It is small and
internally consistent. Regression risk is low because default behavior
remains enabled, and disabled behavior only applies when the
administrator opts out. Main concern: it adds a new module parameter,
which is normally disfavored for stable, but here it is an opt-out for a
verified host lockup regression.

## Phase 3: Git History Investigation

Step 3.1 Record: blame shows the CET-specific host VMCS state came from
`584ba3ffb984` (`KVM: VMX: Set host constant supervisor states to VMCS
fields`), and guest CET advertising came from `e140467bbdaf` (`KVM: x86:
Enable CET virtualization for VMX and advertise to userspace`). `git
describe --contains` places both in the v6.18 development window.

Step 3.2 Record: no `Fixes:` tag is present, so there was no tagged
introducing commit to follow. The relevant introducing commits were
identified by blame and subject search instead.

Step 3.3 Record: recent file history shows CET virtualization and later
KVM VMX changes in the same area, but this candidate is standalone. No
prerequisite beyond existing VMX CET virtualization support was found.

Step 3.4 Record: Paolo Bonzini authored and committed this patch.
`MAINTAINERS` lists Paolo as maintainer for both `KERNEL VIRTUAL MACHINE
(KVM)` and `KERNEL VIRTUAL MACHINE FOR X86 (KVM/x86)`.

Step 3.5 Record: dependencies are the CET virtualization infrastructure,
especially `VM_ENTRY_LOAD_CET_STATE`, `VM_EXIT_LOAD_CET_STATE`, and
`cpu_has_load_cet_ctrl()`. Those exist in local `pending-6.18`,
`pending-6.19`, and `pending-7.0`. The patch applies cleanly to all
three tested branches.

## Phase 4: Mailing List And External Research

Step 4.1 Record: `b4 dig -c 2d5d3fc593c9...` found the submission at
`https://patch.msgid.link/20260512150016.2979228-1-pbonzini@redhat.com`.
`b4 dig -a` showed a standalone v1 patch and also associated it with the
MBEC/GMET series thread referenced by the bug report. No formal v2 was
found.

Step 4.2 Record: `b4 dig -w` showed the original recipients: Paolo
Bonzini, `linux-kernel@vger.kernel.org`, `kvm@vger.kernel.org`, and
David Riley. Sean Christopherson replied in review; `MAINTAINERS`
confirms Sean is a KVM/x86 maintainer.

Step 4.3 Record: the linked report from David Riley documents Intel host
hard/soft lockups and guest boot hangs with Windows Server 2026,
VBS/HVCI, and `-cpu host,level=30,+vmx-mbec`. The same report says
disabling `cet-ss` and `cet-ibt` in QEMU let the Intel guest boot.

Step 4.4 Record: review feedback from Sean objected to an initial
`vmcs12.c` hunk because `cpu_has_vmcs12_field()` checks raw CPU support,
not enabled KVM policy. Paolo agreed to remove that hunk, and the
committed diff no longer modifies `vmcs12.c`.

Step 4.5 Record: web search did not find stable-list discussion for this
specific patch or bug. Lore WebFetch was blocked by Anubis, but `b4`
successfully retrieved the relevant patch and bug-report messages.

## Phase 5: Code Semantic Analysis

Step 5.1 Record: modified functions: `vmx_set_constant_host_state()`,
`vmx_get_initial_vmentry_ctrl()`, `vmx_get_initial_vmexit_ctrl()`,
`vmx_set_cpu_caps()`, `vmx_hardware_setup()`.

Step 5.2 Record: callers:
- `vmx_set_constant_host_state()` is called from VMCS initialization in
  `vmx.c` and from nested VMCS02 constant-state setup in `nested.c`.
- `vmx_get_initial_vmentry_ctrl()` and `vmx_get_initial_vmexit_ctrl()`
  are used during VMCS initialization.
- `vmx_set_cpu_caps()` is called from `vmx_hardware_setup()`.
- `vmx_hardware_setup()` is called from `vt_hardware_setup()` in
  `arch/x86/kvm/vmx/main.c`.

Step 5.3 Record: key callees include `vmcs_writel()`,
`vm_exit_controls_set()`, `vm_entry_controls_set()`,
`kvm_cpu_cap_clear()`, and `cpu_has_load_cet_ctrl()`. These show the
patch affects VMCS setup and guest CPUID exposure.

Step 5.4 Record: the affected path is reachable through KVM module setup
and VM/vCPU creation, then guest execution. The linked report confirms
practical reachability via QEMU launching a Windows guest.

Step 5.5 Record: similar patterns exist for other VMX feature toggles
such as `enable_ept`, `enable_vpid`, `enable_pml`, and
`enable_unrestricted_guest`, so the implementation follows existing VMX
module-parameter style.

## Phase 6: Stable Tree Analysis

Step 6.1 Record: CET virtualization support was introduced for v6.18-era
kernels. Local `pending-6.18`, `pending-6.19`, and `pending-7.0` all
contain the relevant CET code and lack `enable_cet`.

Step 6.2 Record: exact upstream diff applies cleanly to temporary
worktrees for `pending-6.18`, `pending-6.19`, and `pending-7.0`.
Backport difficulty is clean apply for those tested trees.

Step 6.3 Record: local history search found no separate fix for “host
hangs caused by CET virtualization” or the Windows Server 2026 report.
No replacement fix was identified.

## Phase 7: Subsystem And Maintainer Context

Step 7.1 Record: subsystem is KVM/x86 VMX, criticality IMPORTANT to CORE
for hosts running Intel KVM virtualization. Failure affects host
stability, not only guest functionality.

Step 7.2 Record: KVM/x86 VMX is highly active in this tree. CET
virtualization was a recent large feature, introduced around v6.18, so
this is a mitigation for a recent virtualization regression surface.

## Phase 8: Impact And Risk Assessment

Step 8.1 Record: affected users are Intel KVM hosts exposing CET
virtualization to guests. The verified report involves Windows Server
2026 with VBS/HVCI and QEMU CPU settings exposing CET/MBEC.

Step 8.2 Record: trigger conditions verified from the report: booting
the Windows guest with CET and MBEC exposed. Unprivileged local
triggerability was not verified; this appears to require VM
launch/configuration control.

Step 8.3 Record: failure mode is severe: guest hang plus host watchdog
hard lockup and soft lockup. Severity: CRITICAL.

Step 8.4 Record: benefit is high for affected stable users because it
gives a practical mitigation for host lockups. Risk is low-medium: small
VMX-only patch and default behavior unchanged, but it does add a new
module parameter.

## Phase 9: Final Synthesis

Step 9.1 Record:
- Evidence for backporting: verified host hard/soft lockups; small
  contained VMX-only patch; authored by KVM maintainer; reviewed on KVM
  list with maintainer feedback incorporated; applies cleanly to
  affected local stable branches; default behavior unchanged.
- Evidence against backporting: it is a workaround, not a root-cause
  fix; it adds a new module parameter, which stable normally treats
  cautiously; users must opt in to the mitigation by disabling CET.
- Unresolved: exact root cause of the CET hang is not identified; no
  stable-list discussion was found.

Step 9.2 Stable rules:
1. Obviously correct and tested? Mostly yes: simple gating of existing
   CET controls; mailing-list review fixed an inconsistency. No explicit
   `Tested-by` on this patch.
2. Fixes a real bug affecting users? Yes: linked report shows host
   lockups and guest hangs.
3. Important issue? Yes: host hard/soft lockups are critical.
4. Small and contained? Yes: 2 files, 16 insertions, 2 deletions.
5. No new features or APIs? Concern: it adds a module parameter.
   Mitigating factor: default behavior is unchanged and the parameter is
   an opt-out for a serious regression.
6. Can apply to stable trees? Yes for tested `pending-6.18`,
   `pending-6.19`, and `pending-7.0`.

Step 9.3 Record: no automatic exception category like device ID or
hardware quirk. The closest category is a conservative operational
workaround for broken hardware/feature behavior.

Step 9.4 Decision: backport to stable trees that already contain VMX CET
virtualization, especially v6.18 and newer. Despite the module parameter
concern, the benefit of giving stable users a low-risk escape hatch from
verified host lockups outweighs the risk, and the default behavior is
unchanged.

## Verification

- [Phase 1] Parsed `git show --format=fuller --stat --patch
  2d5d3fc593c9...`: confirmed subject, body, tags, author, and exact
  diff.
- [Phase 2] Diff analysis: confirmed 2 files, 16 insertions, 2
  deletions, VMX-only gating of CET controls and CPUID exposure.
- [Phase 3] `git blame` around changed areas: identified CET code from
  `584ba3ffb984` and `e140467bbdaf`.
- [Phase 3] `git describe --contains`: confirmed CET support is
  v6.18-era and candidate is v7.1-rc4-era.
- [Phase 3] `MAINTAINERS` search: confirmed Paolo Bonzini and Sean
  Christopherson are KVM/x86 maintainers.
- [Phase 4] `b4 dig -c`: found patch submission at
  `20260512150016.2979228-1-pbonzini@redhat.com`.
- [Phase 4] `b4 dig -a`: found standalone v1 and related MBEC/GMET
  series context.
- [Phase 4] `b4 dig -w`: confirmed KVM and LKML recipients plus David
  Riley.
- [Phase 4] `b4 mbox`: confirmed Sean’s review concern and Paolo’s
  agreement to remove the `vmcs12.c` hunk; committed patch matches that
  resolution.
- [Phase 4] `b4 mbox --single-message`: retrieved David Riley’s bug
  report with Intel host lockups and guest hangs.
- [Phase 5] `rg` caller search: traced modified functions to VMX
  hardware setup, VMCS initialization, and nested VMCS02 setup.
- [Phase 6] `git grep` on `pending-6.18`, `pending-6.19`, and
  `pending-7.0`: confirmed CET code exists and `enable_cet` does not.
- [Phase 6] Temporary worktree `git apply --check`: exact patch applies
  cleanly to `pending-6.18`, `pending-6.19`, and `pending-7.0`.
- [Phase 8] Failure mode verified from bug report: watchdog hard lockup
  and soft lockup on host, plus guest early boot hang.
- UNVERIFIED: underlying root cause of the CET virtualization hang
  remains unknown.
- UNVERIFIED: no exhaustive stable-list archive proof beyond web search;
  no stable-specific discussion was found.

**YES**

 arch/x86/kvm/vmx/capabilities.h |  1 +
 arch/x86/kvm/vmx/vmx.c          | 17 +++++++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
index 4e371c93ae168..46fb4d2e81c42 100644
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@ -14,6 +14,7 @@ extern bool __read_mostly flexpriority_enabled;
 extern bool __read_mostly enable_ept;
 extern bool __read_mostly enable_unrestricted_guest;
 extern bool __read_mostly enable_ept_ad_bits;
+extern bool __read_mostly enable_cet;
 extern bool __read_mostly enable_pml;
 extern int __read_mostly pt_mode;
 
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 8b24e682535bf..084c30cf689b9 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -107,6 +107,9 @@ module_param_named(unrestricted_guest,
 bool __read_mostly enable_ept_ad_bits = 1;
 module_param_named(eptad, enable_ept_ad_bits, bool, 0444);
 
+bool __read_mostly enable_cet = 1;
+module_param_named(cet, enable_cet, bool, 0444);
+
 static bool __read_mostly emulate_invalid_guest_state = true;
 module_param(emulate_invalid_guest_state, bool, 0444);
 
@@ -4585,7 +4588,7 @@ void vmx_set_constant_host_state(struct vcpu_vmx *vmx)
 	 * SSP is reloaded from IA32_PL3_SSP. Check SDM Vol.2A/B Chapter
 	 * 3 and 4 for details.
 	 */
-	if (cpu_has_load_cet_ctrl()) {
+	if (enable_cet) {
 		vmcs_writel(HOST_S_CET, kvm_host.s_cet);
 		vmcs_writel(HOST_SSP, 0);
 		vmcs_writel(HOST_INTR_SSP_TABLE, 0);
@@ -4641,6 +4644,10 @@ static u32 vmx_get_initial_vmentry_ctrl(void)
 	if (vmx_pt_mode_is_system())
 		vmentry_ctrl &= ~(VM_ENTRY_PT_CONCEAL_PIP |
 				  VM_ENTRY_LOAD_IA32_RTIT_CTL);
+
+	if (!enable_cet)
+		vmentry_ctrl &= ~VM_ENTRY_LOAD_CET_STATE;
+
 	/*
 	 * IA32e mode, and loading of EFER and PERF_GLOBAL_CTRL are toggled dynamically.
 	 */
@@ -4655,6 +4662,9 @@ static u32 vmx_get_initial_vmexit_ctrl(void)
 {
 	u32 vmexit_ctrl = vmcs_config.vmexit_ctrl;
 
+	if (!enable_cet)
+		vmexit_ctrl &= ~VM_EXIT_LOAD_CET_STATE;
+
 	/*
 	 * Not used by KVM and never set in vmcs01 or vmcs02, but emulated for
 	 * nested virtualization and thus allowed to be set in vmcs12.
@@ -8240,7 +8250,7 @@ static __init void vmx_set_cpu_caps(void)
 	 * VMX_BASIC[bit56] == 0, inject #CP at VMX entry with error code
 	 * fails, so disable CET in this case too.
 	 */
-	if (!cpu_has_load_cet_ctrl() || !enable_unrestricted_guest ||
+	if (!enable_cet || !enable_unrestricted_guest ||
 	    !cpu_has_vmx_basic_no_hw_errcode_cc()) {
 		kvm_cpu_cap_clear(X86_FEATURE_SHSTK);
 		kvm_cpu_cap_clear(X86_FEATURE_IBT);
@@ -8721,6 +8731,9 @@ __init int vmx_hardware_setup(void)
 	    !cpu_has_vmx_invept_global())
 		enable_ept = 0;
 
+	if (!cpu_has_load_cet_ctrl())
+		enable_cet = 0;
+
 	/* NX support is required for shadow paging. */
 	if (!enable_ept && !boot_cpu_has(X86_FEATURE_NX)) {
 		pr_err_ratelimited("NX (Execute Disable) not supported\n");
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] iommu/amd: Use maximum Event log buffer size when SNP is enabled on Family 0x19

[Sasha Levin]

From: Vasant Hegde <vasant.hegde@amd.com>

[ Upstream commit 58c0ac6125d89bf6ec65a521eaeb52a0e8e20a9f ]

Due to CVE-2023-20585, the Event log buffer must use the maximum supported
size (512K) on Milan/Genoa (Family 0x19) systems when SNP is enabled,
to mitigate a potential security vulnerability. All other systems continue to
use the default Event log buffer size (8K).

Apply the errata fix by making the following changes:

* Introduce new global variable (amd_iommu_evtlog_size) to have event log
  buffer size. Adjust variable size for family 0x19.

* Since 'iommu_snp_enable()' must be called after the core IOMMU subsystem
  is initialized, it cannot be moved to the early init stage. The SNP errata
  must also be applied after the 'iommu_snp_enable()' check. Therefore,
  'alloc_event_buffer()' and 'iommu_enable_event_buffer()' are now called
  in the IOMMU_ENABLED state, after the errata is applied.

* Adjust alloc_event_buffer() and iommu_enable_event_buffer() to handle
  all IOMMU instances.

* Also rename EVT_* macros to make it more readable.

Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3016.html
Cc: Borislav Petkov <bp@alien8.de>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Tested-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Conclusion
This commit should be backported to stable trees that carry AMD IOMMU
SNP host support. It is a security mitigation for `CVE-2023-20585`,
scoped to AMD Family `0x19` systems with SNP enabled, and it keeps all
other systems on the existing 8K event log size.

The patch is not feature enablement in the stable sense; it is a
hardware erratum/security workaround. The main concern is backport
mechanics: it applies cleanly to `stable/linux-7.0.y`, but failed a
direct apply check on `6.12.y`, `6.18.y`, and `6.19.y`, so those need
backport adjustment. For Genoa, the companion PPR-log patch should also
be considered for the full series mitigation.

## Phase Walkthrough
Phase 1 Record:
- Subject subsystem/action: `iommu/amd`, action is “Use maximum”, intent
  is to use a 512K AMD IOMMU event log buffer for SNP on Family `0x19`.
- Tags: `Link` to AMD-SB-3016, `Cc` to AMD/IOMMU maintainers, `Signed-
  off-by` Vasant Hegde, `Tested-by` Dheeraj Kumar Srivastava, `Signed-
  off-by` Joerg Roedel. No `Fixes:` tag.
- Body: describes `CVE-2023-20585`, requiring max supported event log
  buffer size on Milan/Genoa with SNP enabled; all other systems remain
  at 8K.
- Hidden bug fix: yes. This is phrased partly as buffer
  sizing/refactoring, but the purpose is a CVE security mitigation.

Phase 2 Record:
- Files changed: `drivers/iommu/amd/amd_iommu.h`, `amd_iommu_types.h`,
  `init.c`, `iommu.c`; fetched commit stat is 86 insertions, 38
  deletions.
- Functions modified/added: `alloc_event_buffer`,
  `iommu_enable_event_buffer`, `remap_event_buffer`,
  `early_enable_iommu`, `early_enable_iommus`, `amd_iommu_resume`, new
  `amd_iommu_apply_erratum_snp`, `state_next`, `amd_iommu_snp_disable`,
  `iommu_poll_events`.
- Code flow: event buffer allocation/enable moves from early per-IOMMU
  setup to after `iommu_snp_enable()`, allowing the erratum decision to
  set 512K before allocation/programming. Polling and SNP shutdown now
  use the variable size.
- Bug category: hardware security erratum/workaround.
- Fix quality: contained to AMD IOMMU event-log handling. Regression
  risk is medium-low because init ordering changes, but it is subsystem-
  contained, tested, and keeps non-SNP/non-Family-0x19 behavior at 8K.

Phase 3 Record:
- Blame/history: fixed 8K event buffer logic is long-standing; SNP
  integration relevant to the erratum is present from the v6.9 era and
  later. `6.12.y`, `6.18.y`, `6.19.y`, and `7.0.y` contain the
  integrated SNP enable commit checked locally; `5.15.y`, `6.1.y`, and
  `6.6.y` do not.
- `Fixes:` tag: none, so no direct original-bug commit to follow.
- Related file history: companion commit `1f44aab79bac3` does the same
  for the PPR log. Patch 2 depends conceptually/codewise on patch 1;
  patch 1 stands on its own for the event log.
- Author context: Vasant Hegde has multiple recent AMD IOMMU fixes in
  the fetched IOMMU fixes branch; Joerg Roedel committed the patch.
- Dependencies: no semantic dependency on the NUMA log-buffer allocation
  commit, but older stable branches have context differences requiring
  backport edits.

Phase 4 Record:
- `b4 dig -c 58c0ac6125d89`: found the original lore submission at `http
  s://patch.msgid.link/20260420084204.12263-2-vasant.hegde@amd.com`.
- `b4 dig -a`: only v1 found.
- `b4 dig -w`: original recipients included `iommu@lists.linux.dev`,
  Joerg Roedel, Will Deacon, Robin Murphy, Suravee Suthikulpanit, and
  Borislav Petkov.
- Lore thread: Dheeraj Kumar Srivastava replied `Tested-by`; Joerg
  Roedel replied “Applied to fixes”.
- AMD bulletin: AMD-SB-3016 confirms potential SNP guest integrity loss
  from an IOMMU host buffer out-of-bounds condition and says OS updates
  are required along with firmware.

Phase 5 Record:
- Callers: event interrupt path uses `amd_iommu_int_thread_evtlog()` ->
  `amd_iommu_handle_irq()` -> `iommu_poll_events()`. Interrupt setup is
  via AMD IOMMU MSI/INTCAPXT setup in `init.c`.
- Callees: allocation uses `iommu_alloc_4k_pages()`, which handles SNP
  4K page setup; enable writes `MMIO_EVT_BUF_OFFSET`, head/tail
  registers, and `CONTROL_EVT_LOG_EN`.
- Reachability: reachable on AMD IOMMU systems through hardware event
  interrupts and SNP init/shutdown paths, not through a direct userspace
  syscall.
- Similar pattern: companion PPR log patch in the same series mirrors
  the variable-size/max-buffer handling.

Phase 6 Record:
- Stable code existence: `6.12.y`, `6.18.y`, `6.19.y`, and `7.0.y` have
  the relevant AMD IOMMU SNP/event-log code. `5.15.y`, `6.1.y`, and
  `6.6.y` lack the integrated SNP enable commit I checked; `6.6.y` has
  an exported old SNP enable function but no in-tree caller was found.
- Backport difficulty: clean on `7.0.y`; direct apply failed on
  `6.12.y`, `6.18.y`, and `6.19.y`, so those need manual backporting.
- Related stable discussion: no stable-list-specific discussion for this
  CVE/patch was found by `lei`.

Phase 7 Record:
- Subsystem: AMD IOMMU driver under `drivers/iommu/amd`.
- Criticality: important platform/virtualization security code,
  affecting AMD EPYC SNP hosts rather than all systems.
- Activity: actively maintained; recent AMD IOMMU fixes and the
  maintainer-applied fixes branch confirm ongoing subsystem work.

Phase 8 Record:
- Affected users: AMD Family `0x19` Milan/Genoa systems with SNP
  enabled.
- Trigger/security conditions: AMD bulletin describes a privileged
  attacker with a compromised hypervisor triggering an out-of-bounds
  condition without RMP checks.
- Failure severity: security integrity impact for confidential SNP
  guests; AMD rates it Medium, but stable rules treat CVE/security
  mitigations as strong candidates.
- Benefit/risk: high benefit for affected SNP hosts; medium-low
  regression risk due to contained but non-trivial init-order and
  buffer-size changes.

Phase 9 Record:
- Evidence for: CVE/security mitigation, AMD bulletin requires OS
  update, tested-by, maintainer applied to fixes, scoped to AMD IOMMU,
  default behavior preserved for unaffected systems.
- Evidence against/concerns: patch is larger than a trivial one-liner,
  moves event buffer allocation/enable timing, and needs backport
  adjustments for several stable branches. Genoa full mitigation also
  needs the PPR companion patch.
- Stable rules: fixes a real security issue; important; no new userspace
  API; contained to one driver; tested; applies cleanly to `7.0.y` and
  can be backported with adjustments elsewhere.
- Exception category: hardware erratum/security workaround.

## Verification
- [Phase 1] Parsed fetched commit `58c0ac6125d89`: confirmed subject,
  tags, `Tested-by`, no `Fixes:`, and AMD-SB-3016 link.
- [Phase 2] Inspected diff/stat from fetched commit: 4 AMD IOMMU files,
  86 insertions, 38 deletions.
- [Phase 3] Ran `git blame` on event allocation, enable, SNP init, and
  polling paths; confirmed relevant code history.
- [Phase 3] Checked stable branch ancestry: `6.12.y+` contain integrated
  SNP enable; `5.15.y`, `6.1.y`, `6.6.y` do not.
- [Phase 4] Ran `b4 dig -c 58c0ac6125d89`, `-a`, and `-w`; found one v1
  submission, maintainers/recipients, and lore URL.
- [Phase 4] Fetched lore thread; confirmed `Tested-by` reply and
  maintainer “Applied to fixes”.
- [Phase 4] Fetched AMD bulletin; confirmed CVE impact and OS update
  requirement.
- [Phase 5] Traced event interrupt call path with source search/read:
  `amd_iommu_int_thread_evtlog()` to `iommu_poll_events()`.
- [Phase 6] Ran apply checks: clean on `stable/linux-7.0.y`; failed
  direct apply on `6.12.y`, `6.18.y`, and `6.19.y`.
- UNVERIFIED: I did not build-test the backport or test on AMD Family
  `0x19` SNP hardware.

**YES**

 drivers/iommu/amd/amd_iommu.h       |   2 +
 drivers/iommu/amd/amd_iommu_types.h |  10 ++-
 drivers/iommu/amd/init.c            | 110 +++++++++++++++++++---------
 drivers/iommu/amd/iommu.c           |   2 +-
 4 files changed, 86 insertions(+), 38 deletions(-)

diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 1342e764a5486..f1c486dcf0f38 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -11,6 +11,8 @@
 
 #include "amd_iommu_types.h"
 
+extern int amd_iommu_evtlog_size;
+
 irqreturn_t amd_iommu_int_thread(int irq, void *data);
 irqreturn_t amd_iommu_int_thread_evtlog(int irq, void *data);
 irqreturn_t amd_iommu_int_thread_pprlog(int irq, void *data);
diff --git a/drivers/iommu/amd/amd_iommu_types.h b/drivers/iommu/amd/amd_iommu_types.h
index c685d3771436a..c3430c09bc5c9 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -15,6 +15,7 @@
 #include <linux/mutex.h>
 #include <linux/msi.h>
 #include <linux/list.h>
+#include <linux/sizes.h>
 #include <linux/spinlock.h>
 #include <linux/pci.h>
 #include <linux/iommufd.h>
@@ -141,7 +142,6 @@
 #define MMIO_STATUS_GALOG_INT_MASK		BIT(10)
 
 /* event logging constants */
-#define EVENT_ENTRY_SIZE	0x10
 #define EVENT_TYPE_SHIFT	28
 #define EVENT_TYPE_MASK		0xf
 #define EVENT_TYPE_ILL_DEV	0x1
@@ -259,8 +259,12 @@
 #define MMIO_CMD_BUFFER_TAIL(x) FIELD_GET(MMIO_CMD_TAIL_MASK, (x))
 
 /* constants for event buffer handling */
-#define EVT_BUFFER_SIZE		8192 /* 512 entries */
-#define EVT_LEN_MASK		(0x9ULL << 56)
+#define EVTLOG_ENTRY_SIZE	0x10
+#define EVTLOG_SIZE_SHIFT	56
+#define EVTLOG_SIZE_DEF		SZ_8K /* 512 entries */
+#define EVTLOG_LEN_MASK_DEF	(0x9ULL << EVTLOG_SIZE_SHIFT)
+#define EVTLOG_SIZE_MAX		SZ_512K /* 32K entries */
+#define EVTLOG_LEN_MASK_MAX	(0xFULL << EVTLOG_SIZE_SHIFT)
 
 /* Constants for PPR Log handling */
 #define PPR_LOG_ENTRIES		512
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index f3fd7f39efb48..74effb847f488 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -132,6 +132,8 @@ struct ivhd_entry {
 	u8 uid;
 } __attribute__((packed));
 
+int amd_iommu_evtlog_size = EVTLOG_SIZE_DEF;
+
 /*
  * An AMD IOMMU memory definition structure. It defines things like exclusion
  * ranges for devices and regions that should be unity mapped.
@@ -864,35 +866,47 @@ void *__init iommu_alloc_4k_pages(struct amd_iommu *iommu, gfp_t gfp,
 }
 
 /* allocates the memory where the IOMMU will log its events to */
-static int __init alloc_event_buffer(struct amd_iommu *iommu)
+static int __init alloc_event_buffer(void)
 {
-	iommu->evt_buf = iommu_alloc_4k_pages(iommu, GFP_KERNEL,
-					      EVT_BUFFER_SIZE);
+	struct amd_iommu *iommu;
 
-	return iommu->evt_buf ? 0 : -ENOMEM;
+	for_each_iommu(iommu) {
+		iommu->evt_buf = iommu_alloc_4k_pages(iommu, GFP_KERNEL,
+						      amd_iommu_evtlog_size);
+		if (!iommu->evt_buf)
+			return -ENOMEM;
+	}
+
+	return 0;
 }
 
-static void iommu_enable_event_buffer(struct amd_iommu *iommu)
+static void iommu_enable_event_buffer(void)
 {
+	struct amd_iommu *iommu;
 	u64 entry;
 
-	BUG_ON(iommu->evt_buf == NULL);
+	for_each_iommu(iommu) {
+		BUG_ON(iommu->evt_buf == NULL);
 
-	if (!is_kdump_kernel()) {
-		/*
-		 * Event buffer is re-used for kdump kernel and setting
-		 * of MMIO register is not required.
-		 */
-		entry = iommu_virt_to_phys(iommu->evt_buf) | EVT_LEN_MASK;
-		memcpy_toio(iommu->mmio_base + MMIO_EVT_BUF_OFFSET,
-			    &entry, sizeof(entry));
-	}
+		if (!is_kdump_kernel()) {
+			/*
+			 * Event buffer is re-used for kdump kernel and setting
+			 * of MMIO register is not required.
+			 */
+			entry = iommu_virt_to_phys(iommu->evt_buf);
+			entry |= (amd_iommu_evtlog_size == EVTLOG_SIZE_DEF) ?
+				EVTLOG_LEN_MASK_DEF : EVTLOG_LEN_MASK_MAX;
+
+			memcpy_toio(iommu->mmio_base + MMIO_EVT_BUF_OFFSET,
+				    &entry, sizeof(entry));
+		}
 
-	/* set head and tail to zero manually */
-	writel(0x00, iommu->mmio_base + MMIO_EVT_HEAD_OFFSET);
-	writel(0x00, iommu->mmio_base + MMIO_EVT_TAIL_OFFSET);
+		/* set head and tail to zero manually */
+		writel(0x00, iommu->mmio_base + MMIO_EVT_HEAD_OFFSET);
+		writel(0x00, iommu->mmio_base + MMIO_EVT_TAIL_OFFSET);
 
-	iommu_feature_enable(iommu, CONTROL_EVT_LOG_EN);
+		iommu_feature_enable(iommu, CONTROL_EVT_LOG_EN);
+	}
 }
 
 /*
@@ -981,15 +995,20 @@ static int __init alloc_cwwb_sem(struct amd_iommu *iommu)
 	return 0;
 }
 
-static int __init remap_event_buffer(struct amd_iommu *iommu)
+static int __init remap_event_buffer(void)
 {
+	struct amd_iommu *iommu;
 	u64 paddr;
 
 	pr_info_once("Re-using event buffer from the previous kernel\n");
-	paddr = readq(iommu->mmio_base + MMIO_EVT_BUF_OFFSET) & PM_ADDR_MASK;
-	iommu->evt_buf = iommu_memremap(paddr, EVT_BUFFER_SIZE);
+	for_each_iommu(iommu) {
+		paddr = readq(iommu->mmio_base + MMIO_EVT_BUF_OFFSET) & PM_ADDR_MASK;
+		iommu->evt_buf = iommu_memremap(paddr, amd_iommu_evtlog_size);
+		if (!iommu->evt_buf)
+			return -ENOMEM;
+	}
 
-	return iommu->evt_buf ? 0 : -ENOMEM;
+	return 0;
 }
 
 static int __init remap_command_buffer(struct amd_iommu *iommu)
@@ -1041,10 +1060,6 @@ static int __init alloc_iommu_buffers(struct amd_iommu *iommu)
 		ret = remap_command_buffer(iommu);
 		if (ret)
 			return ret;
-
-		ret = remap_event_buffer(iommu);
-		if (ret)
-			return ret;
 	} else {
 		ret = alloc_cwwb_sem(iommu);
 		if (ret)
@@ -1053,10 +1068,6 @@ static int __init alloc_iommu_buffers(struct amd_iommu *iommu)
 		ret = alloc_command_buffer(iommu);
 		if (ret)
 			return ret;
-
-		ret = alloc_event_buffer(iommu);
-		if (ret)
-			return ret;
 	}
 
 	return 0;
@@ -2890,7 +2901,6 @@ static void early_enable_iommu(struct amd_iommu *iommu)
 	iommu_init_flags(iommu);
 	iommu_set_device_table(iommu);
 	iommu_enable_command_buffer(iommu);
-	iommu_enable_event_buffer(iommu);
 	iommu_set_exclusion_range(iommu);
 	iommu_enable_gt(iommu);
 	iommu_enable_ga(iommu);
@@ -2954,7 +2964,6 @@ static void early_enable_iommus(void)
 			iommu_disable_event_buffer(iommu);
 			iommu_disable_irtcachedis(iommu);
 			iommu_enable_command_buffer(iommu);
-			iommu_enable_event_buffer(iommu);
 			iommu_enable_ga(iommu);
 			iommu_enable_xt(iommu);
 			iommu_enable_irtcachedis(iommu);
@@ -3067,6 +3076,7 @@ static void amd_iommu_resume(void *data)
 	for_each_iommu(iommu)
 		early_enable_iommu(iommu);
 
+	iommu_enable_event_buffer();
 	amd_iommu_enable_interrupts();
 }
 
@@ -3396,6 +3406,23 @@ static __init void iommu_snp_enable(void)
 #endif
 }
 
+static void amd_iommu_apply_erratum_snp(void)
+{
+#ifdef CONFIG_KVM_AMD_SEV
+	if (!amd_iommu_snp_en)
+		return;
+
+	/* Errata fix for Family 0x19 */
+	if (boot_cpu_data.x86 != 0x19)
+		return;
+
+	/* Set event log buffer size to max */
+	amd_iommu_evtlog_size = EVTLOG_SIZE_MAX;
+	pr_info("Applying erratum: Increase Event log size to 0x%x\n",
+		amd_iommu_evtlog_size);
+#endif
+}
+
 /****************************************************************************
  *
  * AMD IOMMU Initialization State Machine
@@ -3432,6 +3459,21 @@ static int __init state_next(void)
 	case IOMMU_ENABLED:
 		register_syscore(&amd_iommu_syscore);
 		iommu_snp_enable();
+
+		amd_iommu_apply_erratum_snp();
+
+		/* Allocate/enable event log buffer */
+		if (is_kdump_kernel())
+			ret = remap_event_buffer();
+		else
+			ret = alloc_event_buffer();
+
+		if (ret) {
+			init_state = IOMMU_INIT_ERROR;
+			break;
+		}
+		iommu_enable_event_buffer();
+
 		ret = amd_iommu_init_pci();
 		init_state = ret ? IOMMU_INIT_ERROR : IOMMU_PCI_INIT;
 		break;
@@ -4034,7 +4076,7 @@ int amd_iommu_snp_disable(void)
 		return 0;
 
 	for_each_iommu(iommu) {
-		ret = iommu_make_shared(iommu->evt_buf, EVT_BUFFER_SIZE);
+		ret = iommu_make_shared(iommu->evt_buf, amd_iommu_evtlog_size);
 		if (ret)
 			return ret;
 
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 760d5f4623b55..02b5eaae6843d 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1009,7 +1009,7 @@ static void iommu_poll_events(struct amd_iommu *iommu)
 		iommu_print_event(iommu, iommu->evt_buf + head);
 
 		/* Update head pointer of hardware ring-buffer */
-		head = (head + EVENT_ENTRY_SIZE) % EVT_BUFFER_SIZE;
+		head = (head + EVTLOG_ENTRY_SIZE) % amd_iommu_evtlog_size;
 		writel(head, iommu->mmio_base + MMIO_EVT_HEAD_OFFSET);
 	}
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ALSA: usb-audio: add clock quirk for Motu 1248

[Sasha Levin]

From: Nicola Lunghi <nick83ola@gmail.com>

[ Upstream commit 320e55722ca466a7d40dd69e1aea982cb6189006 ]

The Motu 1248 (and probably other older Motu AVB interfaces) take more
than 2 seconds to switch clock. During the clock switching process the
device return that the clock is not valid. This is similar to what
already implemented for the Microbook II interface. Add the Motu
1248 usb id to the existing Motu quirk.

Signed-off-by: Nicola Lunghi <nick83ola@gmail.com>
Link: https://patch.msgid.link/20260504144520.699522-2-nick83ola@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

Phase 1:
- Record 1.1: Subsystem `ALSA: usb-audio`; action verb `add`; intent is
  to add Motu 1248 USB ID `07fd:0005` to an existing clock-validity
  delay quirk.
- Record 1.2: Tags: `Signed-off-by: Nicola Lunghi`, `Link:
  https://patch.msgid.link/20260504144520.699522-2-nick83ola@gmail.com`,
  `Signed-off-by: Takashi Iwai`. No `Fixes:`, `Reported-by:`, `Tested-
  by:`, `Reviewed-by:`, or `Cc: stable`.
- Record 1.3: Commit body describes Motu 1248 returning clock-invalid
  for more than 2 seconds while switching clock, causing the existing
  ALSA clock validation to fail too early. No kernel-version range
  given.
- Record 1.4: This is a hardware quirk fix, not a hidden
  memory/synchronization bug.

Phase 2:
- Record 2.1: One file changed: `sound/usb/clock.c`, `+11/-4`. Modified
  function: `uac_clock_source_is_valid_quirk()`. Single-file surgical
  hardware quirk.
- Record 2.2: Before: the 5-second retry loop applied only to
  `USB_ID(0x07fd, 0x0004)`. After: the same loop also applies to
  `USB_ID(0x07fd, 0x0005)`, with comments expanded.
- Record 2.3: Bug category is hardware workaround/device quirk.
  Mechanism: ALSA rechecks clock validity up to 50 times with
  `msleep(100)` instead of failing on the initial transient invalid
  response.
- Record 2.4: Fix quality is high: it reuses existing code and only
  widens the device match. Regression risk is very low and limited to
  MOTU product ID `0x0005`.

Phase 3:
- Record 3.1: `git blame` shows the existing MOTU retry quirk was
  introduced by `2edb84e3047b9` in 2020. Later nearby changes came from
  clock refactoring and multi-control-interface support, but the retry
  logic remains the same.
- Record 3.2: No `Fixes:` tag, so no introducing commit to follow.
- Record 3.3: Recent `sound/usb/clock.c` history shows related clock
  fixes/refactors, but this patch is standalone and only changes the
  device match.
- Record 3.4: Author has prior usb-audio quirk commits in local history;
  Takashi Iwai applied the patch and is the ALSA maintainer/committer
  for this area.
- Record 3.5: No functional dependencies found. The patch applies
  cleanly to checked pending stable branches.

Phase 4:
- Record 4.1: `b4 dig -c 320e55722ca46` found the original submission at
  the patch.msgid.link URL. `b4 dig -a` showed only `v1`; no newer
  revision found.
- Record 4.2: `b4 dig -w` showed Nicola Lunghi, Jaroslav Kysela, Takashi
  Iwai, `linux-sound`, `linux-kernel`, and `linux-usb` were included.
- Record 4.3: `b4 mbox` showed Takashi replied “Applied now. Thanks.” No
  objections or review concerns appeared in the two-message thread.
  WebFetch of lore was blocked by Anubis.
- Record 4.4: No multi-patch series or related required patches found.
- Record 4.5: Stable-list web search was blocked by Anubis; no stable-
  specific discussion was found through the available local/b4 data.

Phase 5:
- Record 5.1: Key function: `uac_clock_source_is_valid_quirk()`.
- Record 5.2: Call path verified: `uac_clock_source_is_valid()` calls
  the quirk when the device reports invalid clock;
  `__uac_clock_find_source()` and `set_sample_rate_v2v3()` call clock
  validation; setup is reached from format parsing, stream setup,
  endpoint preparation, and sample-rate initialization.
- Record 5.3: Key callees are `snd_usb_ctl_msg()`,
  `snd_usb_find_ctrl_interface()`, `snd_usb_find_clock_source()`, and
  `msleep(100)`.
- Record 5.4: Reachability is real for users of affected USB audio
  devices during sample-rate/clock setup and PCM endpoint preparation.
- Record 5.5: Similar existing pattern is the MicroBook IIc quirk for
  the same vendor and same delayed clock-validity behavior.

Phase 6:
- Record 6.1: The existing quirk code exists in checked pending stable
  branches `pending-5.4`, `pending-5.10`, `pending-5.15`, `pending-6.1`,
  `pending-6.6`, `pending-6.12`, and `pending-7.0`.
- Record 6.2: Backport difficulty is clean: `git apply --check`
  succeeded on all those pending branches.
- Record 6.3: No alternative Motu 1248 fix was found in local
  stable/current history.

Phase 7:
- Record 7.1: Subsystem is ALSA USB audio driver. Criticality: IMPORTANT
  for users of affected MOTU hardware, not core-wide.
- Record 7.2: Subsystem is active; recent history contains multiple usb-
  audio fixes and quirks.

Phase 8:
- Record 8.1: Affected users are driver/hardware-specific: Motu 1248 and
  likely related older MOTU AVB/hybrid devices with product ID `0x0005`.
- Record 8.2: Trigger is changing sample rate or clock source, or
  validation during device/audio setup. Unprivileged trigger depends on
  local audio-device permissions; I did not verify distro policy.
- Record 8.3: Failure mode is ALSA failing clock validation early,
  returning errors such as `-ENXIO` from the code path and preventing
  successful audio setup. Severity: MEDIUM for the kernel generally,
  HIGH for affected hardware usability.
- Record 8.4: Benefit is high for affected hardware; risk is very low
  because this only enables an existing quirk for one USB product ID.

Phase 9:
- Record 9.1: Evidence for backporting: real hardware quirk, existing
  stable-accepted mechanism, small single-file change, maintainer-
  applied, cleanly applies to stable branches, external CCRMA
  documentation corroborates MOTU 1248 Linux sample-rate failures that
  succeed after waiting. Evidence against: no crash/security/data-
  corruption, no explicit stable tag, and no direct reporter/tested-by
  tag.
- Record 9.2: Stable rules: obviously correct yes; fixes real user-
  visible hardware failure yes; important enough under hardware-quirk
  exception yes; small/contained yes; no new API/features yes; applies
  cleanly yes.
- Record 9.3: Exception category: hardware quirk/workaround for broken
  device timing behavior.
- Record 9.4: Decision: backport. This is exactly the kind of low-risk
  device-specific quirk stable trees routinely take.

## Verification

- Phase 1: Parsed commit `320e55722ca46` with `git show
  --format=fuller`; verified tags and message.
- Phase 2: Verified diff with `git show --find-renames` and `--numstat`:
  `sound/usb/clock.c`, `+11/-4`.
- Phase 3: Ran `git blame -L 179,240 -- sound/usb/clock.c`; identified
  existing quirk origin `2edb84e3047b9`.
- Phase 3: Checked recent file history with `git log --oneline -20 --
  sound/usb/clock.c`.
- Phase 4: Ran `b4 dig -c 320e55722ca46`, `-a`, and `-w`; confirmed v1
  patch, recipients, and lore URL.
- Phase 4: Ran `b4 mbox`; confirmed Takashi’s “Applied now” reply and no
  objections in the fetched thread.
- Phase 5: Used `rg` and file reads to trace callers through `clock.c`,
  `format.c`, `endpoint.c`, `stream.c`, and `quirks.c`.
- Phase 6: Checked quirk presence in pending stable branches and
  verified `git apply --check` cleanly on `pending-5.4`, `pending-5.10`,
  `pending-5.15`, `pending-6.1`, `pending-6.6`, `pending-6.12`, and
  `pending-7.0`.
- Phase 8: Used WebFetch of CCRMA MOTU 1248 documentation; it reports
  Linux output/sample-rate attempts may fail initially and succeed after
  5-10 seconds.
- UNVERIFIED: Exact USB ID mapping for every model listed in the new
  comment beyond the commit’s own statement.

**YES**

 sound/usb/clock.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/sound/usb/clock.c b/sound/usb/clock.c
index 842ba5b801eae..2e0c18e352812 100644
--- a/sound/usb/clock.c
+++ b/sound/usb/clock.c
@@ -208,11 +208,18 @@ static bool uac_clock_source_is_valid_quirk(struct snd_usb_audio *chip,
 	}
 
 	/*
-	 * MOTU MicroBook IIc
-	 * Sample rate changes takes more than 2 seconds for this device. Clock
-	 * validity request returns false during that period.
+	 * Quirk for older MOTU AVB / hybrid interfaces
+	 *
+	 * These devices take more than 2 seconds to switch sample rate or
+	 * clock source. During this period the clock validity request
+	 * returns false, causing ALSA to fail prematurely.
+	 *
+	 * Affected models (all use vendor 0x07fd):
+	 *   - MicroBook IIc          → 0x0004
+	 *   - 1248, 624, 8A, UltraLite AVB, 8M, 16A, ... → 0x0005
 	 */
-	if (chip->usb_id == USB_ID(0x07fd, 0x0004)) {
+	if (chip->usb_id == USB_ID(0x07fd, 0x0004) ||  /* MicroBook IIc */
+	    chip->usb_id == USB_ID(0x07fd, 0x0005)) {  /* 1248 / 624 / 8A / UltraLite AVB / ... */
 		count = 0;
 
 		while ((!ret) && (count < 50)) {
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] workqueue: Release PENDING in __queue_work() drain/destroy reject path

[Sasha Levin]

From: Breno Leitao <leitao@debian.org>

[ Upstream commit a7488f089bdfa87c4fef1744d4dca9f4f8b46f8b ]

The caller of __queue_work() owns WORK_STRUCT_PENDING, won via
test_and_set_bit() in queue_work_on()/__queue_delayed_work(). The
state machine documented above __queue_work() requires that owner
to either hand the token to a pwq (insert_work() -> set_work_pwq()),
hand it to a timer, or release it via set_work_pool_and_clear_pending().
try_to_grab_pending() relies on this: when it observes
"PENDING && off-queue" it busy-loops, trusting the current owner to
make progress.

The (__WQ_DESTROYING | __WQ_DRAINING) early-return path violates that
contract. It WARN_ONCE()s and bare-returns, leaving work->data with
PENDING set, WORK_STRUCT_PWQ clear, and work->entry empty.

The path is reachable without explicit API abuse: queue_delayed_work()
arms a timer with PENDING set; if drain_workqueue() runs while the
timer is still pending, delayed_work_timer_fn() -> __queue_work() in
softirq context hits the WARN, current is not a wq worker so
is_chained_work() is false, and the work is silently dropped with
PENDING leaked.

Mirror what clear_pending_if_disabled() already does on its analogous
reject path: unpack the off-queue data and call
set_work_pool_and_clear_pending() to release the token before
returning.

I was able to reproduce this by queueing several slow works on
a max_active=1 wq, arm a delayed_work whose timer fires while
drain_workqueue() is blocked, then call cancel_delayed_work_sync().
Without this patch the cancel livelocks at 100% CPU; with it the cancel
returns immediately.

Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record 1.1: Subsystem `workqueue`; action verb `Release`; intent: clear
`WORK_STRUCT_PENDING` when `__queue_work()` rejects work during
drain/destroy.

Record 1.2: Commit tags: `Signed-off-by: Breno Leitao
<leitao@debian.org>` and `Signed-off-by: Tejun Heo <tj@kernel.org>`. No
committed `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`,
`Acked-by:`, `Link:`, or `Cc: stable@vger.kernel.org`.

Record 1.3: The body describes a real state-machine bug:
`__queue_work()` may return from the `__WQ_DESTROYING | __WQ_DRAINING`
reject path with `PENDING` still set while the work is off-queue.
`try_to_grab_pending()` then sees `PENDING && off-queue` and busy-
retries. The verified failure mode is `cancel_delayed_work_sync()`
livelocking at 100% CPU after a delayed timer fires during
`drain_workqueue()`.

Record 1.4: This is not a hidden cleanup; it is an explicit correctness
fix for a leaked pending token causing livelock.

### Phase 2: Diff Analysis
Record 2.1: One file changed: `kernel/workqueue.c`, 12 insertions. One
function changed: `__queue_work()`. Scope: single-file surgical core
workqueue fix.

Record 2.2: Before: reject path warned and returned directly. After:
reject path unpacks off-queue work data and calls
`set_work_pool_and_clear_pending()` before returning.

Record 2.3: Bug category: workqueue state-machine/token leak with a race
between delayed-work timer execution and draining/destroying a
workqueue. Mechanism: queued delayed work owns `PENDING`; timer callback
enters `__queue_work()`; reject path drops the work but did not release
`PENDING`.

Record 2.4: Fix quality is high. It mirrors the existing
`clear_pending_if_disabled()` pattern in the same file and does not add
an API or change normal queueing behavior. Regression risk is low; the
change is limited to an already-rejecting path.

### Phase 3: Git History
Record 3.1: `git blame` shows the PENDING/off-queue busy-loop contract
comment came from `8930caba3dbd`; the drain reject mechanism is rooted
in `9c5a2ba70251` (`v3.1`), and the destroy-side diagnostic flag came
from `33e3f0a3358b` (`v6.3`). The bare reject `return` traces back to
`e41e704bc4f4` (`v2.6.36-rc4` era).

Record 3.2: No committed `Fixes:` tag. I inspected the patch-thread note
suggesting `e41e704bc4f4`; that commit added the “warn and ignore”
dying-workqueue behavior.

Record 3.3: Recent `kernel/workqueue.c` history shows nearby independent
workqueue fixes and diagnostics; this patch is standalone, not a multi-
patch series dependency.

Record 3.4: Breno Leitao has multiple recent workqueue commits in
`origin/master`; Tejun Heo, the workqueue maintainer, committed this
patch.

Record 3.5: Dependencies: conceptually standalone. Exact patch applies
cleanly to `v6.18.32`, `v6.19.14`, `v7.0`, and `v7.0.9`; older trees
need small backport adjustment because helper APIs and warning text
differ.

### Phase 4: Mailing List / External Research
Record 4.1: `b4 dig -c a7488f089bdfa` found the original thread: `https:
//patch.msgid.link/20260507-workqueue_pending-v1-1-
3a53e2facf4e@debian.org`. Series revisions: v1 only.

Record 4.2: Original recipients included Breno Leitao, Tejun Heo, Lai
Jiangshan, `linux-kernel@vger.kernel.org`, `clm@meta.com`, and `kernel-
team@meta.com`. Tejun replied that it was applied to `wq/for-7.1-fixes`.

Record 4.3: No external bug report or syzbot link in this commit. The
bug report evidence is the author’s concrete reproducer in the
commit/thread.

Record 4.4: No related patch series found; b4 reports a single-patch v1.

Record 4.5: Web search found no stable-specific discussion for this
exact patch. Lore WebFetch was blocked by Anubis, but b4 successfully
fetched the mbox.

### Phase 5: Code Semantic Analysis
Record 5.1: Modified function: `__queue_work()`.

Record 5.2: Callers verified in `kernel/workqueue.c`: `queue_work_on()`,
`queue_work_node()`, `delayed_work_timer_fn()`, zero-delay
`__queue_delayed_work()`, `rcu_work_rcufn()`, and requeue paths. The
relevant caller is `delayed_work_timer_fn()`.

Record 5.3: Key callees: `is_chained_work()`, `work_offqd_unpack()`,
`set_work_pool_and_clear_pending()`, and, on non-reject paths, pool
selection plus `insert_work()`.

Record 5.4: Verified call chain: `queue_delayed_work_on()` sets
`PENDING`; `__queue_delayed_work()` arms the timer;
`delayed_work_timer_fn()` calls `__queue_work()`; `drain_workqueue()`
sets `__WQ_DRAINING`; `cancel_delayed_work_sync()` reaches
`try_to_grab_pending()` through `work_grab_pending()` and can spin on
`-EAGAIN`. Direct unprivileged trigger was not verified.

Record 5.5: Similar in-tree pattern verified:
`clear_pending_if_disabled()` already unpacks off-queue data and clears
pending in an analogous reject path.

### Phase 6: Stable Tree Analysis
Record 6.1: The buggy drain reject path exists in checked tags from
`v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.18`, `v6.19`, and
`v7.0`. Drain behavior dates back to `v3.1`.

Record 6.2: Backport difficulty: clean for `v6.18+` and `v7.0`; minor
manual backport for `v6.12`; more adjustment for `v6.6` and older
because `work_offqd_unpack()`/flags helpers differ or are absent.

Record 6.3: I found no exact related fix already present by subject in
checked stable branches.

### Phase 7: Subsystem Context
Record 7.1: Subsystem is core workqueue infrastructure. Criticality:
CORE, because workqueues are used throughout drivers, filesystems,
networking, storage, GPU, and core kernel code.

Record 7.2: Workqueue is actively maintained, with recent commits by
Breno Leitao and Tejun Heo, but the affected state machine is mature and
present across long-lived stable lines.

### Phase 8: Impact / Risk
Record 8.1: Affected population: broad kernel users, but trigger-
specific to users of delayed work on workqueues being drained or
destroyed.

Record 8.2: Trigger: delayed-work timer fires while `drain_workqueue()`
or destroy-time draining is active, followed by cancellation/grab of
that delayed work. Commonness is workload dependent; direct unprivileged
reachability was not verified.

Record 8.3: Failure mode: livelock at 100% CPU in
`cancel_delayed_work_sync()`. Severity: HIGH, potentially CRITICAL for
teardown/suspend/remove paths that must complete.

Record 8.4: Benefit high: prevents a real hang/livelock in core
infrastructure. Risk low: 12-line change, reject path only, mirrors
existing cleanup logic.

### Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: real reproduced livelock, core
subsystem, broad stable-tree presence, small fix, maintainer-applied, no
new API. Evidence against: exact patch does not cleanly apply to older
stable trees and lacks independent `Tested-by`; older trees need careful
helper-specific backports. Unresolved: no independent bug report found,
no direct unprivileged trigger verified.

Record 9.2: Stable rules: obviously correct and self-tested: yes; fixes
real bug: yes; important issue: yes, livelock/hang; small and contained:
yes, one function and 12 lines; no new features/APIs: yes; applies to
stable: clean for newer stable, minor/manual for older.

Record 9.3: No exception category applies; this is a core bug fix, not a
device ID, quirk, DT, build, or documentation change.

Record 9.4: Decision: backport. The technical merit is strong: this
fixes a verified workqueue livelock with a small, localized, maintainer-
accepted change.

## Verification
- Phase 1: Parsed `git show --format=fuller` for `a7488f089bdfa`;
  confirmed tags and commit body.
- Phase 2: Inspected the diff; confirmed only `kernel/workqueue.c`
  changed with 12 insertions in `__queue_work()`.
- Phase 3: Used `git blame`, `git show`, `git describe --contains`, and
  path-limited `git log`; confirmed historical origins and stable
  version presence.
- Phase 4: Used `b4 dig -c`, `-a`, `-w`, and mbox fetch; confirmed v1
  patch and Tejun’s apply reply. WebFetch to lore was blocked.
- Phase 5: Used `rg` and `ReadFile` to trace callers/callees and the
  delayed-work/cancel path.
- Phase 6: Checked specific stable tags and ran patch apply checks in
  temporary worktrees; confirmed clean apply for `v6.18+` and backport
  needs for older trees.
- Phase 7: Verified subsystem path and recent workqueue history.
- Phase 8: Verified failure mode from commit body and matching code
  path; unprivileged trigger remains unverified.

**YES**

 kernel/workqueue.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c6ea96d5b7167..2c512b4a74482 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2281,6 +2281,18 @@ static void __queue_work(int cpu, struct workqueue_struct *wq,
 	if (unlikely(wq->flags & (__WQ_DESTROYING | __WQ_DRAINING) &&
 		     WARN_ONCE(!is_chained_work(wq), "workqueue: cannot queue %ps on wq %s\n",
 			       work->func, wq->name))) {
+		struct work_offq_data offqd;
+
+		/*
+		 * State on entry: PENDING is set, work is off-queue (no
+		 * insert_work() has run).
+		 *
+		 * Returning without clearing PENDING would leave the work
+		 * in a weird state (PENDING=1, PWQ=0, entry empty)
+		 */
+		work_offqd_unpack(&offqd, *work_data_bits(work));
+		set_work_pool_and_clear_pending(work, offqd.pool_id,
+						work_offqd_pack_flags(&offqd));
 		return;
 	}
 	rcu_read_lock();
-- 
2.53.0

[PATCH AUTOSEL 7.0] ASoC: sdw_utils: avoid the SDCA companion function not supported failure

[Sasha Levin]

From: Derek Fang <derek.fang@realtek.com>

[ Upstream commit 56d5a9eaf60af5c824a33a83e1468aa143627a62 ]

Treat the companion amp as generic AMP until full support for companion
amp is added.

Signed-off-by: Derek Fang <derek.fang@realtek.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://patch.msgid.link/20260430121043.552241-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `ASoC: sdw_utils`; action verb `avoid`;
claimed intent is to avoid SDCA companion amp being treated as
unsupported.

Step 1.2 Record: tags present:
- `Signed-off-by: Derek Fang <derek.fang@realtek.com>`
- `Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>`
- `Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>`
- `Link: https://patch.msgid.link/20260430121043.552241-1-yung-
  chuan.liao@linux.intel.com`
- `Signed-off-by: Mark Brown <broonie@kernel.org>`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-by:`, or `Cc:
stable@vger.kernel.org` tags were present.

Step 1.3 Record: the body says companion amps should be treated as
generic amps until full companion-amp support exists. The user-visible
symptom implied by the subject and code is an SDCA companion amp being
classified as unsupported. No stack trace, crash, version statement, or
bug report is included.

Step 1.4 Record: this is a hidden bug fix. The verb “avoid” plus the
one-line mapping change fixes incorrect handling of a valid SDCA
function type that was already accepted elsewhere in the SDCA code.

## Phase 2: Diff Analysis
Step 2.1 Record: one file changed,
`sound/soc/sdw_utils/soc_sdw_utils.c`, one line added. Modified
function: `asoc_sdw_get_dai_type()`. Scope: single-file surgical logic
fix.

Step 2.2 Record: before the patch, `SDCA_FUNCTION_TYPE_COMPANION_AMP`
fell through to `default` and returned `-EINVAL`. After the patch, it
returns `SOC_SDW_DAI_TYPE_AMP`, like smart and simple amp function
types. This affects SDCA endpoint detection and SOF SoundWire endpoint
construction paths that call `asoc_sdw_get_dai_type()`.

Step 2.3 Record: bug category is logic/correctness plus hardware
compatibility. The broken mechanism is that a valid SDCA companion amp
function type was known to SDCA parsing code but not known to the SDW
DAI-type mapper, so amp endpoint matching could fail.

Step 2.4 Record: the fix is obviously small and locally correct:
“companion amp” is mapped into the existing amp class. Regression risk
is very low; the only behavior change is for devices reporting
`SDCA_FUNCTION_TYPE_COMPANION_AMP`.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` on the pre-fix switch shows
`asoc_sdw_get_dai_type()` and its default `-EINVAL` mapping came from
`4f8ef33dd44a3d` (“ASoC: soc_sdw_utils: skip the endpoint that doesn't
present”), first contained from v6.16. The actual companion-amp exposure
came later from `f5cb3ee251b4f` (“ASoC: SDCA: Add companion amp
Function”), first contained from v6.19.

Step 3.2 Record: no `Fixes:` tag is present, so no tag target exists to
follow. The likely prerequisite/regression source was verified
separately as `f5cb3ee251b4f`, which added
`SDCA_FUNCTION_TYPE_COMPANION_AMP` to `include/sound/sdca_function.h`
and `sound/soc/sdca/sdca_functions.c`.

Step 3.3 Record: recent history for `soc_sdw_utils.c` shows active
SDCA/SoundWire endpoint work. Related commits include `506cbe36a2ac7b`
exporting `asoc_sdw_get_dai_type()`, `f5cb3ee251b4f` adding the
companion amp function type, and later SDCA/sdw_utils fixes. This patch
is standalone except that it only applies meaningfully to trees already
containing the companion-amp enum.

Step 3.4 Record: Derek Fang has multiple Realtek ASoC codec commits,
including the RT1017 SDCA amplifier driver. Bard Liao has many
SDW/SOF/ASoC commits in this area and is listed as an SDCA reviewer in
`MAINTAINERS`.

Step 3.5 Record: dependency identified:
`SDCA_FUNCTION_TYPE_COMPANION_AMP` must exist. It is present in v6.19
and v7.0, absent in v6.18. The patch should not be applied to older
trees unless that enum support is also present.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 56d5a9eaf60a` matched the original patch by
exact patch-id at the supplied patch link. `b4 dig -a` found only v1 of
a single-patch series. No newer revision was found.

Step 4.2 Record: `b4 dig -w` showed the original recipients included
Bard Liao, Mark Brown, Takashi Iwai, `linux-sound@vger.kernel.org`,
Intel/Realtek audio contributors, and Derek Fang. The patch carries
`Reviewed-by: Charles Keepax`, who is listed as an SDCA maintainer.

Step 4.3 Record: no bug-report link or `Reported-by` tag exists.
Web/lore fetches for the search pages were blocked by Anubis, but `b4`
successfully fetched the actual thread. No syzbot or user bug report was
found.

Step 4.4 Record: `b4 dig -a` shows this is not part of a multi-patch
series. Local related-patch search found `f5cb3ee251b4f` as the
companion-amp type addition, which is the important dependency/context.

Step 4.5 Record: no stable-specific discussion was found in local stable
tag history or web search. No reviewer stable nomination was found in
the fetched thread.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified function: `asoc_sdw_get_dai_type()`.

Step 5.2 Record: callers found:
- `is_sdca_endpoint_present()` in `sound/soc/sdw_utils/soc_sdw_utils.c`,
  used while parsing SoundWire endpoints for ASoC machine drivers.
- `is_endpoint_present()` in `sound/soc/sof/intel/hda.c`, present in
  v7.0 and later, used while building default SoundWire machine
  descriptions from detected peripherals.

Step 5.3 Record: key callees/side effects: `is_sdca_endpoint_present()`
gets a SoundWire device by name, checks `slave->sdca_data`, loops over
firmware-provided SDCA functions, and skips endpoints if no matching DAI
type is found. The SOF HDA path similarly checks
`sdw_device->sdca_data.function[]` before adding endpoints.

Step 5.4 Record: reachability is verified through machine-driver setup
paths: Intel `sof_sdw`, AMD ACP SDW SOF, and AMD ACP SDW legacy machine
drivers call `asoc_sdw_parse_sdw_endpoints()`. The HDA default machine
path calls `find_acpi_adr_device()` during SoundWire machine selection.
This is boot/probe-time hardware enumeration, not an unprivileged
syscall path.

Step 5.5 Record: similar pattern search found
`SDCA_FUNCTION_TYPE_COMPANION_AMP` handled in the SDCA name parser but
missing from the DAI-type mapper before this patch. No other
`asoc_sdw_get_dai_type()` companion mapping existed before the fix.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: v6.18 has `asoc_sdw_get_dai_type()` but no
`SDCA_FUNCTION_TYPE_COMPANION_AMP`. v6.19 and v7.0 contain the companion
enum/name support but lack this mapper case. v7.1-rc3 contains the fix.
Therefore the affected stable trees are v6.19.y and v7.0.y, not older
trees lacking `f5cb3ee251b4f`.

Step 6.2 Record: `git apply --check` of the target patch succeeded on
the current checkout, which is v7.0.5. The v6.19 helper context around
`SDCA_FUNCTION_TYPE_SIMPLE_AMP` matches the same missing-case pattern,
so expected v6.19 backport difficulty is clean or trivial.

Step 6.3 Record: local stable history checks for v6.19.y and v7.0.y
found no existing stable commit with this subject. v7.1-rc3 contains
`56d5a9eaf60a`.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is ASoC SoundWire/SDCA audio support.
Criticality is driver/platform-specific, important for affected
SoundWire laptop/audio hardware but not universal core kernel code.

Step 7.2 Record: subsystem activity is high; recent history shows many
SDCA and `sdw_utils` changes across v6.19 to v7.1. This is a newer,
actively evolving area, which reinforces the dependency check.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected users are systems with SoundWire SDCA devices
reporting companion amp functions, especially Intel/AMD SoundWire laptop
audio configurations using these helper paths.

Step 8.2 Record: trigger condition is hardware/firmware enumeration
where `slave->sdca_data.function[i].type` is
`SDCA_FUNCTION_TYPE_COMPANION_AMP`. It happens during boot/probe/machine
selection, not from unprivileged userspace.

Step 8.3 Record: failure mode is endpoint/DAI detection failure: the
companion amp can be treated as unsupported and skipped or not included
in generated SoundWire endpoint data. Severity is medium for the general
kernel, high for affected hardware because it can break audio amp
availability.

Step 8.4 Record: benefit is high for affected hardware and low-risk
globally. Risk is very low: one added switch case, no new API, no
locking, no memory lifetime changes, and no behavior change for other
function types.

## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting:
- Fixes real incorrect handling of an already-defined SDCA companion amp
  type.
- Prevents affected SoundWire audio endpoints from being classified
  unsupported.
- One-line, single-function, single-file change.
- Reviewed by Charles Keepax; applied by Mark Brown; relevant
  maintainers/lists were included.
- Applies to stable trees that already contain `f5cb3ee251b4f`, verified
  for v6.19/v7.0 presence.

Evidence against backporting:
- No crash, data corruption, security issue, syzbot report, or explicit
  stable tag.
- It is hardware/functionality enablement rather than a core reliability
  fix.
- It must not be applied to trees without
  `SDCA_FUNCTION_TYPE_COMPANION_AMP`.

Unresolved questions:
- No external user bug report was found, so exact affected product count
  is unverified.
- I did not run a full v6.19 worktree apply test, but verified matching
  context and dependency presence.

Step 9.2 Stable rules:
1. Obviously correct and tested? Yes for correctness by code inspection;
   no explicit `Tested-by` on this patch.
2. Fixes a real bug? Yes, incorrect mapping of a valid SDCA companion
   amp function.
3. Important issue? Yes for affected hardware audio functionality,
   though not crash/security.
4. Small and contained? Yes, one line in one function.
5. No new feature/API? Yes, it uses an existing enum and existing DAI
   type.
6. Can apply to stable? Yes for v7.0.5 verified; expected trivial for
   v6.19.y; not applicable to older trees lacking the enum.

Step 9.3 Exception category: closest category is hardware
compatibility/workaround for existing SoundWire SDCA audio support. It
is not a new driver or new userspace API.

Step 9.4 Decision: backport to stable trees that already include
`f5cb3ee251b4f` (`SDCA_FUNCTION_TYPE_COMPANION_AMP`), notably v6.19.y
and v7.0.y. Do not backport to older trees unless that prerequisite is
intentionally present.

## Verification
- [Phase 1] Parsed commit `56d5a9eaf60a` with `git show`; confirmed
  subject, body, tags, and one-file/one-line patch.
- [Phase 2] Inspected diff; confirmed only `asoc_sdw_get_dai_type()`
  adds `SDCA_FUNCTION_TYPE_COMPANION_AMP` to the amp cases.
- [Phase 3] `git blame 56d5a9eaf60a^` showed the mapper switch came from
  `4f8ef33dd44a3d`; `git show f5cb3ee251b4f` confirmed companion amp
  enum/name support was added later.
- [Phase 3] `git tag --contains f5cb3ee...` showed companion amp support
  starts at v6.19; `git grep` confirmed absent in v6.18 and present in
  v6.19/v7.0.
- [Phase 4] `b4 dig -c 56d5a9eaf60a` found the original patch thread;
  `b4 dig -a` showed only v1; `b4 dig -w` showed original recipients.
- [Phase 4] Fetched the mbox with `b4`; confirmed Mark Brown applied it
  to `sound.git for-7.1` and no NAK/objection appeared in the fetched
  thread.
- [Phase 5] `rg` found callers in `is_sdca_endpoint_present()` and SOF
  HDA `is_endpoint_present()`; file reads verified endpoint filtering
  behavior.
- [Phase 6] `git grep` across v6.18/v6.19/v7.0/v7.1-rc3 verified where
  the enum and fix exist.
- [Phase 6] `git apply --check` verified the patch applies cleanly to
  current v7.0.5.
- [Phase 7] `MAINTAINERS` verified Mark Brown as ASoC maintainer and
  Charles Keepax/Bard Liao as SDCA maintainer/reviewer contacts.
- [Phase 8] Failure mode was verified from code paths that skip
  endpoints when no matching DAI type is found.
- UNVERIFIED: exact real-world affected laptop/device count; no public
  bug report was found.

**YES**

 sound/soc/sdw_utils/soc_sdw_utils.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/sdw_utils/soc_sdw_utils.c b/sound/soc/sdw_utils/soc_sdw_utils.c
index 0e67d9f34cba3..2b4b54e8241e6 100644
--- a/sound/soc/sdw_utils/soc_sdw_utils.c
+++ b/sound/soc/sdw_utils/soc_sdw_utils.c
@@ -1400,6 +1400,7 @@ int asoc_sdw_get_dai_type(u32 type)
 	switch (type) {
 	case SDCA_FUNCTION_TYPE_SMART_AMP:
 	case SDCA_FUNCTION_TYPE_SIMPLE_AMP:
+	case SDCA_FUNCTION_TYPE_COMPANION_AMP:
 		return SOC_SDW_DAI_TYPE_AMP;
 	case SDCA_FUNCTION_TYPE_SMART_MIC:
 	case SDCA_FUNCTION_TYPE_SIMPLE_MIC:
-- 
2.53.0

[PATCH AUTOSEL 7.0] Documentation: security-bugs: do not systematically Cc the security team

[Sasha Levin]

From: Willy Tarreau <w@1wt.eu>

[ Upstream commit aed3c3346765e4317bb2ec6ff872e1c952e128ab ]

With the increase of automated reports, the security team is dealing
with way more messages than really needed. The reporting process works
well with most teams so there is no need to systematically involve the
security team in reports.

Let's suggest to keep it for small lists of recipients and new reporters
only. This should continue to cover the risk of lost messages while
reducing the volume from prolific reporters.

Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260509094755.2838-2-w@1wt.eu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `Documentation/process/security-bugs`; action verb
`do not`; intent is to update security bug reporting instructions so
reporters do not always Cc the security team.

Record 1.2: Tags present: `Cc: Greg KH <gregkh@linuxfoundation.org>`,
`Cc: Leon Romanovsky <leon@kernel.org>`, `Reviewed-by: Leon Romanovsky
<leon@kernel.org>`, `Reviewed-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>`, `Signed-off-by: Willy Tarreau
<w@1wt.eu>`, `Signed-off-by: Jonathan Corbet <corbet@lwn.net>`,
`Message-ID: <20260509094755.2838-2-w@1wt.eu>`. No `Fixes:`, no
`Reported-by:`, no `Tested-by:`, no `Cc: stable`.

Record 1.3: The body describes a process/documentation problem:
increased automated reports create more mail to the security team than
needed. Symptom is excess security-team involvement, not a kernel
runtime crash or data corruption. No affected kernel versions are named.

Record 1.4: This is not a hidden code bug fix. It is an explicit
documentation/process update that corrects now-overbroad guidance.

## Phase 2: Diff Analysis
Record 2.1: One file changed: `Documentation/process/security-bugs.rst`,
9 insertions and 1 deletion in the submitted patch. No functions are
modified. Scope is single-file documentation-only.

Record 2.2: Before: reports “must” be sent to maintainers with the
security team in Cc. After: reports still go to maintainers, but
security-team Cc is mandatory only for two-or-fewer recipients, advised
for early reports or specific help, and no longer necessary for
comfortable reporters sending to large teams.

Record 2.3: Bug category is documentation/process correctness. No
resource leak, race, memory safety, refcount, initialization, endian, or
hardware quirk mechanism exists.

Record 2.4: Fix quality is high for its scope: small, reviewed,
documentation-only, no runtime behavior. Regression risk is limited to
possibly changing reporter behavior; no kernel runtime regression is
possible from the diff itself.

## Phase 3: Git History Investigation
Record 3.1: `git blame` shows the replaced sentence was introduced by
`a72b832a482372` (“Documentation: explain how to find maintainers
addresses for security reports”), first contained by `v7.0-rc7~8^2~2`.

Record 3.2: No `Fixes:` tag is present, so there is no Fixes target to
follow.

Record 3.3: Recent history of `Documentation/process/security-bugs.rst`
shows a series of security-reporting documentation updates by Willy
Tarreau, including contact/process clarifications and typo fixes. This
patch is standalone at the diff level but part of a three-patch
documentation series.

Record 3.4: The author has multiple recent commits in
`Documentation/process/security-bugs.rst`. Maintainer lookup identifies
`Security Officers <security@kernel.org>` and `Jonathan Corbet
<corbet@lwn.net>` for this file.

Record 3.5: No code dependencies or functions exist. The exact patch
depends on the newer rewritten security-bugs document layout present in
`7.0.y`; older stable branches do not contain `a72b832a482372`.

## Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c` could not be used because no candidate commit
SHA was available locally or in the prompt, and local `master`, `docs-
next`, and `all-next` searches did not find the commit object. Using the
supplied Message-ID, `b4 am` found the original submission at
`https://patch.msgid.link/20260509094755.2838-1-w@1wt.eu`.

Record 4.2: `b4 am` and the mbox show v3 of a 3-patch series, 33 thread
messages, sent to Greg KH, Leon Romanovsky, Jonathan Corbet, Shuah Khan,
`security@kernel.org`, `workflows@vger.kernel.org`, `linux-
doc@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.

Record 4.3: No bug report link, syzbot report, Bugzilla report, or user
crash report exists. Lore WebFetch was blocked by Anubis, but `b4`
successfully fetched the mbox.

Record 4.4: Series context: patch 1/3 is this Cc guidance change; patch
2/3 adds security-bug/threat-model documentation; patch 3/3 clarifies
AI-assisted reports. Cover letter says v2 reworded the “when to Cc” part
based on Greg’s feedback; v3 included wording/structure feedback and
added reviews.

Record 4.5: I found no stable-specific discussion or stable nomination
in the fetched thread. Jonathan Corbet said he applied the series to
`docs-fixes` after short linux-next exposure.

## Phase 5: Code Semantic Analysis
Record 5.1: No functions modified; documentation only.

Record 5.2: No callers; affected audience is readers of
`Documentation/process/security-bugs.rst`.

Record 5.3: No callees or side effects.

Record 5.4: Reachability is not runtime reachability. The path is
“reporter reads stable-tree documentation and follows reporting
instructions.”

Record 5.5: `rg` found the old mandatory-Cc sentence only in
`Documentation/process/security-bugs.rst`; related security-team
references remain elsewhere in the same document.

## Phase 6: Cross-Referencing And Stable Tree Analysis
Record 6.1: `a72b832a482372` is an ancestor of `stable/linux-7.0.y` but
not of local `stable/linux-5.15.y`, `stable/linux-6.1.y`,
`stable/linux-6.6.y`, `stable/linux-6.12.y`, `stable/linux-6.18.y`, or
`stable/linux-6.19.y`. So this exact buggy/obsolete sentence is
confirmed in `7.0.y`; older local stable trees have older document
layouts.

Record 6.2: `b4` reports the series base applies cleanly to the current
tree, which is `stable/linux-7.0.y`. Older stable trees would need a
different documentation backport if maintainers wanted equivalent
guidance there.

Record 6.3: No related stable fix for this exact wording was found in
local history.

## Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is documentation/process, specifically security
bug reporting. Criticality is process-important, not runtime
core/driver/filesystem criticality.

Record 7.2: The file has active recent development, with several
2025-2026 security-reporting documentation updates.

## Phase 8: Impact And Risk Assessment
Record 8.1: Affected population is documentation readers: security bug
reporters, maintainers, and the kernel security team. No running kernel
users are directly affected.

Record 8.2: Trigger is following the stable tree’s security-bug
reporting documentation. This can be done by any reporter, but it is not
a syscall or kernel execution path.

Record 8.3: Failure mode severity is low for runtime stability, but
medium for security-process efficiency: the old wording can
unnecessarily add the private security team to large-team reports.

Record 8.4: Benefit is moderate for keeping security reporting guidance
current and reducing unnecessary private-list traffic. Risk is very low
because the patch is documentation-only and reviewed.

## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: documentation-only; zero runtime
regression risk; corrects overbroad/obsolete reporting guidance;
reviewed by Leon Romanovsky and Greg Kroah-Hartman; applied by
documentation maintainer Jonathan Corbet; relevant to security reporting
workflow; clean for `7.0.y`.

Evidence against: it does not fix a kernel runtime bug, crash, security
vulnerability, corruption, or deadlock; older stable trees do not
contain the exact rewritten section, so this exact patch is mainly
applicable to `7.0.y`.

Unresolved: I could not run `b4 dig -c` without a commit SHA, and
WebFetch of lore was blocked by Anubis. The `b4` Message-ID fetch
supplied the needed thread content.

Record 9.2: Stable rules: obviously correct and reviewed: yes. Fixes
real user-visible runtime bug: no. Important
crash/security/corruption/deadlock: no. Small and contained: yes, one
documentation file. No new feature/API: yes. Applies to stable: yes for
`7.0.y`; older branches need separate handling.

Record 9.3: Exception category: documentation fix/update. This is the
reason it qualifies despite not being a runtime bug.

Record 9.4: Decision: backport where the affected documentation exists,
especially `7.0.y`. The runtime benefit is nonexistent, but the risk is
also nonexistent, and stable policy exceptions allow documentation fixes
that correct obsolete guidance.

## Verification
- Phase 1: Parsed supplied commit tags and b4 patch headers; confirmed
  no `Fixes:`, `Reported-by:`, `Tested-by`, or `Cc: stable`.
- Phase 2: Read supplied diff and b4 patch; confirmed one documentation
  file, 9 insertions/1 deletion, no code.
- Phase 3: Ran `git blame -L 148,152 -- Documentation/process/security-
  bugs.rst`; old sentence introduced by `a72b832a482372`.
- Phase 3: Ran `git describe --contains a72b832a482372`; first contained
  around `v7.0-rc7~8^2~2`.
- Phase 3: Ran file and author history commands; confirmed recent
  related docs updates by Willy Tarreau.
- Phase 4: Local `git log` searches on current history, `master`, `docs-
  next`, and `all-next` did not find the candidate commit object.
- Phase 4: `b4 am -o /tmp/security-bugs-b4
  20260509094755.2838-2-w@1wt.eu` found a v3 3-patch series, 33
  messages, and reported clean apply to current tree.
- Phase 4: `b4 mbox` saved the thread mbox; `rg` found no stable
  nomination or NAK for this patch.
- Phase 4: WebFetch of lore URLs was blocked by Anubis; not used for the
  final decision.
- Phase 5: `rg` over `Documentation` confirmed the exact mandatory-Cc
  sentence appears in `Documentation/process/security-bugs.rst`.
- Phase 6: `git merge-base --is-ancestor a72b832a482372
  stable/linux-7.0.y` returned true; checks for `5.15.y`, `6.1.y`,
  `6.6.y`, `6.12.y`, `6.18.y`, and `6.19.y` returned false.
- Phase 7: `./scripts/get_maintainer.pl` identified Security Officers
  and Jonathan Corbet for the file; `MAINTAINERS` confirms
  `DOCUMENTATION PROCESS`, `SECURITY CONTACT`, and `STABLE BRANCH`
  entries.
- Phase 8: Failure mode verified from commit text and diff only:
  documentation/process burden, not runtime failure.

**YES**

 Documentation/process/security-bugs.rst | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 27b028e858610..6dc525858125e 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -148,7 +148,15 @@ run additional tests.  Reports where the reporter does not respond promptly
 or cannot effectively discuss their findings may be abandoned if the
 communication does not quickly improve.
 
-The report must be sent to maintainers, with the security team in ``Cc:``.
+The report must be sent to maintainers.  If there are two or fewer
+recipients in your message, you must also always Cc: the Linux kernel
+security team who will ensure the message is delivered to the proper
+people, and will be able to assist small maintainer teams with processes
+they may not be familiar with.  For larger teams, Cc: the Linux kernel
+security team for your first few reports or when seeking specific help,
+such as when resending a message which got no response within a week.
+Once you have become comfortable with the process for a few reports, it is
+no longer necessary to Cc: the security list when sending to large teams.
 The Linux kernel security team can be contacted by email at
 <security@kernel.org>.  This is a private list of security officers
 who will help verify the bug report and assist developers working on a fix.
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] io_uring/fdinfo: translate SqThread PID through caller's pid_ns

[Sasha Levin]

From: Maoyi Xie <maoyixie.tju@gmail.com>

[ Upstream commit 3799c2570982577551023ae035f5a786cf39a76e ]

SQPOLL stores current->pid (init_pid_ns view) in sqd->task_pid
at thread creation. fdinfo prints it raw via
seq_printf("SqThread:\t%d\n", sq_pid). A reader inside a
non-initial pid_ns sees the host PID, not the kthread's PID in
the reader's own pid_ns.

The SQPOLL kthread is created with CLONE_THREAD and no
CLONE_NEW*, so it lives in the submitter's pid_ns. An
unprivileged user_ns + pid_ns submitter can read fdinfo and
learn the host PID of a kthread whose in-namespace PID is
different.

Reproducer (mainline 7.0, KASAN): unshare CLONE_NEWUSER |
CLONE_NEWPID | CLONE_NEWNS, mount a private /proc, then have a
grandchild that is pid 1 in the new pid_ns open an io_uring
ring with IORING_SETUP_SQPOLL. /proc/self/task lists {1, 2};
the SQPOLL kthread is pid 2. Before: fdinfo prints
SqThread = <host pid>. After: SqThread = 2.

Use task_pid_nr_ns() against the proc inode's pid_ns to compute
sq_pid, instead of reading the stored sq->task_pid (which holds
the init_pid_ns view). pidfd_show_fdinfo() in kernel/pid.c
follows the same pattern.

Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260510084119.457578-1-maoyi.xie@ntu.edu.sg
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
Phase 1, commit message forensics:
- Record 1.1: subsystem `io_uring/fdinfo`; action verb `translate`;
  intent is to report `SqThread` in the proc fdinfo reader’s PID
  namespace.
- Record 1.2: tags are `Signed-off-by: Maoyi Xie
  <maoyi.xie@ntu.edu.sg>`, `Link: https://patch.msgid.link/2026051008411
  9.457578-1-maoyi.xie@ntu.edu.sg`, and `Signed-off-by: Jens Axboe
  <axboe@kernel.dk>`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
  `Reviewed-by:`, `Acked-by:`, or `Cc: stable`.
- Record 1.3: the bug is a namespace information leak: `SqThread`
  reports the init-namespace/host PID to a reader inside a non-initial
  PID namespace. The message includes a concrete reproducer using
  unprivileged user/pid/mount namespaces and an SQPOLL ring.
- Record 1.4: this is not hidden cleanup; it is an explicit namespace
  correctness and information disclosure fix.

Phase 2, diff analysis:
- Record 2.1: one file, `io_uring/fdinfo.c`, with 2 insertions and 1
  deletion in `__io_uring_show_fdinfo()`. Scope is a single-function
  surgical fix.
- Record 2.2: before, fdinfo used stored `sq->task_pid`; after, it
  computes `sq_pid = task_pid_nr_ns(tsk,
  proc_pid_ns(file_inode(m->file)->i_sb))`.
- Record 2.3: bug category is logic/security namespace translation. The
  broken value was a raw task PID; the fix translates the live SQPOLL
  task into the proc fdinfo file’s PID namespace.
- Record 2.4: fix quality is high: minimal, uses existing helpers, keeps
  the existing task lifetime protection, and follows the verified
  `pidfd_show_fdinfo()` pattern. Regression risk is very low; host/init
  namespace output remains equivalent.

Phase 3, git history:
- Record 3.1: blame shows the current `sq_pid = sq->task_pid` line last
  touched by `606559dc4fa36a`, while the semantic change to store/print
  `sq->task_pid` came from `a0d45c3f596be`, first contained around
  `v6.7-rc2`.
- Record 3.2: no `Fixes:` tag is present, so there was no tagged
  introducing commit to follow.
- Record 3.3: recent `io_uring/fdinfo.c` history includes multiple
  fdinfo correctness fixes, including SQPOLL lifetime/UAF fixes and SQE
  display fixes. No prerequisite series was found for this patch.
- Record 3.4: local history shows no other `Maoyi Xie` commits under
  `io_uring`; `Jens Axboe` is the listed `IO_URING` maintainer and
  committed/applied the patch.
- Record 3.5: dependencies `task_pid_nr_ns()` and `proc_pid_ns()` exist
  in relevant stable branches checked. The patch applies cleanly to
  `p-6.12`, `p-6.18`, `p-6.19`, and `p-7.0`.

Phase 4, mailing list research:
- Record 4.1: `b4 dig -c 3799c2570982577551023ae035f5a786cf39a76e` found
  the lore thread at the supplied patch.msgid link. `b4 dig -a` found
  only v1.
- Record 4.2: original recipients included Jens Axboe, Pavel Begunkov,
  `io-uring@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.
- Record 4.3: no separate bug-report link or reporter tag was present;
  the bug evidence is the commit’s reproducer.
- Record 4.4: no multi-patch series or related required patches were
  found by b4.
- Record 4.5: no stable-specific discussion was verified. WebFetch hit
  Anubis protection; web search did not produce usable stable discussion
  for this exact patch.

Phase 5, semantic analysis:
- Record 5.1: modified function is `__io_uring_show_fdinfo()`.
- Record 5.2: caller chain is `/proc/*/fdinfo` read in `fs/proc/fd.c` ->
  `file->f_op->show_fdinfo()` -> `io_uring_show_fdinfo()` ->
  `__io_uring_show_fdinfo()`.
- Record 5.3: relevant callees are `rcu_dereference()`,
  `get_task_struct()`, `io_sq_cpu_usec()`, `task_pid_nr_ns()`,
  `proc_pid_ns()`, and `seq_printf()`.
- Record 5.4: reachable from userspace by creating an
  `IORING_SETUP_SQPOLL` ring and reading `/proc/self/fdinfo/<fd>`.
  Current code has global `io_uring_allowed()` gating, but no SQPOLL-
  specific capability check was found in the flag validation path.
- Record 5.5: similar verified pattern exists in `pidfd_show_fdinfo()`,
  which derives the namespace from `file_inode(m->file)->i_sb`.

Phase 6, stable tree analysis:
- Record 6.1: `p-6.12`, `p-6.18`, `p-6.19`, and `p-7.0` contain the
  exact `sq->task_pid` fdinfo pattern. `p-6.6` also contains
  `sq->task_pid`; `p-6.1` uses `task_pid_nr(sq->thread)`, which also
  returns `tsk->pid` in the checked header. `p-5.10` and `p-5.15` did
  not show `SqThread` fdinfo matches in checked paths.
- Record 6.2: exact patch applies cleanly to `p-6.12+` branches checked.
  Older `p-6.1`/`p-6.6` need backport adjustment due code shape
  differences.
- Record 6.3: no existing stable fix for this specific namespace
  translation was found in checked stable branch code.

Phase 7, subsystem context:
- Record 7.1: subsystem is `io_uring`, an important syscall-facing
  kernel I/O subsystem; affected surface is SQPOLL fdinfo, not the core
  I/O data path.
- Record 7.2: file history shows active fdinfo development and recent
  fixes. Maintainer metadata verifies Jens Axboe as `IO_URING`
  maintainer.

Phase 8, impact and risk:
- Record 8.1: affected users are container/pid-namespace users who
  create SQPOLL io_uring rings and read proc fdinfo.
- Record 8.2: trigger is straightforward where io_uring is allowed:
  create SQPOLL in non-init pid namespace and read fdinfo. It is not
  timing-dependent.
- Record 8.3: failure mode is host PID information disclosure and pid
  namespace isolation violation. Severity is medium
  security/correctness, not crash/corruption.
- Record 8.4: benefit is meaningful for namespace isolation; risk is
  very low due a 3-line localized proc-output fix.

Phase 9, synthesis:
- Record 9.1: evidence for backporting: real reproducer, unprivileged
  namespace information leak, tiny fix, maintainer-applied, uses
  established proc namespace helper pattern, clean applies to multiple
  stable branches. Evidence against: no crash/data corruption; older
  stable branches need adapted backports.
- Record 9.2: stable rules: obviously correct yes; fixes real user-
  visible bug yes; important enough as security/isolation info leak yes;
  small and contained yes; no new feature/API yes; applies cleanly to
  checked `p-6.12+`, with older-tree rework as noted.
- Record 9.3: no automatic exception category applies.
- Record 9.4: decision is to backport.

## Verification
- Phase 1: `git show --format=fuller --patch
  3799c2570982577551023ae035f5a786cf39a76e` verified the commit message,
  trailers, and 3-line diff.
- Phase 2: local `io_uring/fdinfo.c` read verified the pre-patch
  `sq->task_pid` fdinfo output and task reference context.
- Phase 3: `git blame`, `git show a0d45c3f596be`, `git describe
  --contains`, and file logs verified history and first-release context.
- Phase 4: `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and `b4 mbox` verified
  the lore thread, v1-only submission, recipients, and Jens “Applied,
  thanks” reply with commit `3799c257...`.
- Phase 5: reads of `fs/proc/fd.c`, `io_uring/io_uring.c`,
  `io_uring/sqpoll.c`, `kernel/fork.c`, `include/linux/pid.h`,
  `kernel/pid.c`, and `fs/pidfs.c` verified reachability, helper
  semantics, SQPOLL creation flags, and the pidfd fdinfo pattern.
- Phase 6: checked `p-6.1`, `p-6.6`, `p-6.12`, `p-6.18`, `p-6.19`,
  `p-7.0`, and `stable/linux-7.0.y` code; worktree `git apply --check`
  verified clean application to `p-6.12`, `p-6.18`, `p-6.19`, and
  `p-7.0`.
- Unverified: no kernel build or runtime reproducer was run; stable-list
  discussion could not be verified because direct lore WebFetch was
  blocked and search found no usable exact stable thread.

This is stable material: it fixes a concrete namespace information leak
with a tiny, conventional, low-risk change.

**YES**

 io_uring/fdinfo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/io_uring/fdinfo.c b/io_uring/fdinfo.c
index c2d3e45544bb4..001fb542dc11a 100644
--- a/io_uring/fdinfo.c
+++ b/io_uring/fdinfo.c
@@ -190,8 +190,9 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m)
 			get_task_struct(tsk);
 			rcu_read_unlock();
 			usec = io_sq_cpu_usec(tsk);
+			sq_pid = task_pid_nr_ns(tsk,
+						proc_pid_ns(file_inode(m->file)->i_sb));
 			put_task_struct(tsk);
-			sq_pid = sq->task_pid;
 			sq_cpu = sq->sq_cpu;
 			sq_total_time = usec;
 			sq_work_time = sq->work_time;
-- 
2.53.0

Re: [PATCH AUTOSEL 7.0] io_uring/wait: honour caller's time namespace for IORING_ENTER_ABS_TIMER

[Jens Axboe]

On 5/20/26 5:18 AM, Sasha Levin wrote:
> From: Maoyi Xie <maoyixie.tju@gmail.com>
> 
> [ Upstream commit 45d2b37a37ab98484693533496395c610a2cab96 ]
> 
> io_uring_enter() with IORING_ENTER_ABS_TIMER takes an absolute
> timespec from the caller via ext_arg->ts. It arms an ABS mode
> hrtimer in __io_cqring_wait_schedule(). The conversion path in
> io_uring/wait.c parses ext_arg->ts inline rather than going
> through io_parse_user_time(). It therefore does not pick up the
> time namespace conversion added by the previous patch.

Once again - If you auto-pick this one, please also do the other one in
the series, 9cc6bac1bebf8310d2950d1411a91479e86d69a1. Makes no sense to
do just one of them.

-- 
Jens Axboe

Re: [PATCH AUTOSEL 7.0] Documentation: security-bugs: do not systematically Cc the security team

[Jonathan Corbet]

Sasha Levin <sashal@kernel.org> writes:

> From: Willy Tarreau <w@1wt.eu>
>
> [ Upstream commit aed3c3346765e4317bb2ec6ff872e1c952e128ab ]
>
> With the increase of automated reports, the security team is dealing
> with way more messages than really needed. The reporting process works
> well with most teams so there is no need to systematically involve the
> security team in reports.

You'll want, at a minimum, f2e65e4e5b4b4b9ecf43f03c3fdbe8c9a8a43a9e to
go with this, or you'll add a broken reference with this commit.

Thanks,

jon

Re: [PATCH AUTOSEL 7.0-5.10] wifi: libertas: fix integer underflow in process_cmdrequest()

[James Cameron]

Interesting.  OLPC XO-1 historical context; our occasional unexplained
corruptions might have been caused by short messages from the wireless
device firmware over USB.

On Wed, May 20, 2026 at 07:18:56AM -0400, Sasha Levin wrote:
> From: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>
> 
> [ Upstream commit 3994b4afd521d60e47e012fe2ed7b606aaec370b ]
> 
> The existing validation only checks if recvlength exceeds
> LBS_CMD_BUFFER_SIZE, but doesn't check the lower bound. When a
> USB device sends a response shorter than MESSAGE_HEADER_LEN, the
> subtraction (recvlength - MESSAGE_HEADER_LEN) wraps to a huge
> value, causing memcpy to corrupt the heap.
> Add the same lower bound check that libertas_tf already has.
> 
> Signed-off-by: Amir Mohammad Jahangirzad <a.jahangirzad@gmail.com>
> Link: https://patch.msgid.link/20260418004247.368944-1-a.jahangirzad@gmail.com
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> 
> LLM Generated explanations, may be completely bogus:
> 
> ## Phase Walkthrough
> ### Phase 1: Commit Message Forensics
> Step 1.1 Record: Subsystem is `wifi: libertas`; action verb is `fix`;
> claimed intent is to prevent integer underflow in
> `process_cmdrequest()`.
> 
> Step 1.2 Record: Tags present are `Signed-off-by: Amir Mohammad
> Jahangirzad`, `Link: https://patch.msgid.link/20260418004247.368944-1-
> a.jahangirzad@gmail.com`, and `Signed-off-by: Johannes Berg`. No
> `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by`, or
> `Cc: stable` tag was present in the supplied commit message or original
> posted patch.
> 
> Step 1.3 Record: The commit body describes a concrete memory corruption
> bug: `recvlength` is only checked against the upper bound, then
> `recvlength - MESSAGE_HEADER_LEN` is stored in `priv->resp_len[i]` and
> used as the `memcpy()` length. If a USB device supplies fewer than 4
> bytes, the subtraction becomes negative and is converted to a huge
> unsigned copy length. Symptom/failure mode: heap/driver memory
> corruption from `memcpy()`. Version information: none in the message.
> Root cause: missing lower-bound validation.
> 
> Step 1.4 Record: This is not hidden; it is explicitly a memory-safety
> fix. It matches the same already-present guard in `libertas_tf`.
> 
> ### Phase 2: Diff Analysis
> Step 2.1 Record: One file changed:
> `drivers/net/wireless/marvell/libertas/if_usb.c`, 3 insertions and 2
> deletions. Modified function: `process_cmdrequest()`. Scope: single-file
> surgical fix.
> 
> Step 2.2 Record: Before, `process_cmdrequest()` rejected only
> `recvlength > LBS_CMD_BUFFER_SIZE`; lengths `1..3` passed and produced
> `recvlength - MESSAGE_HEADER_LEN`. After, it rejects `recvlength <
> MESSAGE_HEADER_LEN` as well as overlarge responses. This affects the USB
> command-response receive path.
> 
> Step 2.3 Record: Bug category is memory safety, specifically integer
> underflow leading to oversized `memcpy()`. Verified details:
> `MESSAGE_HEADER_LEN` is 4, `resp_len` is `u32`, `resp_buf` is `u8
> resp_buf[2][LBS_UPLD_SIZE]`, and `LBS_UPLD_SIZE` is 2312. A negative
> subtraction assigned to `u32` becomes a huge length, far beyond the
> destination buffer.
> 
> Step 2.4 Record: Fix quality is high: minimal bounds check, no API
> change, no new behavior except rejecting malformed command responses.
> Regression risk is very low; valid command responses must already
> include the 4-byte command type/header.
> 
> ### Phase 3: Git History Investigation
> Step 3.1 Record: `git blame` shows the upper-bound check came from
> `ddac452680a516` in the v2.6.25-rc1 era, and the `resp_len = recvlength
> - MESSAGE_HEADER_LEN` plus `memcpy()` flow came from `7919b89c8276` in
> the v2.6.26-rc1 era. This code is old and widely present.
> 
> Step 3.2 Record: No `Fixes:` tag is present in the candidate, so there
> is no specific tagged introducing commit to follow. Blame nevertheless
> identifies the relevant old code.
> 
> Step 3.3 Record: Recent file history includes unrelated cleanup/fix
> commits such as `3968e81ba644` changing skb free placement and
> `d66676e6ca96` fixing a warning in `usb_tx_block()`. I found no
> prerequisite commit needed for this bounds check.
> 
> Step 3.4 Record: `git log --author='Amir Mohammad Jahangirzad'` found no
> prior local commits in this Marvell wireless subtree. The final signoff
> is from Johannes Berg; `MAINTAINERS` lists Johannes Berg as wireless
> maintainer, while the Libertas driver itself is marked orphaned under
> `linux-wireless` and `libertas-dev`.
> 
> Step 3.5 Record: Dependencies found: none. The patch uses existing local
> constants and mirrors the already-existing `libertas_tf` check.
> 
> ### Phase 4: Mailing List And External Research
> Step 4.1 Record: No commit hash was available in local history, so `b4
> dig -c` could not be used successfully; `b4 dig -c
> 20260418004247.368944-1-a.jahangirzad@gmail.com` failed because it
> expects a commit. Fallback `b4 mbox` and the lore mirror found the
> original patch at `https://yhbt.net/lore/lkml/20260418004247.368944-1-
> a.jahangirzad@gmail.com/T/`. The thread has one message and no replies.
> `b4 mbox -c` found no newer revision in the thread.
> 
> Step 4.2 Record: Original recipients included Johannes Berg, Kees Cook,
> Ingo Molnar, Johan Hovold, `linux-wireless`, `libertas-dev`, and `linux-
> kernel`. No reviewer replies, NAKs, or explicit stable nominations were
> present in the fetched thread.
> 
> Step 4.3 Record: No `Reported-by` or bug-report link was present. I
> found no separate public bug report for this exact issue. The message
> itself provides the failure mechanism.
> 
> Step 4.4 Record: Related precedent exists: commit `3348ef6a6a126` fixed
> the identical underflow in `libertas_tf: process_cmdrequest()`, with
> message “If recvlength is less than MESSAGE_HEADER_LEN (4) we would end
> up corrupting memory.” That analogous fix was later carried in stable
> review postings for 4.19 and 3.16.
> 
> Step 4.5 Record: Web searches found the exact candidate posting and
> stable history for the analogous `libertas_tf` fix, but no exact stable
> discussion for this new `libertas` patch.
> 
> ### Phase 5: Code Semantic Analysis
> Step 5.1 Record: Modified function: `process_cmdrequest()`.
> 
> Step 5.2 Record: Caller is `if_usb_receive()`, reached as the receive
> URB completion callback installed by `usb_fill_bulk_urb()` through
> `if_usb_submit_rx_urb()`.
> 
> Step 5.3 Record: Key callees are `memcpy()`, `dev_kfree_skb_irq()`, and
> `lbs_notify_command_response()`. The command response is later consumed
> by the main thread through `lbs_process_command_response()`.
> 
> Step 5.4 Record: Reachability is verified through USB receive
> completion: a Libertas USB device response with type `CMD_TYPE_REQUEST`
> reaches `process_cmdrequest()`. The triggering input is device-
> controlled USB receive data, so this is reachable with affected hardware
> or a malicious/faulty USB device.
> 
> Step 5.5 Record: Similar pattern found in `libertas_tf`; that sibling
> driver already has the exact lower-bound check. `if_sdio` and `if_spi`
> use different response formats and do not subtract `MESSAGE_HEADER_LEN`
> in the same way.
> 
> ### Phase 6: Cross-Referencing And Stable Tree Analysis
> Step 6.1 Record: Representative tags `v3.16`, `v4.14`, `v4.19`, `v5.4`,
> `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, and newer `v6.13` through
> `v6.17` all contain the buggy `process_cmdrequest()` pattern without the
> lower-bound check. The bug dates back to at least the v2.6.26-rc1 era.
> 
> Step 6.2 Record: Expected backport difficulty is low for modern stable
> trees: the same context is present in representative stable tags, and
> `git apply --check` succeeds against the current tree. Very old trees
> before the Marvell directory move may need path/context adjustment, as
> verified by older tags using `drivers/net/wireless/libertas/if_usb.c`.
> 
> Step 6.3 Record: No exact related fix for `libertas` was found in local
> history. The sibling `libertas_tf` fix exists and was stable-backported.
> 
> ### Phase 7: Subsystem And Maintainer Context
> Step 7.1 Record: Subsystem is wireless driver code under
> `drivers/net/wireless/marvell/libertas`. Criticality: driver-specific,
> but memory corruption in a kernel USB receive path is high severity for
> affected systems.
> 
> Step 7.2 Record: Subsystem activity is low-to-moderate; recent history
> shows occasional fixes and cleanups. `MAINTAINERS` marks Marvell
> Libertas as orphaned, with `linux-wireless` and `libertas-dev` lists.
> 
> ### Phase 8: Impact And Risk Assessment
> Step 8.1 Record: Affected population is config- and hardware-specific:
> systems with `CONFIG_LIBERTAS_USB` and Marvell Libertas 8388 USB
> devices, or systems exposed to a malicious USB device matching the
> driver IDs.
> 
> Step 8.2 Record: Trigger condition is a USB command response shorter
> than `MESSAGE_HEADER_LEN` but with `CMD_TYPE_REQUEST` dispatch. This is
> device-controlled. I did not verify an unprivileged software-only
> trigger; physical or device-level control is the verified trigger model.
> 
> Step 8.3 Record: Failure mode is heap/driver memory corruption from
> oversized `memcpy()`. Severity: HIGH to CRITICAL, because kernel memory
> corruption can crash the system and can have security implications.
> 
> Step 8.4 Record: Benefit is high for affected systems: prevents kernel
> memory corruption from malformed USB responses. Risk is very low: 3-line
> effective validation change in one driver function, with precedent in
> sibling driver.
> 
> ### Phase 9: Final Synthesis
> Step 9.1 Record: Evidence for backporting: real memory corruption bug;
> old code present across many stable release tags; tiny surgical fix; no
> new API or feature; exact validation already used by `libertas_tf`;
> analogous `libertas_tf` fix was stable-backported. Evidence against:
> driver-specific and no external bug report or tested-by tag. Unresolved:
> exact final upstream commit hash was not present in local history, so
> `b4 dig -c <commit_hash>` could not be completed.
> 
> Step 9.2 Record:
> 1. Obviously correct and tested? Obviously correct by code inspection;
>    no explicit `Tested-by`.
> 2. Fixes a real bug? Yes, verified underflow into oversized `memcpy()`.
> 3. Important issue? Yes, kernel memory corruption.
> 4. Small and contained? Yes, one function in one file.
> 5. No new features/APIs? Yes.
> 6. Can apply to stable trees? Yes for modern representative tags with
>    likely clean/minor context; old pre-directory-move trees may need
>    path adjustment.
> 
> Step 9.3 Record: No exception category such as device ID, quirk, DT,
> build, or docs applies. This is a direct memory-safety bug fix.
> 
> Step 9.4 Record: Stable backport decision is YES. The fix prevents
> kernel memory corruption in an old, stable-present USB driver path with
> extremely low regression risk.
> 
> ## Verification
> - Phase 1: Parsed supplied tags and fetched original patch thread with
>   `b4 mbox`; confirmed no `Fixes`, `Reported-by`, `Tested-by`,
>   `Reviewed-by`, `Acked-by`, or stable tag.
> - Phase 2: Read `drivers/net/wireless/marvell/libertas/if_usb.c`,
>   `dev.h`, and `defs.h`; confirmed `MESSAGE_HEADER_LEN`, `resp_len`,
>   `resp_buf`, and `memcpy()` behavior.
> - Phase 3: Ran `git blame` on `process_cmdrequest()`; identified old
>   introducing history around `ddac452680a516` and `7919b89c8276`.
> - Phase 3: Ran `git describe --contains`; confirmed relevant code dates
>   to v2.6.25/v2.6.26-era history.
> - Phase 4: `b4 dig` with the message-id failed because no local commit
>   hash was available; recorded as unresolved.
> - Phase 4: `b4 mbox` fetched the patch thread; `b4 mbox -c` found one
>   message and no newer revision.
> - Phase 4: Fetched lore mirror and stable archive pages; confirmed
>   analogous `libertas_tf` fix and stable review postings.
> - Phase 5: Traced callers from `if_usb_receive()` through
>   `usb_fill_bulk_urb()` and `if_usb_submit_rx_urb()`.
> - Phase 6: Checked release tags from `v3.16` through representative
>   active v6 tags; confirmed the buggy code exists broadly.
> - Phase 6: Ran `git apply --check` against the current tree; patch
>   applies cleanly there.
> - Phase 7: Checked `MAINTAINERS`; confirmed Libertas is orphaned under
>   wireless lists and Johannes Berg is listed for wireless maintenance.
> - Phase 8: Verified trigger is USB device-controlled receive data; no
>   unprivileged software-only trigger was verified.
> 
> **YES**
> 
>  drivers/net/wireless/marvell/libertas/if_usb.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
> index 8a6bf1365cfab..42d3fd32ece28 100644
> --- a/drivers/net/wireless/marvell/libertas/if_usb.c
> +++ b/drivers/net/wireless/marvell/libertas/if_usb.c
> @@ -625,9 +625,10 @@ static inline void process_cmdrequest(int recvlength, uint8_t *recvbuff,
>  	unsigned long flags;
>  	u8 i;
>  
> -	if (recvlength > LBS_CMD_BUFFER_SIZE) {
> +	if (recvlength < MESSAGE_HEADER_LEN ||
> +	    recvlength > LBS_CMD_BUFFER_SIZE) {
>  		lbs_deb_usbd(&cardp->udev->dev,
> -			     "The receive buffer is too large\n");
> +			     "The receive buffer is invalid: %d\n", recvlength);
>  		kfree_skb(skb);
>  		return;
>  	}
> -- 
> 2.53.0
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev