Merge tag 'powerpc-7.2-4' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fixes from Madhavan Srinivasan:

 - A couple of fixes for a memory leak and a underflow case

Thanks to George Wilson and R Nageswara Sastry

* tag 'powerpc-7.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/pseries: lparcfg - fix kbuf[] underflow
  powerpc/pseries: pci - logic bug
  powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak

powerpc/pseries: lparcfg - fix kbuf[] underflow

In lparcfg_write(), a count of 0 results in kbuf[] being indexed at -1.
Check for count == 0 in the existing check for count > sizeof(kbuf) and
return -EINVAL if true.

Fixes: 74422e2b1939 ("powerpc/pseries: Remove VLA from lparcfg_write()")
Acked-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com>
Cc: stable@vger.kernel.org # 4.20
Signed-off-by: George Wilson <gcwilson@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>

powerpc/pseries: pci - logic bug

The checks on num_vfs in pseries_pci_sriov_enable() are ANDed where OR
was apparently intended.  Change it to OR.

Fixes: 9a7f6b438664 ("powerpc/pseries/pci: Associate PEs to VFs in configure SR-IOV")
Acked-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com>
Cc: stable@vger.kernel.org # 4.16
Signed-off-by: George Wilson <gcwilson@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>

powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak

In papr_phy_attest_create_handle(), the params->cmd.length is not
validated before use, which can result in a buffer overlow.  Check it and
return -EINVAL if it is either 0 or exceeds sizeof(params->cmd).

Also, params is freed on the success path but not error. Free it on
errors after memory allocation.  And free it on negative fd.

Fixes: 86900ab620a4 ("powerpc/pseries: Add a char driver for physical-attestation RTAS")
Acked-by: Haren Myneni <haren@linux.ibm.com>
Acked-by: Nayna Jain <nayna@linux.ibm.com>
Tested-by: R Nageswara Sastry <rnsastry@linux.ibm.com>
Cc: stable@vger.kernel.org # 6.16
Signed-off-by: George Wilson <gcwilson@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>

Merge tag 'watchdog-for-v7.2-rc7' of git://git./linux/kernel/git/groeck/linux-staging

Pull watchdog fixes from Guenter Roeck:

 - at91sam9_wdt: prevent timer rearm during teardown

 - bd96801_wdt: Fix timeout for enabled WDG

 - atcwdt200: Fix return value when watchdog is enabled

* tag 'watchdog-for-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  watchdog: at91sam9_wdt: prevent timer rearm during teardown
  watchdog: bd96801_wdt: Fix timeout for enabled WDG
  watchdog: atcwdt200: fix return value when watchdog is enabled

Merge tag 'hwmon-for-v7.2-rc7' of git://git./linux/kernel/git/groeck/linux-staging

Pull hwmon fixes from Guenter Roeck:
 "Various fixes, most of them fixing critical or high severity bugs
  reported by Sashiko.

  ads7828:
   - Fix external VREF regulator handling

  corsair-psu:
   - Fix linear11 calculation
   - Serialize debugfs access against hwmon
   - Fix possible out-of-bounds access on missing string termination

  ltc4282:
   - Fix parsing adi,current-limit-sense-microvolt
   - Clamp negative current limits
   - Avoid overflow in maximum power calculation

  nzxt-smart2:
   - Check return value of init_device() in probe

  PMBus core:
   - Fix type confusion in notification logic
   - Avoid race condition during probe

  PMBus/lm25066:
   - Fix PMBus coefficient calculations"

* tag 'hwmon-for-v7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (corsair-psu) Fix linear11 calculation
  hwmon: (corsair-psu) serialize debugfs access against hwmon
  hwmon: (ltc4282) Fix parsing adi,current-limit-sense-microvolt
  hwmon: (ltc4282) Clamp negative current limits
  hwmon: (ltc4282) Avoid overflow in maximum power calculation
  hwmon: (ads7828) Fix external VREF regulator handling
  hwmon: (corsair-psu) fix possible out-of-bounds access on missing string termination
  hwmon: (pmbus/lm25066) Fix PMBus coefficient calculations
  hwmon: (nzxt-smart2) Check return value of init_device() in probe
  hwmon: (pmbus) Fix type confusion in notification logic
  hwmon: (pmbus/core) Avoid race condition during probe

Merge tag 'ata-7.2-rc7' of git://git./linux/kernel/git/libata/linux

Pull ata fixes from Damien Le Moal:

 - Disable link power management on yet another misbehaving WD drive
   (Niklas)

 - Fix a use after free issue in the pata_sl82c105 driver (Hongyan)

* tag 'ata-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
  ata: pata_sl82c105: fix bridge revision use-after-free
  ata: libata-core: Disable LPM on WDC WD141KFGX-68FH9N0

Merge tag 'drm-fixes-2026-08-08' of https://gitlab.freedesktop.org/drm/kernel

Pull drm fixes from Dave Airlie:
 "Weekly fixes for drm, feels relatively quiet for the post-AI world,
  mostly amdgpu and xe with a few fixes across the board:

  shmem:
   - check VMA boundaries for PMD mappings

  xe:
   - Fix memory leak in exec_queue_set_hang_replay_state
   - Apply RCS/CCS yield policy to SR-IOV VFs

  amdgpu:
   - JPEG queue reset fixes
   - GC 12 fix
   - GMC 12.1 fixes
   - Lockdep false positive fix
   - Userq fix
   - Bounds checking fixes
   - Devcoredump fixes
   - DCN 2.0.1 fix
   - Aperture mapping fix
   - DC avmute fix
   - DC self refresh fix

  radeon:
   - Performance regression fix

  panthor:
   - skip zero sized firmware segments
   - check VMA boundaries for PMD mappings

  bridge:
   - ps8640: propagate AUX transfer register errors

  amdxdna:
   - Improve error handling in amdxdna_insert_pages.

  v3d:
   - serialise scheduler timeouts"

* tag 'drm-fixes-2026-08-08' of https://gitlab.freedesktop.org/drm/kernel: (26 commits)
  drm/amd/display: allow self-refresh exit while entry is blocked
  drm/amdgpu: fix aperture iounmap skipped on device removal
  drm/amd/display: Check for tg ops in dce110_set_avmute
  Revert "drm/amdgpu: fix aperture mapping leak"
  drm/radeon: restore hardware polling in fence_is_signaled to fix performance regression
  drm/amd: Disable DP audio spread spectrum for Cyan Skillfish
  drm/amdgpu/gmc12.1: fix MMHUB0 check in pasid tlb flush
  drm/amdgpu: Allocate coredump ring buffers per ring
  drm/amdgpu: Use virtual alloc during coredump
  drm/amdgpu: reject oversized IBs with per-ring packet limits
  drm/amdgpu/userq: serialize queue map against GPU reset
  drm/amdgpu: Fix lockdep false positive in amdgpu_lockdep_init
  drm/amdgpu/gmc12.1: implement tlb inv semaphore
  drm/amdgpu: read TRUNCATE_COORD_MODE on gfx12
  drm/amdgpu: fix JPEG v5.3.0 queue reset failure in DPG mode
  drm/amdgpu: fix JPEG v4.0.5 queue reset failure in DPG mode
  drm/amdgpu: fix JPEG v5.0.0 queue reset failure in DPG mode
  drm/panthor: Check VMA boundaries for PMD mappings
  drm/xe/uc: Apply RCS/CCS yield policy to SR-IOV VFs
  drm/xe: Fix memory leak in exec_queue_set_hang_replay_state()
  ...

Merge tag 'pinctrl-v7.2-3' of git://git./linux/kernel/git/linusw/linux-pinctrl

Pull pin control fixes from Linus Walleij:
 "Qualcomm fixes: some incorrectly defined groups in IPQ9650, two pins
  needing to be marked as GPIO in IPQ806X"

* tag 'pinctrl-v7.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
  pinctrl: qcom: ipq806x: mark pci reset as a GPIO pin function
  pinctrl: qcom: ipq806x: mark gpio as a GPIO pin function
  pinctrl: qcom: ipq9650: fix audio_sec_mclk_in1/out1 group pins

Merge tag 'bpf-fixes' of git://git./linux/kernel/git/bpf/bpf

Pull BPF fixes from Daniel Borkmann:

 - Fix BPF verifier to preserve full pointer state for commuted
   scalar += pointer arithmetic (Yiyang Chen, Eduard Zingerman)

 - Fix a use-after-free of request sockets in the BPF TCP iterator
   batching (Jose Fernandez)

 - Fix a use-after-free of sk_redir in the BPF sockmap send verdict
   path (Chengfeng Ye)

 - Fix a netns reference imbalance in the BPF conntrack kfuncs
   (Chengfeng Ye)

 - Fix bpf_get_fsverity_digest() dynptr assumptions and silent
   digest truncation (Eric Biggers)

 - Fix bpf_tcp_{gen,check}_syncookie to check sk_state before
   sk_protocol to make sure it is a full socket (Luxiao Xu)

 - Fix rqspinlock to reset the tail when preserving the queue
   on deadlock (Kumar Kartikeya Dwivedi)

* tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf:
  rqspinlock: Reset tail when preserving queue on deadlock
  bpf: Check sk_state before sk_protocol in bpf_tcp_*_syncookie
  fsverity: Fix silent truncation in bpf_get_fsverity_digest()
  fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions
  bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()
  bpf: Fix netns reference imbalance in conntrack kfuncs
  bpf, sockmap: Fix sk_redir use-after-free in send verdict
  selftests/bpf: Cover commuted pointer state propagation
  bpf: Propagate untrusted pointer state in commuted arithmetic
  bpf: Preserve pointer state for commuted arithmetic
  bpf: Simplify sanitize_err() signature

Merge tag 'for-linus' of git://git./virt/kvm/kvm

Pull vkm fixes from Paolo Bonzini:
 "s390:

   - fix a lot of small bugs and races

  x86:

   - fix missing locking related to KVM_CAP_MOVE_ENC_CONTEXT_FROM

   - warn on creating a new page table that is the child of an invalid
     one, and limit damage before it's too late

   - disable use of INVLPGA when NPT is enabled, because it doesn't seem
     to flush TLBs correctly"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (26 commits)
  KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page
  KVM: SVM: Serialize accesses to the owner and mirror list with separate lock
  KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled
  KVM: s390: Fix cleanup in kvm_s390_pv_create_cpu()
  KVM: s390: Fix ordering when adding to SCA
  KVM: s390: Return -EINTR if a signal is pending while faulting-in
  KVM: s390: Free the mmu cache when kvm_arch_vcpu_create() fails
  KVM: s390: ucontrol: Add missing locking around gmap_remove_child()
  KVM: s390: cmma: Fix dirty tracking when removing memslot
  KVM: s390: Fix race in __do_essa()
  KVM: s390: Fix leaking of PGM_ADDRESSING to userspace
  KVM: s390: ucontrol: Fix sca_clear_ext_call()
  KVM: s390: Fix overclearing ESCA in case of error
  KVM: s390: Fix kvm_s390_vcpu_unsetup_cmma()
  KVM: s390: Do not free SCA if it was not allocated
  KVM: s390: Fix unlikely NULL gmap dereference
  s390/vfio_ccw: Implement a crw lock
  s390/vfio_ccw: Selectively expand io_mutex
  s390/vfio_ccw: Move cp cleanup out of not operational
  s390/vfio_ccw: Cancel existing workqueues
  ...

Merge tag 'thermal-7.2-rc7' of git://git./linux/kernel/git/rafael/linux-pm

Pull thermal control fixes from Rafael Wysocki:
 "Revert three thermal core updates, two recent ones and one older.

  The recent ones attempted to fix a design issue in the thermal core
  and simplify code on top of that, but they made changes visible to
  user space and made it unhappy.

  The older one is a misguided code cleanup that introduced a
  (potentially nasty) bug"

* tag 'thermal-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  Revert "thermal/drivers/hwmon: Cleanup coding style a bit"
  Revert "thermal: hwmon: Register a hwmon device for each thermal zone"
  Revert "thermal: hwmon: Use extra_groups for adding temperature attributes"

Merge tag 'sound-7.2-rc7' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "A collection of small fixes since the last pull request. More than
  few, but an enough-manageable amount at this time.

  USB-audio:
   - UAF, OOB and such hardening fixes for USB-audio, usx2y and
     us144mkii
   - Mixer regression fixes for Logitech PRO X 2 LIGHTSPEED headset and
     M-Audio Fast Track Ultra

  HD-audio:
   - Fix for an ACPI reference leak in TAS2781 HDA side-codec

  ASoC:
   - Fixes the default tables for Cirrus Logic codecs
   - Fixes for invalid enum accesses for Qualcomm LPASS
   - Error handling and robustness fixes for Intel SOF & Soundwire
   - DMI quirks for a few AMD devices"

* tag 'sound-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (22 commits)
  ALSA: usb-audio: Fix sticky mixer regressions on M-Audio Fast Track Ultra
  ASoC: cs4265: sort the register default table
  ASoC: cs35l45: sort the register default table
  ASoC: cs35l41: sort the register default table
  ASoC: amd: yc: Add DMI quirk for MSI Raider A18 HX A7VHG
  ASoC: amd: yc: Add DMI quirk for Xiaomi RedmiBook 16 2025
  ALSA: usx2y: bound the hwdep mmap fault offset
  ALSA: usb-audio: fix OOB write on Type II inbound URBs
  ALSA: us144mkii: re-anchor capture URBs on resubmission
  ALSA: FCP: fix OOB write in fcp_meter_ctl_get()
  MAINTAINERS: add SpacemiT K1/K3 I2S entry
  ASoC: rt5645: Make the Kconfig symbol user selectable
  ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN for Logitech PRO X 2 LIGHTSPEED
  ALSA: hda/tas2781: fix ACPI reference handling
  ASoC: codecs: lpass-wsa-macro: Fix enum kcontrol accesses
  ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses
  ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout
  ASoC: amd: yc: Add DMI quirk for HP Victus Laptop 16-e1xxx
  ASoC/soundwire: Intel: reset the PCMSyCM registers in hda_sdw_bpt_close
  ASoC: SOF: sof-audio: Fix error path in sof_widget_setup_unlocked()
  ...

Merge tag 'amd-drm-fixes-7.2-2026-08-06' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes

amd-drm-fixes-7.2-2026-08-06:

amdgpu:
- JPEG queue reset fixes
- GC 12 fix
- GMC 12.1 fixes
- Lockdep false positive fix
- Userq fix
- Bounds checking fixes
- Devcoredump fixes
- DCN 2.0.1 fix
- Aperture mapping fix
- DC avmute fix
- DC self refresh fix

radeon:
- Performance regression fix

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patch.msgid.link/20260806211538.994087-1-alexander.deucher@amd.com

Merge tag 'drm-misc-fixes-2026-08-06' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes

drm-misc-fixes for v7.2-rc6:
- panthor & shmem helpers: Check vma range inside pmd fault handler.
- panthor: handle empty firmware sections correctly.
- bridge/ps8640: Forward aux transfer errors.
- amdxdna: Improve error handling in amdxdna_insert_pages.

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patch.msgid.link/415659f6-5199-4078-8319-22d7529e777d@linux.intel.com

ALSA: usb-audio: Fix sticky mixer regressions on M-Audio Fast Track Ultra

The recent fix for sticky mixer volumes caused regressions of M-audio
Fast Track Ultra device, where the mixer state is kept to the default
value.

Add the quirk entries to tolerate the broken mixer behavior.  As the
device is known to work in the implicit feedback mode, explicitly
enable the implicit feedback mode, too.

Since there are two FTU models that are almost identical, both entries
are added in this patch (0763:2080 and 0763:2081).

Fixes: 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky mixers")
Link: https://bugzilla.suse.com/show_bug.cgi?id=1273166
Link: https://patch.msgid.link/20260807083418.1712585-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>

KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page

Explicitly clear role.invalid when deriving a child shadow page's role from
its parent to harden against bugs elsewhere in KVM, as violating KVM's
invariant that invalid pages are NOT on the list of active MMU pages leads
to use-after-free due to __kvm_mmu_prepare_zap_page() using list_add()
instead of list_move() when processing an invalid shadow page, i.e. makes a
bad situation far worse.

Yell loudly if the parent is invalid, as it means KVM has missed a validity
check, i.e. KVM is attempting to map memory using an invalid/obsolete root,
but continue on as the child is otherwise still a valid shadow page.

  ==================================================================
  BUG: KASAN: slab-use-after-free in __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm]
  Write of size 8 at addr ff11000153dd1368 by task repro/853

  CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-next-vm #5 PREEMPT
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  Call Trace:
   <TASK>
   dump_stack_lvl+0x4b/0x70
   print_report+0x153/0x49c
   kasan_report+0xbc/0xf0
   __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm]
   mmu_alloc_root+0x141/0x320 [kvm]
   kvm_mmu_load+0x612/0x20f0 [kvm]
   kvm_arch_vcpu_ioctl_run+0x3dd5/0x6150 [kvm]
   kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm]
   __x64_sys_ioctl+0x131/0x1b0
   do_syscall_64+0x67/0x5f0
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
   </TASK>

  Allocated by task 853:
   kasan_save_stack+0x20/0x40
   kasan_save_track+0x14/0x30
   __kasan_slab_alloc+0x5f/0x70
   kmem_cache_alloc_noprof+0xfe/0x2e0
   __kvm_mmu_topup_memory_cache+0x135/0x530 [kvm]
   paging64_page_fault+0x318/0x1e30 [kvm]
   kvm_mmu_do_page_fault+0x21d/0x630 [kvm]
   kvm_mmu_page_fault+0x18c/0x17b0 [kvm]
   kvm_arch_vcpu_ioctl_run+0x1f35/0x6150 [kvm]
   kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm]
   __x64_sys_ioctl+0x131/0x1b0
   do_syscall_64+0x67/0x5f0
   entry_SYSCALL_64_after_hwframe+0x4b/0x53

  Freed by task 853:
   kasan_save_stack+0x20/0x40
   kasan_save_track+0x14/0x30
   kasan_save_free_info+0x3b/0x60
   __kasan_slab_free+0x43/0x70
   kmem_cache_free+0xe2/0x400
   kvm_mmu_commit_zap_page.part.0+0x1e2/0x310 [kvm]
   kvm_mmu_free_roots+0x283/0x560 [kvm]
   kvm_arch_vcpu_ioctl_run+0x33c8/0x6150 [kvm]
   kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm]
   __x64_sys_ioctl+0x131/0x1b0
   do_syscall_64+0x67/0x5f0
   entry_SYSCALL_64_after_hwframe+0x4b/0x53

Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Fixes: a770f6f28b1a ("KVM: MMU: Inherit a shadow page's guest level count from vcpu setup")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

hwmon: (corsair-psu) Fix linear11 calculation

In corsairpsu_linear11_to_int(), the mantissa is extracted using bitwise
operations and cast to s16 before being shifted left:

static int corsairpsu_linear11_to_int(const u16 val, const int scale)
{
    ...
    const int mant = (((s16)(val & 0x7ff)) << 5) >> 5;
    ...
}

Due to C integer promotion rules, the masked value (which is always
positive) is promoted to a 32-bit integer before the left shift. As a
result, the sign bit is never extended to bit 31 of the promoted integer.

When the device hardware reports a negative temperature in Linear11 format
(such as an ambient temperature probe reporting sub-zero), the negative
mantissa is parsed incorrectly as a massive positive value. For example,
-1 becomes 2047, which scales to 2047 degrees Celsius.

Fix the problem by type casting the result of the left shift operation
to s16.

Another problem is left-shifting of negative values. In C, the result of
left-shifting negative values is undefined. Use a multiplication instead
to avoid the problem.

Also use a local s64 variable to store temporary results, change
the return value type from int to long, and clamp the final value
to LONG_MIN and LONG_MAX to avoid under- and overflow issues while
retaining as much information as possible.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Cc: Wilken Gottwalt <wilken.gottwalt@posteo.net>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Wilken Gottwalt <wilken.gottwalt@posteo.net>
Link: https://lore.kernel.org/r/20260804034811.2385506-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

hwmon: (corsair-psu) serialize debugfs access against hwmon

corsairpsu_request() sends a rail select command and then the actual
read as two separate transfers, both going through the single shared
cmd_buffer and wait_completion in corsairpsu_usb_cmd(). The hwmon core
serializes its own callers, but the debugfs files call
corsairpsu_get_value() directly and never take that lock, so a debugfs
read can land between another reader's rail select and its value read.

The result is a value from the wrong rail reported as the right one,
because corsairpsu_usb_cmd() only checks the command echo and both
transfers echo the command it expects. It can also make a caller consume
the reply meant for the other one, since raw_event() writes into the
shared buffer and completes whoever happens to be waiting.

Locking was dropped in commit 4207069edbf0 ("hwmon: (corsair-psu) Rely
on subsystem locking") on the grounds that the subsystem serializes for
us, which holds for sysfs but not for these files. Take
the same lock in the debugfs paths that issue commands, using the guard
added in commit d1e720c7328e ("hwmon: Support guard() and scoped_guard
for subsystem locks").

The lock cannot go into corsairpsu_request() itself: the hwmon core
already holds it across ->read, so every sysfs read would deadlock.
vendor_show() and product_show() only print strings cached during probe
and issue no command, and corsairpsu_get_criticals() and
corsairpsu_check_cmd_support() run before either interface is
registered, so none of them need it.

Fixes: 4207069edbf0 ("hwmon: (corsair-psu) Rely on subsystem locking")
Signed-off-by: Ali Ahmet Memis <ali@iusegentoo.com>
Tested-by: Wilken Gottwalt <wilken.gottwalt@posteo.net>
Link: https://lore.kernel.org/r/20260806142139.168611-1-ali@iusegentoo.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

hwmon: (ltc4282) Fix parsing adi,current-limit-sense-microvolt

ltc4282_parse_dt() evaluates the wrong variable when parsing the current
limit.

When the adi,current-limit-sense-microvolt property is parsed into
st->vsense_max, the subsequent switch statement evaluates the unrelated
val variable instead of st->vsense_max:

drivers/hwmon/ltc4282.c:ltc4282_parse_dt() {
    ...
        ret = device_property_read_u32(dev, "adi,current-limit-sense-microvolt",
                                       &st->vsense_max);
        if (!ret) {
                int reg_val;

                switch (val) {
                case 12500:
                        reg_val = 0;
                        break;
    ...
}

Because val holds a small integer representing vin_mode (from 0 to 3), it
never matches any of the valid current limit cases.

This causes it to always fall through to the default error case, return
-EINVAL, and aborts probe initialization for any device tree using this
property.

Validate st->vsense_max instead to fix the problem.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: cbc29538dbf7d ("hwmon: Add driver for LTC4282")
Cc: Nuno Sa <nuno.sa@analog.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

hwmon: (ltc4282) Clamp negative current limits

When a negative value is passed to ltc4282_write_curr(), the signed long
val is cast directly to u64:

drivers/hwmon/ltc4282.c:ltc4282_write_curr() {
        /* need to pass it in millivolt */
        u32 in = DIV_ROUND_CLOSEST_ULL((u64)val * st->rsense, DECA * MICRO);
        ...
}

This cast converts negative inputs into large positive values. The
subsequent division result overflows the u32 in variable, truncating
to a pseudo-random positive value. When this is passed to
ltc4282_write_voltage_byte(), it is clamped to the maximum limit instead
of zero.

Clamp val to 0 and to the maximum supported upper limit before the cast
and assign the result to a 64-bit temporary variable before the division
to avoid the underflow and an also possible overflow.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: cbc29538dbf7d ("hwmon: Add driver for LTC4282")
Cc: Nuno Sa <nuno.sa@analog.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

hwmon: (ltc4282) Avoid overflow in maximum power calculation

During device initialization in ltc4282_set_max_limits(), the calculation
of the maximum power limit can suffer from a 32-bit integer overflow.

static int ltc4282_set_max_limits(struct ltc4282_state *st)
{
    ...
    st->power_max = DIV_ROUND_CLOSEST(st->vsense_max * DECA * MILLI,
                                      st->rsense) * st->vfs_out;
    ...
}

The result of DIV_ROUND_CLOSEST() evaluates to a 32-bit unsigned integer
on 32-bit architectures. This result is then multiplied by st->vfs_out,
which is a 16-bit unsigned integer. According to C promotion rules, since
both operands are 32-bit or smaller, the multiplication is performed in
32-bit precision.

If the device is configured with a low sense resistor value via the device
tree (for example, 100 nano-ohms, resulting in st->rsense = 1) and the
voltage is high, the division result can reach 343,750,000 and st->vfs_out
can be 33,280. The product of these values is approximately 11.44 trillion,
which exceeds the maximum capacity of a 32-bit integer and overflows
before being stored in st->power_max.

This overflow causes a truncated value to be assigned to st->power_max and
written to the hardware limit register. An incorrect maximum power limit
can trigger spurious power-bad faults or alarms, which may lead to the
shutdown of the monitored power rail.

Avoid the problem by calculating and storing the maximum power using 64-bit
variables.

Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: cbc29538dbf7d ("hwmon: Add driver for LTC4282")
Cc: Nuno Sa <nuno.sa@analog.com>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

hwmon: (ads7828) Fix external VREF regulator handling

The driver currently has two issues with the external VREF regulator
handling in ads7828_probe():

1. All errors from devm_regulator_get_optional() are ignored, causing the
   driver to incorrectly fall back to internal VREF even for transient
   errors like -EPROBE_DEFER or genuine failures like -ENOMEM.

2. The external regulator is never enabled. The driver calls
   regulator_get_voltage() without first calling regulator_enable(),
   so the VREF pin may remain unpowered if the regulator is not
   configured as always-on.

Fix both issues by switching to devm_regulator_get_enable_read_voltage(),
which handles regulator get, enable, and voltage read in one call.
Only -ENODEV (no regulator specified in device tree) should trigger the
fallback to internal VREF. All other errors are propagated to the caller.

Fixes: a8ddfea09566 ("hwmon: (ads7828) Accept optional parameters from device tree")
Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn>
Link: https://lore.kernel.org/r/20260805061645.1331652-1-fffsqian@163.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

hwmon: (corsair-psu) fix possible out-of-bounds access on missing string termination

In theory it could be possible that the REPLY_SIZE sized buffers for
holding the vendor and product strings could be end up missing the null
termination (for example by malicious hardware built on purpose)
required by the seq_printf() call. That limits the debugfs printf calls
to a maximum string length of REPLY_SIZE.

Fixes: d115b51e0e567 ("hwmon: add Corsair PSU HID controller driver")
Signed-off-by: Wilken Gottwalt <wilken.gottwalt@posteo.net>
Link: https://lore.kernel.org/r/anLj9gPWRoRDbQBV@monster.localdomain
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Merge tag 'mm-hotfixes-stable-2026-08-06-18-44' of git://git./linux/kernel/git/akpm/mm

Pull MM fixes from Andrew Morton:
 "17 hotfixes.  15 are cc:stable.  16 are for MM.

  There's a patch series from Lorenzo "mm: fix UAF caused by race
  between ptdump and vmap pgtable freeing" which addresses a quite old
  bug in the ptdump code.

  And another series also from Lorenzo which fixes a four year old bug
  in the huge_zero_folio handling.

  A series from SJ fixes a few possible divide-by-zero issues which
  Sashiko sniffed out. And a series which fixes handling of the
  commit_inputs parameters.

  The remainder are singletons, please see their changelogs for details"

* tag 'mm-hotfixes-stable-2026-08-06-18-44' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm:
  mm/damon: adjust isolated pages stat for DAMOS_MIGRATE_{HOT,COLD}
  mm/damon/ops-common: putback folios on invalid migrate nid
  mm/huge_memory: initialise workingset state before folio split
  mm/page_table_check: skip special zero mappings
  mm/damon/lru_sort: skip damon_call() if ctx has not started
  mm/damon/reclaim: skip damon_call() if ctx has not started
  mm/damon/lru_sort: error out for >10000 active_mem_bp
  samples/damon/mtier: error out for zero quota goal target values
  mailmap: map old addresses to Danila Tikhonov
  mm/huge_memory: separate out CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic
  mm/huge_memory: fix huge_zero_pfn race
  MAINTAINERS: update address for Brendan Jackman
  mm/filemap: __filemap_add_folio() restore index before retrying
  microblaze: restore the page alignment of swapper_pg_dir
  arm64: remove redundant concurrent ptdump UAF mitigation
  mm/ptdump: always stabilise against page table freeing using init_mm
  mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF

Merge tag 'v7.2-rc6-smb3-server-fixes' of git://git.samba.org/ksmbd

Pull smb server fixes from Steve French:

 - Reject Pattern_V1 payloads when Pattern_V1 support was not
   negotiated

 - Validate compression transform flags and chained mode before
   allocating the decompression buffer

 - Enforce the pre-authentication PDU size limit before allocating
   the decompression buffer, preventing compressed requests from
   bypassing the limit

* tag 'v7.2-rc6-smb3-server-fixes' of git://git.samba.org/ksmbd:
  ksmbd: apply the pre-authentication PDU limit when decompressing
  ksmbd: validate compression Flags before kvmalloc
  smb: compress: reject Pattern_V1 when not negotiated

Merge tag 'drm-xe-fixes-2026-08-06' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes

- Fix memory leak in exec_queue_set_hang_replay_state (Michal)
- Apply RCS/CCS yield policy to SR-IOV VFs (Marcin)

Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/anSESyrwICYHvZ59@intel.com

rqspinlock: Reset tail when preserving queue on deadlock

Currently, the destruction of the waiter queue is suppressed for
rqspinlock in cases where a deadlock is detected. Deadlock checks happen
relatively frequently (on entry for AA, within 1ms for ABBA), and waiter
threads may not be involved in locking scenarios involving deadlocks.
Thus, it is useful to not flush the queue and let other waiters take a
stab at acquiring the lock after we detect a deadlock and exit.

However, we need to follow the same logic as what we did previously for
the waitq_timeout label: reset the tail, and if we cannot, signal the
next waiter appropriately. In case of deadlocks, this signal would just
mark the MCS node as unlocked, and in case of timeouts, it would signal
RES_TIMEOUT_VAL. The difference thus is in the value propagated, which
decides whether the queue remains active or gets flushed.

Not doing the tail reset, and waiting for the next waiter can lead to
cases where we are the final waiter, and thus no next waiter arrives,
leading to intermittent stalls in this path. Once the next waiter does
join, we will be unblocked. In the theoretical case when the next waiter
never joins, we risk stalling indefinitely.

This can only happen for ABBA deadlocks, since entry into the wait queue
is guarded with AA checks. A precise sequence of executions leading up
to this scenario can be:

CPU 0 holds lock A.
CPU 1 holds lock B.
CPU 2 attempts lock B, becomes the pending waiter for B.
CPU 0 attempts lock B. B has locked+pending bits set, thus CPU 0 queues.
CPU 1 attempts lock A.
CPU 0 detects an ABBA deadlock.

Once deadlock detection happens for CPU 0, it will sit waiting for the
next waiter in the queue to populate node->next, which will experience
delays until such a waiter arrives.

Fix this by adjusting the logic for the check for deadlocks preceding
the waitq_timeout label. It would make sense to consolidate code for
both cases and use 'ret' to distinguish the value being propagated, but
that is left as an exercise for a future refactoring task to avoid diff
noise in this patch.

Fixes: 7bd6e5ce5be6 ("rqspinlock: Disable queue destruction for deadlocks")
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Link: https://patch.msgid.link/20260802021759.1139457-1-memxor@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>

Merge tag 'v7.2-rc6-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6

Pull smb client fixes from Steve French:

 - Fix potential use after free in cifs_try_adding_channels

 - Fix SMB1 large directory enumeration

 - Minor debug improvement (show compress mount option)

* tag 'v7.2-rc6-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  smb: client: fix SMB1 TRANS2 multi-response truncation in SendReceive()
  smb: client: Fix use-after-free in cifs_try_adding_channels()
  smb/client: show compress mount option

watchdog: at91sam9_wdt: prevent timer rearm during teardown

at91_ping() rearms the watchdog timer from its callback. timer_delete()
neither waits for a running callback nor prevents it from rearming the
timer, so probe failure or driver removal can leave the timer accessing the
devm-allocated at91wdt after it has been freed.

Use timer_shutdown_sync() on both teardown paths. It waits for a running
callback and rejects any attempt by the callback to rearm the timer.

Fixes: 5161b31dc39a ("watchdog: at91sam9_wdt: better watchdog support")
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Link: https://lore.kernel.org/r/20260806060613.1830-1-getshell@seu.edu.cn
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Merge tag 'for-7.2-rc6-fixup-worker-tag' of git://git./linux/kernel/git/kdave/linux

Pull Btrfs Fixes 2: Electric Boogaloo from David Sterba:
 "This brings back the fixup worker infrastructure.

  It's a mechanism to detect pages/folios that are marked dirty without
  filesystem knowledge and require COW fixup. The consequence of not
  doing so is silent data loss.

  The first patch covers the scenarios in detail, also reflecting folio
  API port and subpage block size support added in recent years. The
  original fixup worker was only for pages.

  The patch is relatively big, half of the code is debugging and support
  code, the rest is the core design around the detection and fix.

  The second patch handles an unlikely case when there's work left
  during unmount"

* tag 'for-7.2-rc6-fixup-worker-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: flush the fixup workers during close_ctree
  btrfs: trigger cow fixup via dirty_folio()

Merge tag 'for-7.2-rc6-tag' of git://git./linux/kernel/git/kdave/linux

Pull btrfs fixes from David Sterba:

 - fix leak in encoded ioctl write

 - disable large folios on systems with highmem

 - disable block size > page size when there's no transparent hugepage
   support (under experimental config)

 - reject compressed inline extents without valid LZO headers

 - properly initialize cached inode mapping (if block size > page size)

* tag 'for-7.2-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: initialize inode mapping flags for cached inodes
  btrfs: disable bs > ps support if no transparent hugepage support
  btrfs: fix memory leak in btrfs_do_encoded_write()
  btrfs: lzo: reject inline extents without valid headers
  btrfs: disable large folios for systems with highmem

Merge tag 'net-7.2-rc7' of git://git./linux/kernel/git/netdev/net

Pull networking fixes from Jakub Kicinski:
 "Including fixes from netfilter.

  Looks like our attempt to keep the PRs smaller have only prevented
  this one from getting even bigger. In the last 9 days there were
  405 postings explicitly tagged with [PATCH net], vs 687 with [PATCH
  net-next]. 37% of posted patches being fixes is pretty crazy, and
  that's likely undercounting because LLM "researchers" more often post
  fixes without knowing to tag the patches for specific trees. I don't
  have historic data.

  In any case, we keep adjusting the criteria. The next PR will be
  smaller.

  Current release - regressions:

   - net: defer netdev KOBJ_ADD uevent until the device is published,
     previously rtnl_lock would serialize the accesses vs publishing

   - net: explicitly cancel work to avoid races with ref tracker exit

   - qrtr: ns: raise lookup limit to 128

   - eth: hns3: fix speed configuration residue after driver reload

  Previous releases - regressions:

   - tcp: do not change rcv_ssthresh in tcp_measure_rcv_mss(), regressed
     flows with MSS and scaling_ratio variability

   - Revert "net: thunderbolt: Enable end-to-end flow control also in
     transmit", broke some platforms (no packets coming thru)

   - eth: stmmac: resume PHY before hardware setup when opening the
     interface

  Previous releases - always broken:

   - another pile of fixes for less common protocols (SCTP, TLS, SMC
     etc.)

   - close a couple of AF_PACKET bugs and ways it can build skbs
     problematic for the rest of the stack

   - bridge: mrp: fix uninitialised bytes on the wire

   - net: devmem: prevent net-iov / page mixing, avoid crashes

   - eth: atlantic: free RX pages of consumed but not refilled buffers"

* tag 'net-7.2-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (116 commits)
  igc: fix netdev not re-attached after resume if interface is down
  tls: don't abort the connection on signal-interrupted sends
  net: avoid theoretical races with ref drain
  net: Defer netdev KOBJ_ADD uevent until the device is published
  MAINTAINERS: dpll: zl3073x: replace Prathosh Satish with Min Li
  sctp: clear control chunk transport if it is being removed
  net/atm: fix slab-out-of-bounds read in vcc_setsockopt()
  s390/ism: Fix UAF of sba and ieq during ism_dev_exit()
  packet: use consistent hard_header_len in TX_RING send path
  packet: use consistent hard_header_len in non-ring send paths
  net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header
  bnge: Fix resource leak in bnge_init_nic() error path
  ptp: ocp: Fix board ID over-read
  tls: rx: restore msg_iter before TLS 1.3 optimistic retry
  selftests: tls: add a test for splicing onto a full plaintext record
  tls: don't leave a full plaintext sk_msg ring unpushed
  xdp: reject clones that overrun skb_shared_info tailroom
  mptcp: reclaim forward-allocated memory on RX path errors
  mptcp: fastopen: only mark MPTFO subflows with SYN data
  mptcp: pm: fix memory leak from alloc-during-teardown race
  ...

drm/amd/display: allow self-refresh exit while entry is blocked

amdgpu_dm_crtc_set_static_screen_optimze() maps sso_enable to the
Replay and PSR1 vsync events. allow_sr_entry is an entry gate, but the
helper currently applies it to both directions.

A non-fast update clears allow_sr_entry. During a modeset, a separate
hardware-programming event keeps self-refresh blocked while the stream
is reprogrammed. If vblank is enabled before the entry delay expires,
the ISM calls the helper with sso_enable false. The early return drops
the disable request, so the vsync events are not set.

After enough fast commits, allow_sr_entry becomes true and the
hardware-programming event can be cleared. Since the vblank reference
remains held, there is no further zero-to-one vblank transition to
restore the missing vsync events. Replay or PSR1 can then become active
while vblank is still enabled.

Gate only requests that enable static-screen optimization. Always
process disable requests so a vblank requestor keeps Replay and PSR1
blocked.

On a Phoenix system, repeated SDDM-to-VT handoffs produced stuck flips
followed by flip_done and commit-wait timeouts. The timeout was not
observed with this change applied.

Fixes: 3c108046e1d6 ("drm/amd/display: Add power module on Linux")
Assisted-by: Codex:gpt-5.6-sol
Assisted-by: Claude:opus-5
Signed-off-by: David Weber <weber.aulendorf@gmail.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit bd0c00982166d34ed47b11ba29cd8bf2950cc2e2)
Cc: stable@vger.kernel.org

drm/amdgpu: fix aperture iounmap skipped on device removal

amdgpu_pci_remove() calls drm_dev_unplug() before invoking the fini
routines. After drm_dev_unplug() the drm_dev_enter() guard in
amdgpu_ttm_fini() always returns false, so iounmap() for
aper_base_kaddr is silently skipped. On connected_to_cpu hardware
ioremap_cache() maps the aperture as WB; when iounmap() is skipped the
stale WB PAT entry persists. On reload IP discovery's
memremap(MEMREMAP_WC) on the same aperture range hits a WB/WC conflict,
producing an ioremap error and failing re-probe.

Remove the drm_dev_enter() guard and call iounmap() unconditionally.
The aperture mapping is plain MMIO and does not require device-presence
protection. Surprise-removal cleanup of aper_base_kaddr is already
handled unconditionally by amdgpu_device_unmap_mmio().

Fixes: 62d5f9f7110a ("drm/amdgpu: Unmap MMIO mappings when device is not unplugged")
Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit fb3f68af9f6fce9343a2bd13b4d68a1c02d283df)
Cc: stable@vger.kernel.org

drm/amd/display: Check for tg ops in dce110_set_avmute

Some older DCE timing generators do not implement is_tg_enabled in
their ops table. Calling it unconditionally when waiting for AV mute
frames causes a NULL pointer dereference on Southern Islands dGPUs
when turning the display off over HDMI.

Check that tg and the required ops exist before waiting for frames.

Fixes: 414da24137ac ("drm/amd/display: Add AV mute wait frames to dce110_set_avmute")
Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5557
Tested-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de>
Signed-off-by: Ray Wu <ray.wu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 2686a0c0aaa07bec2e24131835cf27b5fd4935a5)
Cc: stable@vger.kernel.org

Revert "drm/amdgpu: fix aperture mapping leak"

devres teardown is LIFO. The aperture devres node was registered after
the DRM device node, so devres_release_all() unmaps the aperture before
the DRM device release callback fires amdgpu_device_fini_sw(). IP
sw_fini callbacks (e.g. vcn_v4_0_sw_fini) write to fw_shared through a
pointer derived from aper_base_kaddr, causing a kernel page fault on
probe failure / rollback:

  BUG: unable to handle page fault ... PMD 0
  RIP: vcn_v4_0_sw_fini+0x7b/0x170 [amdgpu]
  Call Trace:
    amdgpu_device_fini_sw
    amdgpu_driver_release_kms
    devm_drm_dev_init_release
    devres_release_all

This reverts commit d871e99879cb5fd1fa798b006b4888887e63a17a.

Fixes: d871e99879cb ("drm/amdgpu: fix aperture mapping leak")
Reported-by: Yuansheng Mao <yuansheng.mao@amd.com>
Signed-off-by: Asad Kamal <asad.kamal@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 336e0cd576817ac64a4b394ca2b3680029f3e37f)
Cc: stable@vger.kernel.org

drm/radeon: restore hardware polling in fence_is_signaled to fix performance regression

Commit 527ba26e50ec ("drm/radeon: delete radeon_fence_process in
is_signaled, no deadlock") removed the hardware polling from
radeon_fence_is_signaled() to fix a self-deadlock caused by
wake_up_all(&rdev->fence_queue) being called with the fence queue
lock held.

However, removing the polling entirely causes significant performance
regression (e.g. glxgears FPS drop) because the fence signaled check
becomes purely passive — it only reads the cached last_seq without
probing the GPU, so completed GPU work is not detected in time,
causing unnecessary CPU stalls in sync-heavy workloads.

Fix this by calling radeon_fence_activity() directly instead of
radeon_fence_process(). radeon_fence_activity() reads the hardware
fence counter and updates last_seq via atomic ops without calling
wake_up_all(), thus avoiding the deadlock while restoring timely
fence detection.

Fixes: 527ba26e50ec ("drm/radeon: delete radeon_fence_process in is_signaled, no deadlock")
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Wang Jiang <jiangwang@kylinos.cn>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f59ad4cca219c7fdf934f712c5860ec5f5900fd7)
Cc: stable@vger.kernel.org

drm/amd: Disable DP audio spread spectrum for Cyan Skillfish

The VBIOS for Cyan Skillfish devices (DCN201) indicates there is
DisplayPort ref clock spread spectrum downspread, so the audio clock
is corrected for it.

However, the clock source in this hardware does not seem to actually be
running with a clock downspread, so DisplayPort audio desyncs with video
after several minutes.

Ignore dprefclk SS downspread on CYAN_SKILLFISH2 asic.

Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5429
Signed-off-by: Travis K. Bangs <tbangs89@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit f3a2d86587432fdd9a6d401507b60a01153453c5)
Cc: stable@vger.kernel.org

drm/amdgpu/gmc12.1: fix MMHUB0 check in pasid tlb flush

Check for mmhub0 rather than mmhub1.  Looks like a copy
paste typo.

Fixes: d0c989a0aad3 ("drm/amd/amdgpu : Use the MES INV_TLBS API for tlb invalidation on gfx12_1")
Cc: Shaoyun Liu <shaoyun.liu@amd.com>
Reviewed-by: Shaoyun Liu <shaoyun.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0e8faef0aaa4d08f3f4f67ee7bb74e1babc8efc4)
Cc: stable@vger.kernel.org

drm/amdgpu: Allocate coredump ring buffers per ring

Allocate each ring buffer separately. A single allocation summing all
ring sizes can exceed the page allocator's MAX_ORDER limit and fail;
per-ring buffers stay small enough to satisfy. The existing allocation
style doesn't capture any ring data if the huge allocation fails.
Splitting into multiple allocations helps to capture as much data as
possible for the core dump.

A failed ring is left with a NULL buffer and skipped when formatting.

Fixes: eea85914d15b ("drm/amdgpu: save ring content before resetting the device")
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Assisted-by: Claude Code
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3e8e92b7892a6377bef86106bfff1b98cf586aee)
Cc: stable@vger.kernel.org

drm/amdgpu: Use virtual alloc during coredump

The number of rings with outstanding fences can be large, requiring a
bigger allocation. Such allocations don't need to be physically
contiguous, so use kvzalloc/kvcalloc which fall back to vmalloc when
contiguous memory isn't available. This also matches the existing
kvfree used to free these allocations.

Also guard the allocation with ring_count to avoid passing 0 size to
allocation routines.

Fixes: eea85914d15b ("drm/amdgpu: save ring content before resetting the device")
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 74d48bd6b7e12eba65de0507475b059966685ad1)
Cc: stable@vger.kernel.org

drm/amdgpu: reject oversized IBs with per-ring packet limits

On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through
to ib->length_dw without a limit, while ring_emit_ib() encodes length
into packet fields. Oversized values can corrupt adjacent control bits
and destabilize command submission.

Add a per-ring IB packet size limit helper and reject command
submissions exceeding the corresponding dword limit before IB
allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE,
and apply the MM fallback limit for other ring types.

Signed-off-by: Candice Li <candice.li@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52)
Cc: stable@vger.kernel.org

drm/amdgpu/userq: serialize queue map against GPU reset

Creating a user queue can race with a GPU reset. While recovery holds
reset_domain->sem for write, MES is unresponsive, so the ADD_QUEUE from
amdgpu_userq_map_helper() times out (-110) and an otherwise valid queue
create fails:

  amdgpu: MES(0) failed to respond to msg=ADD_QUEUE
  [drm:mes_userq_map [amdgpu]] *ERROR* Failed to map queue in HW, err (-110)
  amdgpu: [drm] *ERROR* ... Failed to map Queue
  amdgpu: [drm] *ERROR* ... Failed to create usermode queue

Take reset_domain->sem for read around the map so it runs only once MES
is back up. This mirrors amdgpu_userq_cleanup() and honors the
userq_mutex -> reset_domain->sem order; the reset path never takes
userq_mutex, so there is no deadlock.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit a8e151fe629c63b0eb08aa57de0d434614db3e1b)
Cc: stable@vger.kernel.org

drm/amdgpu: Fix lockdep false positive in amdgpu_lockdep_init

Move fs_reclaim_acquire() to before all lock acquisitions to eliminate
false positive circular locking dependency warning.

This is a 7.2-cycle regression fix suitable for stable backport.

v3: Address Mikhail Gavrilov technical review:
    - Clarify that fs_reclaim_acquire/release pair only REGISTERS the
      fs_reclaim lock class, does NOT create a static edge when called
      with no locks held
    - Explain that the actual fs_reclaim -> notifier_lock edge is
      established at runtime during memory reclaim -> MMU notifier path
    - Add Cc: Arunpravin PaneerSelvam

v2: Address Mikhail Gavrilov review feedback:
    - Fix author name: Michael -> Mikhail Gavrilov in all trailers
    - Add Fixes: tag to link regression to original commit
    - Add Tested-by: Mikhail Gavrilov (tested on RX 7900 XTX)

Fixes: 1d0f5838b126 ("drm/amdgpu: Add lockdep annotations for lock ordering validation")
Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Analyzed-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Test-case-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Suggested-by: Christian König <christian.koenig@amd.com>
Tested-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Arunpravin PaneerSelvam <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Acked-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 70a1e9849e6ed12bb9f1c0faa24b0f1f9de601eb)
Cc: stable@vger.kernel.org

drm/amdgpu/gmc12.1: implement tlb inv semaphore

Needed to properly lock the interface before using it.

Cc: Sonny Jiang <sonny.jiang@amd.com>
Reviewed-by: Sonny Jiang <sonny.jiang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 8e37aa0bd56ba75801a6a21bed45f96372cd9fdc)
Cc: stable@vger.kernel.org

drm/amdgpu: read TRUNCATE_COORD_MODE on gfx12

TA_CNTL2.TRUNCATE_COORD_MODE selects whether texture coordinate
truncation is D3D9/GL/Vulkan conformant. gfx11 reads it and reports it to
userspace via AMDGPU_IDS_FLAGS_CONFORMANT_TRUNC_COORD, but gfx12 never
read it, so the flag was always reported as 0 and userspace fell back to
the non-conformant path.

Read it in gfx_v12_0_constants_init() like gfx11 does.

Fixes: 52cb80c12e8a ("drm/amdgpu: Add gfx v12_0 ip block support (v6)")
Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 4261cbc7b03f1f56e95aeaf1492b8690fa5a253e)
Cc: stable@vger.kernel.org

drm/amdgpu: fix JPEG v5.3.0 queue reset failure in DPG mode

Like jpeg_v5_0_0, in DPG mode the ring reset path only clears the
JPEG_PG_MODE bit and never resets a hung JRBC, so the post-reset ring test
times out and the driver falls back to a full MODE1 reset.

Temporarily force the static power-gating path during the reset so the
stop/start sequence power-cycles the JPEG block (JMI soft reset + power
off/on), matching the jpeg_v4_0 reset.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e93659cab11c48255dcac58af60203c99815586b)
Cc: stable@vger.kernel.org

drm/amdgpu: fix JPEG v4.0.5 queue reset failure in DPG mode

Like jpeg_v5_0_0, in DPG mode the ring reset path only clears the
JPEG_PG_MODE bit and never resets a hung JRBC, so the post-reset ring test
times out and the driver falls back to a full MODE1 reset.

Temporarily force the static power-gating path during the reset so the
stop/start sequence power-cycles the JPEG block (JMI soft reset + power
off/on), matching the jpeg_v4_0 reset.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 75a308eef4503a9d2bf297bef5a9317d2209e696)
Cc: stable@vger.kernel.org

drm/amdgpu: fix JPEG v5.0.0 queue reset failure in DPG mode

In DPG mode jpeg_v5_0_0_ring_reset() takes the DPG stop path, which only
clears the JPEG_PG_MODE bit and never resets the JRBC. A hung ring is not
recovered: the post-reset ring test times out and the driver falls back to
a full MODE1 reset.

Temporarily force the static power-gating path during the reset so the
stop/start sequence power-cycles the JPEG block (JMI soft reset + power
off/on), matching the jpeg_v4_0 reset which has no DPG path.

Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 79b3612827d1adcd2008cd585961fa35a6ff20f2)
Cc: stable@vger.kernel.org

igc: fix netdev not re-attached after resume if interface is down

__igc_resume() calls netif_device_attach() only inside the
netif_running() branch, so an interface that was down during suspend
is never re-attached on resume. It then stays in the not-present state
that __igc_shutdown() set via netif_device_detach(): ethtool reports
ENODEV and every attempt to bring the interface up fails the
netif_device_present() check in __dev_open() with -ENODEV, silently,
since __igc_resume() returns 0. Only reloading the driver recovers the
device.

This is easy to hit in practice because NetworkManager brings managed
interfaces down before sleep unless Wake-on-LAN is configured, making
the adapter unusable after every suspend/resume cycle with WoL
disabled.

Re-attach the netdev on every successful resume, as igb and e1000e do.

Fixes: 6f31d6b643a3 ("igc: Refactor runtime power management flow")
Cc: stable@vger.kernel.org
Signed-off-by: Philipp David <pd-lkml@3b.pm>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20260804222205.1580328-11-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

tls: don't abort the connection on signal-interrupted sends

When a signal interrupts a blocking send, tls_tx_records() treats the
resulting -ERESTARTSYS as a transmission failure and marks the socket
errored via tls_err_abort() with the raw error code. Later syscalls
return the kernel-internal errno 512 (ERESTARTSYS) to userspace, as the
signal it stems from is no longer pending during syscall exit and thus
never translated.

An interrupted send is not a connection error: the partially sent record
stays queued and is resent later. Interrupt error codes are therefore
excluded from the abort in the same way as -EAGAIN.

Fixes: b341ca51d267 ("tls: Fix tls_sw_sendmsg error handling")
Signed-off-by: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>
Link: https://patch.msgid.link/20260805063109.1772314-1-maxbr@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: avoid theoretical races with ref drain

Technically, it's illegal to take a ref on a netdev just because
we have a pointer on which we already hold a ref, with no other
protection. This is because our simple per-cpu refcount
implementation cannot atomically read the count.

Let's make sure we cancel outstanding work and never queue more
work for a device we know is dead. This way taking a ref on
a dev we know is on the netdev_work_list is always going to be safe.

Jiangshan Yi reports that the issues is caught by ref tracker infra
leading to a warning:
  WARNING: lib/ref_tracker.c:322 at ref_tracker_free
  WARNING: lib/ref_tracker.c:246 at ref_tracker_dir_exit

Reported-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Link: https://lore.kernel.org/20260731035135.3917308-2-yijiangshan@kylinos.cn
Fixes: 12c765be84d2 ("net: turn the rx_mode work into a generic netdev_work facility")
Link: https://patch.msgid.link/20260806022821.2079945-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: Defer netdev KOBJ_ADD uevent until the device is published

netdev_register_kobject() calls device_add(), which emits KOBJ_ADD and
wakes udev, but register_netdevice() only makes the device findable by
name later, in list_netdevice().  A udev worker that reacts to the uevent
can therefore run against a device that no lookup can find yet.

This used to be harmless because the ethtool ioctl took the rtnl_lock
when looking the device up, and register_netdevice() runs under rtnl, so
the worker simply blocked until registration finished. The commit in the
fixes tag moved the lookup out from under rtnl for ops-locked drivers.
Now there is a short window in register_netdevice() between
netdev_register_kobject() until list_netdevice() when the device is not
findable by name.

This was reproduced with the mlx5 driver on a kernel with KASAN enabled
during devlink reload: systemd-udevd's net_driver builtin gets -ENODEV
from ETHTOOL_GDRVINFO, which was preventing interface renaming.

Suppress the uevent in netdev_register_kobject() and emit it from
register_netdevice() next to rtmsg_ifinfo(). This is the last point in
register_netdevice() where no error can happen, so only fully registered
devices are announced: the registration error paths never reach it, and
the device_del() that unwinds them stays silent as well, leaving
userspace with neither an add nor a remove.

Fixes: f994752b1127 ("net: ethtool: optionally skip rtnl_lock on IOCTL path")
Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Shahar Shitrit <shshitrit@nvidia.com>
Link: https://patch.msgid.link/20260806080758.2039586-2-dtatulea@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

MAINTAINERS: dpll: zl3073x: replace Prathosh Satish with Min Li

Replace Prathosh Satish by Min Li as the Microchip co-maintainer
of the ZL3073X DPLL driver.

Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Link: https://patch.msgid.link/20260805155425.38808-1-ivecera@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

sctp: clear control chunk transport if it is being removed

sctp_make_heartbeat_ack() caches the destination transport in
chunk->transport without taking a reference. When src_out_of_asoc_ok is
enabled, the HEARTBEAT ACK may remain queued on control_chunk_list instead
of being transmitted immediately.

If the peer transport is removed while the chunk is still queued,
sctp_assoc_rm_peer() drops the transport and schedules it for RCU freeing,
but only clears cached transport pointers in out_chunk_list.  The queued
control chunk therefore retains a dangling transport pointer.

Once an ASCONF_ACK clears the suppression and the queued control chunk is
transmitted, SCTP dereferences the stale transport pointer, leading to a
use-after-free.

Fix this by also clearing chunk->transport for queued control chunks in
control_chunk_list when removing the transport.

Fixes: 8a07eb0a50ae ("sctp: Add ASCONF operation on the single-homed host")
Reported-by: Daniele Linguaglossa <danielelinguaglossa@gmail.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/7e1168cb722132152a29d47e5eafaeac4a3bf6f3.1785943120.git.lucien.xin@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net/atm: fix slab-out-of-bounds read in vcc_setsockopt()

vcc_setsockopt() contained an ineffective optlen check:
  if (__SO_LEVEL_MATCH(optname, level) && optlen != __SO_SIZE(optname))
      return -EINVAL;

If __SO_LEVEL_MATCH(optname, level) evaluated to false (e.g. if the caller
passed a mismatched level), the length check optlen != __SO_SIZE(optname)
was short-circuited and bypassed. Execution then fell through to switch(optname),
calling copy_from_sockptr() assuming optval contained sufficient space.

Furthermore, even if level matched, a cgroup BPF setsockopt filter could shrink
optlen after entry. Because copy_from_sockptr() on kernel pointers uses memcpy(),
this leads to a KASAN slab-out-of-bounds read when optlen is smaller than the
expected structure size.

Fix this by using copy_safe_from_sockptr(), which unconditionally validates
that optlen is at least the expected size before copying. Also change the local
'value' variable type from 'unsigned long' to 'int' so that SO_SETCLP matches
its sizeof(int) ABI encoding on 64-bit systems.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+53ecc09fb81df10ef4de@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=53ecc09fb81df10ef4de
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260805131508.3227331-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

s390/ism: Fix UAF of sba and ieq during ism_dev_exit()

A ism interrupt handler can be active in parallel with ism_dev_exit(),
accessing freed data structures.

No new interrupts will be generated after unregister_ieq(). Drain ongoing
interrupt handlers by free_irq(), before freeing ism data structures.

Fixes: 684b89bc39ce ("s390/ism: add device driver for internal shared memory")
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Link: https://patch.msgid.link/20260805131043.954639-1-wintera@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Merge branch 'net-fix-hard_header_len-races-in-packet-send-paths'

Qihang Tang says:

====================
net: fix hard_header_len races in packet send paths

The packet socket TX paths read dev->hard_header_len independently for
skb allocation and header construction. Concurrent netdevice
reconfiguration (e.g. bonding device type changes) can change this value
in between, leading to mismatched headroom and copy length, and in the
SOCK_RAW case to out-of-bounds writes.

Patch 1 removes the CAP_SYS_RAWIO zero-padding branch in
dev_validate_header(). That branch sizes a memset against the live
dev->hard_header_len while operating on an skb whose headroom was
allocated from an earlier hard_header_len read, so a concurrent increase
can write past the reserved buffer. Removing it first keeps the later
snapshot fixes bisect-safe: they do not replace an earlier skb_under_panic
with a silent overwrite.

Patches 2 and 3 snapshot hard_header_len once per send and use it
consistently for allocation and construction, in the non-ring and TX_RING
paths respectively. The separate SOCK_DGRAM consistency problem between
hard_header_len and header_ops->create remains out of scope, as noted in
the commit messages.
====================

Link: https://patch.msgid.link/20260805125729.19220-1-q.h.hack.winter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

packet: use consistent hard_header_len in TX_RING send path

tpacket_snd() reads dev->hard_header_len independently for skb
allocation and header construction in tpacket_fill_skb(). Concurrent
netdevice reconfiguration can therefore make the reserved headroom
smaller than the amount later pushed, or make copylen - hard_header_len
negative.

Snapshot hard_header_len once before processing ring frames and use it
for the frame limit, headroom allocation, copy length, and skb
construction. Pass the snapshot to tpacket_fill_skb().

The separate SOCK_DGRAM consistency problem between hard_header_len and
header_ops->create is not addressed here.

Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap")
Cc: stable@vger.kernel.org
Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260805125729.19220-4-q.h.hack.winter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

packet: use consistent hard_header_len in non-ring send paths

packet_snd() reads dev->hard_header_len multiple times while allocating
and constructing an skb. Device reconfiguration can change this value
concurrently, for example through bonding device type changes.

For SOCK_RAW, packet_snd() can save a larger value in reserve and later
allocate headroom using a smaller value. Moving skb->data back by reserve
then places it before skb->head, and the following copy from userspace can
attempt an out-of-bounds write.

packet_sendmsg_spkt() has the same issue because it calculates its
reservation and header offset from separate reads before dropping the RCU
read lock to allocate the skb.

Add LL_RESERVED_SPACE_EX() for callers that already saved a header length.
Read hard_header_len once in packet_snd() and use it for allocation and
construction. In packet_sendmsg_spkt(), preserve the allocation-time value
through the device lookup retry.

The separate SOCK_DGRAM consistency problem between hard_header_len and
header_ops->create is not addressed here.

Fixes: b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation")
Cc: stable@vger.kernel.org
Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260805125729.19220-3-q.h.hack.winter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: remove CAP_SYS_RAWIO zero-padding in dev_validate_header

dev_validate_header() reads dev->hard_header_len directly when
zero-padding short link layer headers for CAP_SYS_RAWIO holders:

    if (capable(CAP_SYS_RAWIO)) {
        memset(ll_header + len, 0, dev->hard_header_len - len);
        return true;
    }

Packet send paths call dev_validate_header() on skbs whose headroom was
allocated from an earlier hard_header_len read. If the device is
reconfigured so that dev->hard_header_len increases before validation,
the memset writes past the reserved buffer, an out-of-bounds write.

This out-of-bounds write is masked in some SOCK_RAW paths today because
the same concurrent increase can first make skb_push() exceed the
reserved headroom and trigger skb_under_panic(). Remove the zero-padding
branch before making those hard_header_len reads consistent, so the
snapshot fixes do not turn a loud panic into a silent overwrite.

This path is only reached for variable length L2 protocols, where
len < hard_header_len but len >= min_header_len. No remaining in-tree
variable length L2 protocol implements header_ops->validate, and the
CAP_SYS_RAWIO bypass that zero-pads and accepts short headers has no
real value beyond allowing testing of intentionally malformed input.

Drop the CAP_SYS_RAWIO branch. The remaining reads of
dev->hard_header_len in dev_validate_header() are comparisons only and
have no memory safety impact.

Suggested-by: Willem de Bruijn <willemb@google.com>
Fixes: 2793a23aacbd ("net: validate variable length ll headers")
Cc: stable@vger.kernel.org
Signed-off-by: Qihang Tang <q.h.hack.winter@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260805125729.19220-2-q.h.hack.winter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

bnge: Fix resource leak in bnge_init_nic() error path

If bnge_init_chip() fails, bnge_init_nic() jumps to err_free_ring_grps
and returns immediately, skipping cleanup for RX ring pair buffers.

Remove the early return so execution falls through to
err_free_rx_ring_pair_bufs to properly free resources on error.

Fixes: 23df6aebf803 ("bng_en: Allocate stat contexts")
Signed-off-by: Bhargava Marreddy <bhargava.marreddy@broadcom.com>
Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com>
Reviewed-by: Rajashekar Hudumula <rajashekar.hudumula@broadcom.com>
Link: https://patch.msgid.link/20260805094022.15487-1-bhargava.marreddy@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

ptp: ocp: Fix board ID over-read

The EEPROM board ID is a fixed 13-byte field and is not guaranteed to
contain a NUL terminator. Passing it directly to
devlink_info_version_fixed_put() treats it as a C string and may read
beyond the field.

Format at most OCP_BOARD_ID_LEN bytes into the existing local buffer
before reporting the ID. Use a precision limit because the snprintf()
output size alone does not bound the source string scan.

Fixes: 0cfcdd1ebcfe ("ptp: ocp: add nvmem interface for accessing eeprom")
Cc: stable@vger.kernel.org
Signed-off-by: Ahmad Byagowi <ahmadexp@gmail.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260804210751.48248-1-ahmadexp@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

tls: rx: restore msg_iter before TLS 1.3 optimistic retry

tls_decrypt_sg() advances msg->msg_iter when it maps user pages for
the optimistic TLS 1.3 zero-copy path. If the decrypted record turns
out not to be unpadded application data, tls_decrypt_sw() retries into
a kernel skb, but leaves the iterator advanced.

The subsequent copy from the skb then writes decrypted bytes again at
a later point in the caller iovecs while recvmsg() reports only the
post-retry length. A TLS peer can trigger this after the receiver
enables TLS_RX_EXPECT_NO_PAD.

Revert the iterator by the number of bytes consumed by the optimistic
mapping before retrying without zero-copy.

Add a selftest which sends a TLS 1.3 control record with
TLS_RX_EXPECT_NO_PAD enabled and verifies that recvmsg() does not
overwrite later iovecs beyond the returned length.

Fixes: ce61327ce989 ("tls: rx: support optimistic decrypt to user buffer with TLS 1.3")
Cc: stable@vger.kernel.org
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Link: https://patch.msgid.link/20260804125528.2139928-1-Jeremy.Jean@oss.cyber.gouv.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Merge branch 'tls-fix-plaintext-sk_msg-ring-over-fill'

chanyoung says:

====================
tls: fix plaintext sk_msg ring over-fill

An unprivileged user can oops the kernel by splicing into a kTLS socket
whose open record already has a full plaintext sk_msg ring.  Reproduced on
net (53658c6f3682) with a stock config, no KASAN.

Patch 2 oopses an unpatched kernel and passes with patch 1 applied.
====================

Link: https://patch.msgid.link/20260804052837.49015-1-ppoo1220@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

selftests: tls: add a test for splicing onto a full plaintext record

Splicing onto a plaintext sk_msg ring that is already full used to wrap the
ring and make the kernel oops in the scatterwalk once the record was
pushed.

Only the copy path leaves the ring full without pushing it, so splice until
the ring is one fragment short, add the last fragment with a one-byte
MSG_MORE send, and splice once more before pushing the record.

CONFIG_MAX_SKB_FRAGS is 17..45, so that last fragment follows between 16
and 44 splices; sweep that range to trigger the bug on any build.

Signed-off-by: chanyoung <ppoo1220@gmail.com>
Link: https://patch.msgid.link/20260804052837.49015-3-ppoo1220@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

tls: don't leave a full plaintext sk_msg ring unpushed

When the copy path in tls_sw_sendmsg_locked() adds the fragment that fills
the plaintext sk_msg ring, it does not set full_record, so the record is
left full and unpushed.  A later splice() then adds to an already full
ring: sk_msg_page_add() has no fullness check of its own, so sg.end wraps
onto sg.start and the ring appears empty.  Fragments added after that
overwrite live entries, and sg.size no longer matches what is reachable
between sg.start and sg.end, so pushing the record runs the scatterwalk off
the end of the scatterlist.

An unprivileged user can trigger this on a loopback TCP socket with the
"tls" ULP attached:

  BUG: kernel NULL pointer dereference, address: 0000000000000008
  RIP: 0010:memcpy_from_scatterwalk+0x32/0xc0
  Call Trace:
   skcipher_walk_next+0x1d1/0x2c0
   gcm_encrypt_aesni_avx+0x1e9/0x220
   bpf_exec_tx_verdict+0x3bb/0x860
   tls_sw_sendmsg+0xa1a/0xca0
   __sys_sendto+0x1da/0x1f0

Set full_record in the copy path when the ring becomes full, and push a
record that is already full on entry to the sendmsg loop.

Suggested-by: Sabrina Dubroca <sd@queasysnail.net>
Fixes: fe1e81d4f73b ("tls/sw: Support MSG_SPLICE_PAGES")
Cc: stable@vger.kernel.org
Signed-off-by: chanyoung <ppoo1220@gmail.com>
Link: https://patch.msgid.link/20260804052837.49015-2-ppoo1220@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

ata: pata_sl82c105: fix bridge revision use-after-free

pci_get_slot() returns a referenced PCI device. Commit 44c10138fd4b
("PCI: Change all drivers to use pci_device->revision") replaced a
configuration-space read with direct access to the cached revision field,
but left that access after pci_dev_put(). The bridge may therefore be freed
before its revision is read.

Read the revision before dropping the reference.

Fixes: 44c10138fd4b ("PCI: Change all drivers to use pci_device->revision")
Signed-off-by: Hongyan Xu <getshell@seu.edu.cn>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>

xdp: reject clones that overrun skb_shared_info tailroom

xdpf_clone() clones broadcast copies into a single page and sets
frame_sz to PAGE_SIZE. __xdp_build_skb_from_frame() later treats that
page like a normal XDP frame and expects the usual skb_shared_info
tailroom at the end of the buffer.

The current check only rejects frames whose linear xdp_frame header,
headroom, and packet data exceed PAGE_SIZE. A source frame backed by a
larger allocation can still satisfy that check while extending into the
clone's required shared-info area. When such a clone is converted back
into an skb, build_skb_around() places skb_shared_info over live packet
bytes and later writes can corrupt XDP return metadata.

Reject clones unless their linear area fits inside
SKB_WITH_OVERHEAD(PAGE_SIZE), matching the tailroom requirement already
enforced by the XDP-to-skb conversion path.

Fixes: e624d4ed4aa8 ("xdp: Extend xdp_redirect_map with broadcast support")
Cc: stable@vger.kernel.org
Reported-by: Vega <vega@nebusec.ai>
Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Link: https://patch.msgid.link/6b2afef5d1738763c6965e8e466eb16e43e4f956.1785757386.git.zhilinz@nebusec.ai
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Merge branch 'mptcp-misc-fixes-for-v7-2-rc6'

Matthieu Baerts says:

====================
mptcp: misc fixes for v7.2-rc6

Here are various unrelated fixes:

- Patches 1-3: harden incoming MPTCP suboptions parsing by rejecting
  non-combinable ones. Patch 3 removes unreachable code after patch 2
  added here for consistency, and to reduce comments from AI reviews.
  Fixes for v5.6.

- Patch 4: fix a data race in the ADD_ADDR timer callback. A fix for
  v5.13.

- Patch 5: correctly catch data corruption during the MPTCP join
  selftest by marking tests as failed, instead of only printing a
  warning. A fix for v5.18.

- Patch 6: fix a leak with the userspace ADD_ADDR list in case of race
  condition during teardown. A fix for v5.19.

- Patch 7: deal with MPTFO with a valid token, but no data in the SYN. A
  fix for v6.2.

- Patch 8: reclaim forward-allocated memory in case of error on the
  receive side. A fix for v6.19.
====================

Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-0-b8f496d71664@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

mptcp: reclaim forward-allocated memory on RX path errors

After commit 9db5b3cec4ec ("mptcp: borrow forward memory from subflow"),
errors in the receive path prior to queueing skbs into the receive
queue do not trigger forward-allocated memory reclaiming.

Prevent forward memory from growing unboundedly in pathological drop
scenarios by explicitly reclaiming memory when skbs are dropped.

Fixes: 9db5b3cec4ec ("mptcp: borrow forward memory from subflow")
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-8-b8f496d71664@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

mptcp: fastopen: only mark MPTFO subflows with SYN data

Passive TCP Fast Open accepts a valid-cookie SYN even when it carries
no data. In that case the child socket's receive queue is intentionally
left empty.

mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking
for queued SYN data. That made data-less TFO SYNs hit a WARN and, if
the warning was non-fatal, left stale MPTFO state behind. The stale
flag could later trigger a state-confusion bug in
check_fully_established().

Only mark the subflow as MPTFO after confirming that an SKB was queued.
Return quietly when the receive queue is empty.

Note that mptcp_subflow_context's is_mptfo field is now not just about
subflows where the TFO was present, but about MPTFO subflow that
consumed SYN data. Only having a valid cookie but not carrying data is
not really "doing TFO".

Fixes: 36b122baf6a8 ("mptcp: add subflow_v(4,6)_send_synack()")
Cc: stable@vger.kernel.org
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-7-b8f496d71664@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

mptcp: pm: fix memory leak from alloc-during-teardown race

mptcp_pm_destroy() empties msk->pm.anno_list and
msk->pm.userspace_pm_local_addr_list under msk->pm.lock during socket
teardown, dropping the lock between the two.

A concurrent userspace PM genl ANNOUNCE on the same msk holds a sock
reference via mptcp_token_get_sock() and, in
mptcp_pm_nl_announce_doit(), calls
mptcp_userspace_pm_append_new_local_addr() and
mptcp_pm_announced_alloc(). Both take msk->pm.lock briefly to add to
their respective lists. Because the genl handler holds a sock reference,
mptcp_pm_destroy() may run on the same msk via mptcp_disconnect(), which
invokes mptcp_destroy_common() without dropping the sock refcount,
before the handler completes.

If the lock acquisitions interleave such that mptcp_pm_destroy() empties
a list first, the later alloc adds its entry to a list head that nothing
else iterates for this msk, and the entry leaks. kmemleak reports both
mptcp_pm_add_addr objects (from mptcp_pm_announced_alloc()) and
mptcp_pm_addr_entry objects (from
mptcp_userspace_pm_append_new_local_addr()) under sustained concurrent
ANNOUNCE + close load against the userspace PM.

Add an MPTCP_PM_DESTROYING bit in msk->pm.status, set by
mptcp_pm_destroy() under pm.lock before the lists are emptied and
checked under pm.lock by the alloc paths. Either the alloc takes pm.lock
first, in which case its entry is on the list when mptcp_pm_destroy()
frees it; or mptcp_pm_destroy() takes pm.lock first, in which case the
later alloc observes the bit and refuses.

Found by an MPTCP protocol-flow harness extending BRF (arXiv:2305.08782).

Fixes: 9ab4807c84a4 ("mptcp: netlink: Add MPTCP_PM_CMD_ANNOUNCE")
Cc: stable@vger.kernel.org
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-6-b8f496d71664@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

selftests: mptcp: join: mark tests with data corruption as failed

check_transfer() compares the input and output files byte-by-byte using
`cmp -l "$in" "$out" | while read ...`. Because the while-loop body runs
in a subshell (the script sets neither lastpipe nor pipefail), the
fail_test call inside it -- which sets the global ret/last_test_failed --
and the `return 1` both act on the subshell, not on check_transfer().

check_transfer() thus always falls through to `return 0`, and any data
corruption affecting only the payload (leaving the subflow/PM counters
untouched) is silently reported as PASS.

Fixes: 8117dac3e7c3 ("selftests: mptcp: add invert check in check_transfer")
Cc: stable@vger.kernel.org
Signed-off-by: Gang Yan <yangang@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-5-b8f496d71664@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

mptcp: pm: fix data race in add_addr timer callback

The timer callback reads entry->retrans_times outside pm.lock to decide
whether to call mptcp_pm_subflow_established(). Since
mptcp_pm_announced_del_timer() can concurrently set retrans_times =
ADD_ADDR_RETRANS_MAX under pm.lock, a race condition exists.

I discovered this issue while studying the code. AI tools helped me to
verify the issue can potentially happen under race conditions.

Use a local 'retransmit' flag set inside pm.lock to capture whether
retransmission is still possible when the lock is taken. This allows to
call mptcp_pm_subflow_established() accordingly, and not depending on
the situation that can be different when checked outside the pm.lock.

Fixes: 348d5c1dec60 ("mptcp: move to next addr when timeout")
Cc: stable@vger.kernel.org
Signed-off-by: Qing Luo <luoqing@kylinos.cn>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-4-b8f496d71664@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

mptcp: remove MPC && MPJ check

After the parent commit ("mptcp: avoid combining some incoming
suboptions"), the parsing step no longer allow to have both the
MP_CAPABLE and MP_JOIN suboptions set together.

These chunks are now unreachable, these checks can then be removed.

Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-3-b8f496d71664@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

mptcp: avoid combining some incoming suboptions

Some MPTCP suboptions are mutually exclusive according to the RFC8684,
but also because in different places, the code doesn't expect some
combinations to be present. That's specially true for suboptions that
would be present twice, but with different attributes.

The new restrictions are the same as the ones applied on the output
side, with mptcp_write_options. The same rules can be reused with a
small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks
this option [1], which is not the case on Linux. Here are the rules:

  Which options can be used together?

  X: mutually exclusive
  O: often used together
  C: can be used together in some cases
  P: could be used together but we prefer not to (optimisations)

  | Opt: | MPC  | MPJ  | DSS  | ADD  |  RM  | PRIO | FAIL |  FC  |
  |------|------|------|------|------|------|------|------|------|
  | MPC  |------|------|------|------|------|------|------|------|
  | MPJ  |  X   |------|------|------|------|------|------|------|
  | DSS  |  X   |  X   |------|------|------|------|------|------|
  | ADD  |  X   |  X   |  P   |------|------|------|------|------|
  | RM   |  C   |  C   |  C   |  P   |------|------|------|------|
  | PRIO |  X   |  C   |  C   |  C   |  C   |------|------|------|
  | FAIL |  X   |  X   |  C   |  X   |  X   |  X   |------|------|
  | FC   |  X   |  X   |  P   |  X   |  X   |  X   |  X   |------|
  | RST  |  X   |  X   |  X   |  X   |  X   |  X   |  O   |  O   |
  |------|------|------|------|------|------|------|------|------|

The only difference is with the 'P': another stack could send and
ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be
allowed.

A few points of attention:

 - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is
   no reason to add it with a SYN. Note that even with a 4th ACK, it
   doesn't seem to be useful, except when IDs are known in advance via
   another channel. Better not to break that.

 - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer
   result to a reject of the two options, but only the second suboption
   is ignored. That seems OK to do that for this unexpected error. At
   least now all inconsistent combinations are handled the same way.
   This could change later in next. This also means the explicit checks
   for having both MPC + MPJ in subflow.c will now be unreachable.
   That's fine, they will be removed in a follow-up patch.

 - In case of conflicting combinations, the extra suboption(s) is/are
   ignored: having such combinations either means the remote peer is
   buggy, or is evil. The simplest action is then taken in this case:
   stop processing the current suboption.

 - In mp_opt->suboptions, there is also a bit reserved to the checksum,
   which can be used in an MP_CAPABLE and a DSS. Each time a DSS option
   can be used in parallel with another option, the checksum can be set,
   so the verification is combined into a new OPTIONS_MPTCP_DSS macro.

 - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional
   Checksum: they are the same as the ones found in a DSS, because a DSS
   cannot be used in parallel to an MP_CAPABLE. Similarly, even if there
   is room, a DSS cannot be used with an MP_JOIN.

Fixes: eda7acddf808 ("mptcp: Handle MPTCP TCP options")
Cc: stable@vger.kernel.org
Link: https://www.rfc-editor.org/rfc/rfc8684.html#section-3.5-5.1
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-2-b8f496d71664@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

mptcp: options: reset DSS fields in case of unexpected size

A remote peer could send a malformed DSS with a wrong size, followed by
another DSS or MPC + Data. In this case, the first suboption will be
ignored, but leaving some fields written, which could lead to
inconsistency or access uninitialized data.

Explicitly reset the fields that could have been modified in case of
unexpected size.

Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260728-net-mptcp-misc-fixes-7-2-rc6-v1-0-f7e2d229159d%40kernel.org?part=1
Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path")
Cc: stable@vger.kernel.org
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260803-net-mptcp-misc-fixes-7-2-rc6-v2-1-b8f496d71664@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Merge tag 'probes-fixes-v7.2-rc6' of git://git./linux/kernel/git/trace/linux-trace

Pull probes selftest fix from Masami Hiramatsu:

 - selftests/ftrace: Refactor eprobes test to fix argument checks

   Refactor the eprobes selftest to get more stable test result by using
   `sys_enter_chdir` instead of `openat` and filter for exact directory
   names

   This resolves test instability after the string pointer handling fix

* tag 'probes-fixes-v7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  selftests/ftrace: refactor eprobes test to fix argument checks

net: usb: ipheth: fix carrier_work UAF on disconnect

ipheth_sndbulk_callback() re-arms the carrier-check work on any
non-zero URB status:

else
schedule_delayed_work(&dev->carrier_work, 0);

Nothing ties that to the interface being up, so the work can be armed
again after ipheth_close() has already drained it, and stay armed
until the netdev whose private area embeds it is freed.

On unplug with a TX URB in flight, ipheth_disconnect() drains the work
through unregister_netdev() -> ipheth_close() ->
cancel_delayed_work_sync() and only then calls ipheth_kill_urbs().
usb_kill_urb() completes the in-flight TX URB with -ENOENT, so
ipheth_sndbulk_callback() runs after the drain and re-arms
carrier_work.

The same completion also re-arms the work if the interface is only
brought down while a TX URB is in flight, and
ipheth_carrier_check_work() then keeps re-queueing itself once a
second. unregister_netdev() does not call ipheth_close() for an
already-down interface, so nothing drains it on the later unplug
either.

In both cases free_netdev() frees the netdev while carrier_work is
still pending, and ipheth_carrier_check_work() dereferences freed
memory.

Tie the work to the interface state instead of chasing the completion:
disable it in ipheth_close() and enable it in ipheth_open(), so a
schedule_delayed_work() from the URB completion is a no-op whenever
the interface is not up. disable_delayed_work_sync() also waits for a
running instance, so it fully replaces the cancel_delayed_work_sync()
it takes the place of. The work starts out disabled in ipheth_probe()
so the enable/disable counts balance from the first open.

Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and
raw-gadget standing in for the device, driving the second path above (the
interface is already down, so unregister_netdev() does not call
ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in
__run_timers(), freed by ipheth_disconnect() and re-armed from
ipheth_sndbulk_callback() via queue_delayed_work_on(). The
same trigger on a kernel differing only by this patch reports 0 of 15,
and the carrier check still functions across open/close cycles.

The reproducer needs an attached USB device that stops draining bulk OUT,
plus a link down and unplug, driven as root. It is not a privilege
boundary crossing and no exploit primitive was developed.

Found by 0sec (https://0sec.ai).

Fixes: bb1b40c7cb86 ("usbnet: ipheth: prevent TX queue timeouts when device not ready")
Cc: stable@vger.kernel.org
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
Link: https://patch.msgid.link/20260802120602.42595-1-doruk@0sec.ai
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: thunderbolt: Tear down DMA paths before stopping the rings

tbnet_tear_down() stops both rings and frees their frame buffers before
calling tb_xdomain_disable_paths().  tb_ring_stop() zeroes the ring's
descriptor base and tbnet_free_buffers() unmaps and frees the pages the
frames sit in, so by the time __tb_path_deactivate_hop() polls the hop's
'pending' bit, anything still in flight has nowhere to drain to.

The teardown sequence has been in this order since the driver was added.
The setup path has not: commit ff7cd07f3064 ("net: thunderbolt: Enable
DMA paths only after rings are enabled") moved the path enable to the end
of tbnet_connected_work() and documented why:

/* Both logins successful so enable the rings, high-speed DMA
 * paths and start the network device queue.
 *
 * Note we enable the DMA paths last to make sure we have primed
 * the Rx ring before any incoming packets are allowed to
 * arrive.
 */

Teardown was never updated to match, so the rings and the paths now come
down in the same order they go up instead of in reverse.

On an ASMedia ASM4242 host router the 'pending' bit then never clears:
every teardown burns the full 500 ms timeout and
__tb_path_deactivate_hop() returns -ETIMEDOUT.  Raising the timeout to
5 s does not help, so the hop is not slow to drain, it never drains
at all.

The failure is invisible above the thunderbolt core.
__tb_path_deactivate_hops() is void and only calls tb_port_warn();
tb_path_deactivate(), tb_tunnel_deactivate() and
__tb_disconnect_xdomain_paths() are void as well, and
tb_disconnect_xdomain_paths() ends in an unconditional "return 0".  So
tb_xdomain_disable_paths() reports success and the netdev_warn() below
it never fires.  Repeated teardowns eventually take the XDomain control
channel down, after which the peer node is gone and only a power cycle
brings the controller back.

Deactivating the paths first fixes it.  Measured with kretprobes on a
stock v6.17 tree with no other patches applied, on a link that was up
and had just carried traffic:

  before: __tb_path_deactivate_hop() returns 0 for the first hop, then
          -ETIMEDOUT for the second 500335 us later
  after:  0 for both, 525 us apart

Alternating the two orderings ABBA over three load levels, four
teardowns per arm: every teardown failed before the change (21 of 21
that ran), none failed after (0 of 24).  The before arms ran short
because the link died partway through.  The same split shows up when
the interface is enslaved to a bond instead of just brought down, which
is how I ran into this in the first place.  Throughput and latency after
the change are unchanged.

Hosts whose routers drain the hop despite the stale descriptor base see
no functional difference, since the paths end up deactivated either way.

Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
Signed-off-by: Fan XinRan <shinjiangjiang@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://patch.msgid.link/20260803-b4-tbnet-teardown-v2-1-27de6a13ca2d@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

Merge tag 'xfs-fixes-7.2-rc7' of git://git./fs/xfs/xfs-linux

Pull xfs fixes from Carlos Maiolino:
 "This contains mostly a collection of bug fixes found by LLM tools"

* tag 'xfs-fixes-7.2-rc7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: (34 commits)
  xfs: check v5 superblock features early
  xfs: add a comment to describe xfs_gc_bio.victim_rtg
  xfs: add a separate bio_set for spliting GC writes
  xfs: don't swallow dquot recovery verification errors
  xfs: fix ilock leak on error in xfs_dq_get_next_id
  xfs: don't ignore runtime errors in xrep_iunlink_reload_next
  xfs: set the prev pointer when reinserting an inode on the unlinked list
  xfs: fix another iunlink infinite loop bug in online fsck
  xfs: fix allocated inodes that show up in the unlinked list
  xfs: check xfarray iteration errors when committing unlinked inode lists
  xfs: pass runtime errors from xrep_iunlink_mark_ondisk_rec up to callers
  xfs: load next_agino from the correct xfarray in xrep_iunlink_relink_prev
  xfs: don't walk off the end of a null sc->sa.agi_bp in AGI repair
  xfs: don't livelock in scrub on a circular unlinked list
  xfs: hoist per-bucket unlinked list check to helper
  xfs: avoid UAF on sc->tempip in xrep_tempfile_create
  xfs: nlink scrub must take IOLOCK before determining ILOCK state
  xfs: don't zap the attr fork on repair when there are queued pptr updates
  xfs: don't return EFSCORRUPTED when scrubbing corrupt parent pointers
  xfs: don't double-lock when deleting a self-referential directory
  ...

net: qrtr: ns: Raise lookup limit to 128

Current limit of 64 is not enough for Sony Xperia 10 VII (SM6475).

After merging v6.6.142 into a downstream AOSP device, it's stuck on
boot animation and following log spam can be observed in dmesg:

E qrtr    : ctrl_cmd_new_lookup(): QRTR client node exceeds max lookup limit!
E qrtr    : qrtr_ns_worker(): failed while handling packet from 1:16600

No idea why it needs more than 64 client lookups, but it appears to
work fine with 128 as it did when there were no limits.

I don't really have a good way to investigate what it needs all
these lookups for as most of the userspace is closed source.

Fixes: 5640227d9a21 ("net: qrtr: ns: Limit the maximum number of lookups")
Signed-off-by: Łukasz Patron <priv.luk@gmail.com>
Link: https://patch.msgid.link/20260804201919.1148015-1-priv.luk@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

KVM: SVM: Serialize accesses to the owner and mirror list with separate lock

Interaction between KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and
KVM_CAP_VM_COPY_ENC_CONTEXT_FROM can cause two separate issues:

- in sev_migrate_from(), when the destination KVM is a mirror, the mirror
  entry is moved from the source's list to the owner's mirror_vms list,
  without holding the owner's lock unlike other writers of the owner's
  mirror list (sev_vm_copy_enc_context_from(), sev_vm_destroy()).
  A concurrent COPY or destroy can race with sev_migrate_from() and
  corrupt the list.

- In sev_vm_destroy(), the *owner* is still active and could receive
  concurrently a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM that causes
  sev->enc_context_owner to change.  In this case the incorrect VM
  receives kvm_put_kvm().

The second issue needs particular care because the owner could disappear
altogether (even though the race window is impossibly small) between
reading it and locking it.  There is thus no way to perform the checks
under the owner lock without putting struct kvm under SLAB_TYPESAFE_BY_RCU
(which would allow kvm_get_kvm_safe() under RCU critical section).

It is much simpler to just use a global lock, since the critical
sections are so small and the new lock is always a leaf lock.

Fixes: b2125513dfc0 ("KVM: SEV: Allow SEV intra-host migration of VM with mirrors")
Cc: stable@vger.kernel.org
Reported-by: Shen Yongchao <grayhat@foxmail.com>
Link: https://lore.kernel.org/kvm/tencent_625C0F42824E542C72B34733392AF2C49709@qq.com/
Link: https://lore.kernel.org/kvm/tencent_DDC4E4352EC91CAC05A9A8F4E55E8C96730A@qq.com/
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Merge tag 'kvm-s390-master-7.2-3' of https://git./linux/kernel/git/kvms390/linux into HEAD

KVM: s390: Misc fixes for 7.2

Fix a bunch of small issues that came up during the previous round of
fixes.

They are mostly extremely unlikely races, but they should be fixed
nonetheless.

KVM: SVM: make svm_flush_tlb_gva do a full asid flush if NPT enabled

Red Hat is seeing multiple reports of Windows memory corruptions
(and consequent BSODs) with hv-tlbflush=on, on AMD processors only.
The crashes, while extremely rare, happen even with a stock configuration,
but with Driver Verifier enabled they can be detected after approximately
200 VM hours.  In particular, Alexander Lougovski measured the following:

- on AMD Turin, 15 crashes in 3300 VM hours

- on AMD Milan, 2 crashes in 500 VM hours (there are fewer hours
  here due to the host being smaller)

- on Intel Sapphire Rapids, 0 crashes in 8000 VM hours

- on AMD Turin with full TLB flush (not exactly this patch but
  similar), no crashes in ~2 weeks of run time which should also
  be ~7000 VM hours

For Turin, the microcode version was 0x0b002162, which (assuming
this is the same issue) should not be affected by the problem listed in
https://knowledge.broadcom.com/external/article/419026/bsod-on-virtual-machines-running-on-amd.html;
on the other hand that problem should not apply to earlier processors.
AMD has not provided any information or analysis yet, and when we asked
we didn't know yet that it reproduced on Milan as well.

As to the workload, Alexander threw more or less everything at the same
time at the VM:

- a full Windows Defender scan every 30 minutes

- a disk I/O job

- a loop doing repeated mmap of system files (mostly to hope that
  it triggers some consistency check in the Windows memory manager)

- SQL Express 2022 + StressDB (1.6M rows), with the host doing queries
  (75% write/25% read) via sqlcmd

Driver Verifier is able to detect BSODs more or less at the same time as
the pages are freed.  They mostly happen in the Windows Defender filter
driver, but occasionally also in the networking stack (e.g., afd.sys)
or elsewhere in the filesystem stack (e.g., fltmgr.sys).

The flush is issued from kvm_hv_vcpu_flush_tlb(), which receives the
cross-CPU requests from the Hyper-V TLB flush hypercalls via a kfifo
and is invoked by the KVM_REQ_HV_TLB_FLUSH request.  The mechanism is
the same for both Intel and AMD, and the handler for both vendors is
a simple INVVPID(ADDR)/INVLPGA instruction.

Because the request is handled on the destination CPU, there is a question
of what happens if the VM is migrated across physical CPUs.  In that case,
the INVLPGA instruction would use a stale svm->vmcb->control.asid; but
if anything that might do an *unnecessary* flush (on an asid that's being
used for another VM) and then pre_svm_run() would force a full TLB rebuild.

So, for lack of better ideas, this patch forces a full ASID bump in
svm_flush_tlb_gva().  To avoid paying the price on Intel and also to
avoid unnecessary loops on AMD, the flush_tlb_gva op now returns whether
it did a full flush or not; kvm_hv_vcpu_flush_tlb() takes note and exits
its loops immediately.  While there is an obvious performance impact,
about half of the benefit from Hyper-V tlbflush is preserved (10% vs. 20%
on the SQL Server workload).

kvm_mmu_invalidate_addr() is the only other caller of the flush_tlb_gva op.
The change would have a performance impact on every intercepted INVLPG and,
for nested SVM, on every L1 INVLPGA.  For INVLPGA specifically, this covers
the same suspected issue but for nested hypervisors, so it is correct to
apply the workaround; for INVLPG on shadow paging, instead, the impact
would be stronger and, due to lack of data, for now the use of INVLPGA is
left in place in svm_flush_tlb_gva().

Analyzed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Analyzed-by: Alexander Lougovski <alougovs@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Merge branch 'net-sched-fix-qdisc-graft-hierarchy-validation'

Zijie Huang says:

====================
net/sched: fix qdisc graft hierarchy validation

The qdisc create-and-graft path allows users to keep attaching new classful
qdiscs under an already deep parent hierarchy. Such a hierarchy can later
be walked recursively and exhaust the kernel stack.

This series stores the qdisc hierarchy depth in struct Qdisc and checks it
when a qdisc is grafted. New child qdiscs are rejected once the parent is
already at the maximum allowed depth. It also adds tdc coverage for the
maximum allowed depth and rejection above it.
====================

Link: https://patch.msgid.link/cover.1785434373.git.milkory@outlook.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

selftests/tc-testing: add qdisc hierarchy depth tests

Add tdc coverage for the qdisc hierarchy depth limit.

The tests verify that the deepest allowed hierarchy can still be created
and that adding another child qdisc below it is rejected.

Signed-off-by: Zijie Huang <milkory@outlook.com>
Assisted-by: Codex:gpt-5.4
Signed-off-by: Ren Wei <enjou1224z@gmail.com>
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Link: https://patch.msgid.link/5cc2d26a7c8e553759cdd29a3116f843fabc25ba.1785434373.git.milkory@outlook.com
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

net/sched: reject overly deep qdisc hierarchies

Deep qdisc hierarchies can lead to excessive recursion in qdisc tree
walkers and exhaust the kernel stack. The existing loop check does not
cover the create-and-graft path, so a hierarchy can still be extended by
creating a new child qdisc below an already deep parent.

Store the hierarchy depth in struct Qdisc and update it when qdiscs are
grafted. Reject new child qdiscs once the parent is already at the maximum
allowed depth.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
Reported-by: Vega <vega@nebusec.ai>
Assisted-by: Codex:gpt-5.4
Signed-off-by: Zijie Huang <milkory@outlook.com>
Signed-off-by: Ren Wei <enjou1224z@gmail.com>
Reviewed-by: Victor Nogueira <victor@mojatatu.com>
Link: https://patch.msgid.link/1e9ab39597423fd5d13cfaaf52279b8ee3d9fc3c.1785434373.git.milkory@outlook.com
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

net: octeontx2-pf: Fix UB in shift operation

In function otx2_get_egress_burst_cfg, when the parameter `burst` is
255 and the max mantissa is 255 (0xFFULL), `burst_exp` is set to
`ilog2(255) - 1`, which equals 6.

This results in an unsigned wrap-around when calculating
`(1ULL << (*burst_exp - 7))`, since `*burst_exp - 7` becomes -1,
which makes the shift operand 0xFFFFFFFF. This value is greater than
the width of the left operand.

According to standard 6.5.7 p.3:
"The type of the result is that of the promoted left operand.
If the value of the right operand is negative or is greater than
or equal to the width of the promoted left operand, the behavior
is undefined."

Fix the off-by-one boundary condition.

Add a WARN_ON(*burst_exp < 7) before the else branch as an
explicit safeguard. This ensures that if max_mantissa ever changes
in a way that reintroduces this condition, it will be immediately
caught at runtime rather than silently triggering UB.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: e638a83f167e ("octeontx2-pf: TC_MATCHALL egress ratelimiting offload")
Signed-off-by: Sergey V. Frolov <Sergey.V.Frolov@kaspersky.com>
Cc: stable@vger.kernel.org
Reviewed-by: Ratheesh Kannoth <rkannoth@marvell.com>
Reviewed-by: Sunil Goutham <sgoutham@marvell.com>
Link: https://patch.msgid.link/20260804120446.1955448-1-Sergey.V.Frolov@kaspersky.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

net: phy: mediatek: fix TX blink masks using the RX bits

MTK_GPHY_LED_TX_BLINK_SET and MTK_2P5GPHY_LED_TX_BLINK_SET are built
from the RX blink bits instead of the TX ones, so both TX masks are
identical to their RX counterparts. The TX bits they should be using,
MTK_PHY_LED_BLINK_{10,100,1000,2500}TX, are otherwise only referenced
by the per-speed branch of mtk_phy_led_hw_ctrl_set().

A TX trigger selected without a link trigger therefore programs the RX
blink bits, and the LED blinks on received traffic. The masks are also
used to decode the blink register in mtk_phy_led_hw_ctrl_get(), which
as a result cannot tell the two triggers apart: an RX-only
configuration reads back as RX and TX, and a TX-only configuration
reads back as neither.

Fixes: 7f9c320c98db ("net: phy: mediatek: Move LED helper functions into mtk phy lib")
Cc: stable@vger.kernel.org
Signed-off-by: Ahmed Naseef <naseefkm@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260804113511.3371248-1-naseefkm@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

Merge tag 'asoc-fix-v7.2-rc6' of https://git./linux/kernel/git/broonie/sound into for-linus

ASoC: Fixes for v7.2

A moderately large set of fixes, but mostly unremarkable:

 - A series of robustness fixes for the SOF code that came from testing.
 - Fixes for user visible issues with some of the Qualcomm controls.
 - Fixes to the register default tables in Cirrus drivers which ensure
   correcy syncing on resume.  This is a wider problem which will be
   fixed with a regmap core change but I'd already applied these, the
   rest of the fixes will come in the merge window.
 - Making the existing RT645 driver user selectable so it can be used
   with more machines.
 - Quite a few new AMD laptop quirks.
 - A MAINTAINERS update for SpacemiT.

net/smc: fix TOCTOU race between smc_listen_out() and listener close

smc_listen_out() reads lsmc->sk.sk_state without the listener lock,
then acquires lock_sock_nested() only after the check passes. This
opens a window where smc_close_active() can transition the listener
to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept
queue, and release the lock, all between the lockless read and the
delayed lock acquisition:

  smc_listen_work (smc_hs_wq)          smc_close_active()
  -------------------------------      -------------------------
  release_sock(child)
  if (sk_state == SMC_LISTEN) TRUE
                                        lock_sock(listener)
                                        sk_state = SMC_CLOSED
                                        smc_close_cleanup_listen()
                                        release_sock(listener)
                                        flush_work(tcp_listen_work)
  lock_sock_nested(listener)
  smc_accept_enqueue(listener, child) /* child enqueued on dead listener */

smc_close_active() flushes only tcp_listen_work. Work items already
dispatched onto smc_hs_wq for the CLC handshake continue running
unguarded. smc_accept_enqueue() takes a sock_hold() on the child that
is never released, so the child smc_sock, its clcsock, and the
reference all leak. A remote peer that opens TCP connections while the
server calls close() can exhaust kernel memory.

Move lock_sock_nested() to before the sk_state check so that the test
and the enqueue are atomic under the listener lock.

Fixes: fd57770dd198 ("net/smc: wait for pending work before clcsock release_sock")
Reviewed-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Signed-off-by: Sidraya Jayagond <sidraya@linux.ibm.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Link: https://patch.msgid.link/20260803070701.126339-1-sidraya@linux.ibm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

net: remove WARN_ON_ONCE() from sk_mc_loop()

sk_mc_loop() can be called for sockets that are neither AF_INET
nor AF_INET6 (e.g. AF_PACKET sockets when sending packets via raw/packet
socket over virtual devices such as VRF or ipvlan).

In such cases, sk_family is not AF_INET/AF_INET6 and sk_mc_loop() falls
through the switch statement and triggers WARN_ON_ONCE(1).

Non-INET sockets do not support IP_MULTICAST_LOOP or IPV6_MULTICAST_LOOP
options, so loopback should default to true without generating a warning.

Fixes: f60e5990d9c1 ("ipv6: protect skb->sk accesses from recursive dereference inside the stack")
Reported-by: syzbot+22c3218a6fa219e47321@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a72024c.13623e66.bdc14.0019.GAE@google.com/T/#u
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260804152048.2134341-1-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>

drm/panthor: Check VMA boundaries for PMD mappings

When checking a different patch[1] sashiko AI pointed out that
panthor needs the same fix[2]:

In the ->huge_fault handler do not install a PMD huge page
mapping if the huge page exceeds the boundaries of the VMA.

[1] https://lore.kernel.org/lkml/20260622215718.1532689-1-lk@c--e.de/
[2] https://sashiko.dev/#/patchset/20260622215718.1532689-1-lk%40c--e.de

Cc: Boris Brezillon <boris.brezillon@collabora.com>
Cc: Steven Price <steven.price@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Fixes: 68cbf96b1e9b ("drm/panthor: Part ways with drm_gem_shmem_object")
Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/lkml/20260622215718.1532689-1-lk@c--e.de/
Link: https://patch.msgid.link/20260623181942.1536598-1-lk@c--e.de
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>

MAINTAINERS: add myself as a maintainer for Hisilicon Network Subsystem

I am already listed as a maintainer for the HNS3 and HIBMCGE drivers,
but not for the broader Hisilicon Network Subsystem entry, whose file
pattern covers drivers/net/ethernet/hisilicon/ (e.g. the legacy hns
driver). As a result, patches to those files are not CC'd to me.

Add myself alongside Jian Shen to help maintain these legacy Hisilicon
ethernet drivers and ensure patches in this tree are routed to me.

Signed-off-by: Jijie Shao <shaojijie@huawei.com>
Acked-by: Jian Shen <shenjian15@huawei.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260804130554.871716-1-shaojijie@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

dibs: initialise dibs->lock in dibs_dev_alloc()

dibs->lock is initialised by dibs_dev_add(), but a dibs device can
already take interrupts before that call: ism_probe() runs
ism_dev_init(), and hence request_irq(), before it calls
dibs_dev_add(). No client can have registered a dmb at that point, so
no dmb interrupt can occur, but a GID event interrupt can, and
ism_handle_irq() takes dibs->lock unconditionally on entry, before it
inspects anything else.

Initialise the lock in dibs_dev_alloc() instead, so that it is valid as
soon as a driver can publish the device to its interrupt handler.

Fixes: cc21191b584c ("dibs: Move data path to dibs layer")
Cc: stable@vger.kernel.org
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com>
Link: https://patch.msgid.link/20260730124227.167829-1-hidayath@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: prestera: validate firmware header length

prestera_fw_hdr_parse() reads the firmware header before checking
that the firmware image contains that header.

Reject images shorter than struct prestera_fw_header before decoding the
magic and version fields.

Fixes: 4c2703dfd7fabb ("net: marvell: prestera: Add PCI interface support")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Acked-by: Elad Nachman <enachman@marvell.com>
Link: https://patch.msgid.link/20260731141500.1-prestera-v2-pengpeng@iscas.ac.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

net: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp()

The commit 4f61f133f354 ("net: tap: NULL pointer derefence in
dev_parse_header_protocol when skb->dev is null") fixed a crash in
tap_get_user() by assigning skb->dev before calling tun_vnet_hdr_to_skb().
This is required because virtio_net_hdr_to_skb() may invoke
dev_parse_header_protocol(), which dereferences skb->dev. Without the
assignment, a NULL pointer dereference can occur.

However, tap_get_user_xdp() still parses the virtio-net header before
assigning skb->dev. When the vhost TX path passes an XDP buffer containing
a GSO virtio-net header but the protocol is set to zero on purpose,
tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb->dev
is still NULL, resulting in a crash.

Fix this by looking up the tap device and assigning skb->dev before calling
tun_vnet_hdr_to_skb(), matching the ordering already used in
tap_get_user(). Preserve the existing RCU read-side critical section across
dev_queue_xmit().

Fixes: 924a9bc362a5 ("net: check if protocol extracted by virtio_net_hdr_set_proto is correct")
Cc: stable@vger.kernel.org
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Link: https://patch.msgid.link/20260802224612.264563-1-dongli.zhang@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>