sl811h_probe() enables the HCD controller device as a wakeup source after
usb_add_hcd() succeeds, but sl811h_remove() removes the HCD and releases
the driver resources without disabling that wakeup source.
Disable controller wakeup after usb_remove_hcd() and before usb_put_hcd()
so the wakeup source object is detached while the controller device pointer
is still available.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: 3c9740a117 ("usb: hcd: move controller wakeup setting initialization to individual driver")
Cc: stable <stable@kernel.org>
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Link: https://patch.msgid.link/20260701121625.96815-1-mhun512@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
anx7411_i2c_probe() enables runtime PM before returning successfully, but
anx7411_i2c_remove() tears down the Type-C partner state, workqueue, dummy
I2C device, mux, switch and port without disabling runtime PM.
Use devm_pm_runtime_enable() so runtime PM is disabled automatically on
driver detach. Since devres action registration can fail, route that
failure through the existing probe unwind path.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: fe6d8a9c8e ("usb: typec: anx7411: Add Analogix PD ANX7411 support")
Cc: stable <stable@kernel.org>
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260701114006.75738-1-mhun512@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The dwc3_ulpi_setup() calls the register read and write calls with
dwc3->regs when both these calls take the dwc3 structure directly.
Chnage these two calls to fix the following sparse warning, and
possibly a nasty bug in the dwc3_ulpi_setup() code:
drivers/usb/dwc3/core.c:796:45: warning: incorrect type in argument 1 (different address spaces)
drivers/usb/dwc3/core.c:796:45: expected struct dwc3 *dwc
drivers/usb/dwc3/core.c:796:45: got void [noderef] __iomem *regs
drivers/usb/dwc3/core.c:798:40: warning: incorrect type in argument 1 (different address spaces)
drivers/usb/dwc3/core.c:798:40: expected struct dwc3 *dwc
drivers/usb/dwc3/core.c:798:40: got void [noderef] __iomem *regs
Cc: stable <stable@kernel.org>
Fixes: 9accc68b1c ("usb: dwc3: Add dwc pointer to dwc3_readl/writel")
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://patch.msgid.link/20260703162033.2847599-1-ben.dooks@codethink.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uss720_probe() registers a parport before reading the 1284 register used
to detect unsupported Belkin F5U002 adapters. If get_1284_register()
fails, the error path drops the driver private data and the USB device
reference, but leaves the parport device registered.
Leaving the port registered is more than a private allocation leak:
parport_register_port() has already reserved a parport number and
registered the parport bus device, while pp->private_data still points at
the private data that the common error path is about to release.
Undo the pre-announce registration in the get_1284_register() failure
branch before jumping to the common private-data cleanup path. Clear
priv->pp first, matching the disconnect path and avoiding a stale pointer
in the private data.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: 3295f1b866 ("usb: misc: uss720: check for incompatible versions of the Belkin F5U002")
Cc: stable <stable@kernel.org>
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Alex Henrie <alexhenrie24@gmail.com>
Link: https://patch.msgid.link/20260706151049.63470-1-mhun512@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a length check for the rndis header in rndis_rm_hdr, to ensure that
MessageType, MessageLength, DataOffset, and DataLength fields are
present before they are accessed.
Assisted-by: gkh_clanker_2000
Cc: stable <stable@kernel.org>
Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
Link: https://patch.msgid.link/20260708-usb-gadget-rndis-v1-2-e77e026dcc6a@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add variable representations for BufLength and BufOffset in
rndis_query_response(), and perform a length check on them.
This is identical to how rndis_set_response() handles these parameters.
Assisted-by: gkh_clanker_2000
Cc: stable <stable@kernel.org>
Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
Link: https://patch.msgid.link/20260708-usb-gadget-rndis-v1-1-e77e026dcc6a@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
EHCI and FOTG210 isochronous submits build an ehci_iso_sched before
linking the URB to the endpoint queue, and keep the staged schedule in
urb->hcpriv until iso_stream_schedule() and the link helpers consume it.
If the controller is no longer accessible, or usb_hcd_link_urb_to_ep()
fails, submit jumps to done_not_linked before that handoff happens and
leaks the staged schedule still attached to urb->hcpriv.
Free the staged schedule from done_not_linked when submit fails before
the URB is linked and clear urb->hcpriv after the free.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still
present in v7.1.1.
An x86_64 allyesconfig build showed no new warnings. As we do not have an
EHCI host controller with a USB isochronous device to test with, no
runtime testing was able to be performed.
Fixes: 8de9840265 ("[PATCH] USB: Fix USB suspend/resume crasher (#2)")
Fixes: e9df41c5c5 ("USB: make HCDs responsible for managing endpoint queues")
Fixes: 7d50195f6c ("usb: host: Faraday fotg210-hcd driver")
Cc: stable <stable@kernel.org>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260630071419.349161-1-dawei.feng@seu.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit 1892bf9067 ("USB: usb-storage: Fix use of bitfields for
hardware data in ene_ub6250.c") converted the media status fields from
bitfields to bit masks.
The original ene_transport() test called ene_init() only when neither
media type was ready:
!(sd_ready || ms_ready)
The converted test became:
!sd_ready || ms_ready
This is not equivalent. Restore the original semantics by testing that
both ready bits are clear before calling ene_init().
Fixes: 1892bf9067 ("USB: usb-storage: Fix use of bitfields for hardware data in ene_ub6250.c")
Cc: stable <stable@kernel.org>
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/F42641386E32404F+20260626070607.4119527-1-raoxu@uniontech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
printer_open() returns -EBUSY when the character device is already
open, but it increments dev->kref regardless of the return value. VFS
does not call ->release() for a failed open, so every rejected second
open permanently leaks one reference.
Move kref_get() into the successful-open branch.
Fixes: e8d5f92b8d ("usb: gadget: function: printer: fix use-after-free in __lock_acquire")
Cc: stable <stable@kernel.org>
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Link: https://patch.msgid.link/80295742B820DA9B+20260626064617.4090626-1-raoxu@uniontech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vep_alloc_request() wasn't initializing vrequest->udc, so cancellations
on the FunctionFS AIO path were arriving in vep_dequeue without a valid
UDC reference.
Since vrequest->udc is never actually properly used anywhere, we opt to
remove it, and update vep_dequeue to obtain a reference to the udc with
ep_to_vudc(), consistent with the other vep_ ops.
AFAICT this bug has existed for ~10 years. Seems that nobody has really
stressed the FunctionFS AIO path on usbip's vudc.
I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints
via AIO. Before the fix, running `usbip attach` from the host would
cause the guest to oops with the following backtrace:
Call trace:
vep_dequeue+0x1c/0xe4 (P)
usb_ep_dequeue+0x14/0x20
ffs_aio_cancel+0x24/0x34
__arm64_sys_io_cancel+0xb0/0x124
do_el0_svc+0x68/0x100
el0_svc+0x18/0x5c
el0t_64_sync_handler+0x98/0xdc
el0t_64_sync+0x154/0x158
Assisted-by: opencode:openai/gpt-5.5
Cc: stable <stable@kernel.org>
Fixes: b6a0ca1118 ("usbip: vudc: Add UDC specific ops")
Reviewed-by: Igor Kotrasinski <i.kotrasinsk@samsung.com>
Signed-off-by: Sam Day <me@samcday.com>
Link: https://patch.msgid.link/20260626-usbip-vudc-deque-fix-v3-1-98c2dc4d6a48@samcday.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB devices running at SuperSpeedPlus report "10000" or "20000" in
their sysfs speed attribute. usbip currently maps only "5000" to
USB_SPEED_SUPER, so a SuperSpeedPlus device is imported as
USB_SPEED_UNKNOWN.
The attach request is then rejected by vhci_hcd:
vhci_hcd: Failed attach request for unsupported USB speed: UNKNOWN
Map the SuperSpeedPlus sysfs speed values to USB_SPEED_SUPER_PLUS, use
the SuperSpeed VHCI hub for SuperSpeedPlus devices, and recognize the
gadget current_speed string used by the kernel.
Fixes: b2316645ca ("usb: show speed "10000" in sysfs for USB 3.1 SuperSpeedPlus devices")
Cc: stable <stable@kernel.org>
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://patch.msgid.link/00C828F338E43447+20260617020613.199086-1-chenyichong@uniontech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In the UCSI Specification Revision 3.1 RC1, bits 32-63 of the SET_NEW_CAM
command hold the 32-bit Alternate Mode Specific (AMSpecific) field.
For DisplayPort Alternate Mode, this field must contain the full
32-bit DisplayPort configuration VDO payload that the OPM wants the
connector to operate in, rather than just the pin assignment value.
This AMSpecific value follows the DisplayPort Configurations defined
in the DisplayPort Alt Mode on USB Type-C Specification v2.1a,
Table 5-13: SOP DisplayPort Configurations.
Fixes: af8622f6a5 ("usb: typec: ucsi: Support for DisplayPort alt mode")
Cc: stable <stable@kernel.org>
Signed-off-by: Madhu M <madhu.m@intel.com>
Reviewed-by: Jameson Thies <jthies@google.com>
Reviewed-by: Andrei Kuchynski <akuchynski@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260619153311.3526083-1-madhu.m@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ravi Hothi <ravi.hothi@oss.qualcomm.com> says:
This series adds audio support for the Qualcomm Eliza SoC. Eliza uses
the same LPASS macro codec hardware as SM8550, so the existing SM8550
fallback compatible is reused for all four macro codecs (RX, TX, VA,
WSA). The sound card is compatible with the SM8450 generation machine
driver.
Patch 1 documents the Eliza LPASS macro codec compatibles in the
dt-bindings for RX, TX, VA and WSA macros.
Patch 2 documents the Eliza sound card compatible.
Patch 3 adds the Eliza sound card entry to the machine driver.
Link: https://patch.msgid.link/20260703073434.2589657-1-ravi.hothi@oss.qualcomm.com
Add bindings for Eliza sound card, which is compatible with
the existing SM8450.
Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260703073434.2589657-3-ravi.hothi@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add bindings for Qualcomm Eliza LPASS RX, TX, VA and WSA macro codecs,
which are compatible with the existing SM8550 generation.
Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Link: https://patch.msgid.link/20260703073434.2589657-2-ravi.hothi@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The HP Laptop 15-fd0xxx uses GPIO bit 0 to control the mic mute LED,
but currently the quirk only enables the speaker mute LED (via coef
bit). Switch to the existing ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO
fixup which additionally registers a GPIO-based mic mute LED, mapping
to the same verbs (SET_GPIO_DATA/SET_GPIO_DIRECTION bit 0) that the
platform firmware uses.
Signed-off-by: Kshamendra Kumar Mishra <kshamendrakumarmishra@gmail.com>
Link: https://patch.msgid.link/DJSOWKFBTJH8.2Z7EPWX514QXM@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The mute LED on HP Victus 15-fa0xxx (board ID 8A50) uses ALC245 but
requires a quirk to work. This patch enables the existing
ALC245_FIXUP_HP_MUTE_LED_COEFBIT quirk for the device.
Tested on my HP Victus 15-fa0xxx. The LED behaviour works as intended.
Signed-off-by: Rohit Sinha <rohitsinha12043@gmail.com>
Link: https://patch.msgid.link/20260706211834.384022-1-rohitsinha12043@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The device with USB ID 040b:0897 (Weltrend Semiconductor chipset,
sold rebranded as the Redragon H510-PRO Wireless headset, reporting
"XiiSound Technology Corporation" in its USB string descriptors)
reports a constant value on GET_CUR for its PCM Playback Volume
control while still supporting an actually tunable volume. This
trips the sticky-value detection in check_sticky_volume_control(),
which disables the mixer control entirely:
usb 1-4: 5:0: sticky mixer values (0/100/1 => 80), disabling
As a result, the device boots with playback volume effectively muted
and provides no way to raise it through the normal ALSA/PipeWire
mixer path.
Apply QUIRK_FLAG_MIXER_GET_CUR_BROKEN so the sticky check marks the
control as get_cur_broken and relies on the cached value instead of
disabling the mixer control outright.
Tested by backporting this quirk flag and the supporting
get_cur_broken logic onto a Linux 7.1.2-zen kernel build that does
not yet carry it, and confirming that after applying the flag the
kernel log changes from
usb 1-4: 5:0: sticky mixer values (0/100/1 => 80), disabling
to
usb 1-4: 5:0: broken mixer GET_CUR (0/100/1 => 80)
with the control usable via the driver's cached value afterward.
Signed-off-by: Agustin Luzardo <agustinluzardo09@gmail.com>
Link: https://patch.msgid.link/20260705184227.113588-1-agustinluzardo09@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Branch Sampling (BRS) and Last Branch Record (LBR) are mutually
exclusive hardware features, and users of both are tracked via
cpuc->lbr_users.
When SVM is toggled on a CPU, the host perf events are reprogrammed to
update the HostOnly filter bit (set when virtualization is enabled,
cleared when it is disabled). On PerfMonV2-capable processors, this
reprogramming is performed by calling amd_pmu_enable_all() to rewrite
the event selectors. However, amd_pmu_enable_all() also calls
amd_brs_enable_all(), which enables BRS whenever cpuc->lbr_users > 0.
Having active LBR events satisfies this gating on processors that have
LBR but not BRS. The kernel then tries to set the BRS enable bit in
DebugExtnCfg (MSR 0xc000010f). Since that bit is deprecated on such
hardware, the write results in a #GP:
Call Trace:
<IRQ>
amd_pmu_enable_all+0x1d/0x90
amd_pmu_disable_virt+0x62/0xb0
kvm_arch_disable_virtualization_cpu+0xa/0x40 [kvm]
hardware_disable_nolock+0x1a/0x30 [kvm]
__flush_smp_call_function_queue+0x9b/0x410
__sysvec_call_function+0x18/0xc0
sysvec_call_function+0x69/0x90
</IRQ>
<TASK>
asm_sysvec_call_function+0x16/0x20
RIP: 0010:cpuidle_enter_state+0xc4/0x450
? cpuidle_enter_state+0xb7/0x450
cpuidle_enter+0x29/0x40
cpuidle_idle_call+0xf5/0x160
do_idle+0x7b/0xe0
cpu_startup_entry+0x26/0x30
start_secondary+0x115/0x140
secondary_startup_64_no_verify+0x194/0x19b
</TASK>
Fix this by ensuring that BRS is not enabled from the event selector
reprogramming path even when cpuc->lbr_users > 0.
Fixes: bae19fdd7e ("perf/x86/amd/core: Fix reloading events for SVM")
Signed-off-by: Sandipan Das <sandipan.das@amd.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/702fa204d574b03d14e3664c7d4b201db048bbfd.1783506528.git.sandipan.das@amd.com
Currently, configuring a VF MAC address via the PF (e.g., 'ip link
set <pf> vf 0 mac <mac>') blindly attempts to install a DMAC-based
hardware filter. However, the hardware parser profile might not
support DMAC extraction.
Check if the hardware parsing profile supports DMAC extraction
before adding the filter. Additionally, emit a warning message
to inform the operator if the MAC filter installation fails due
to missing DMAC extraction support. Update config->mac only
after hardware programming succeeds in otx2_set_vf_mac().
Fixes: f0c2982aaf ("octeontx2-pf: Add support for SR-IOV management functions")
Signed-off-by: Suman Ghosh <sumang@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Link: https://patch.msgid.link/20260702033451.2969880-1-nshettyj@marvell.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
CAKE accepts signed overhead values and stores them in an s16, but the
adjusted packet length calculation uses unsigned arithmetic. A negative
effective length can therefore wrap to a large value.
Such configurations make rate accounting depend on integer wraparound
rather than on the packet size userspace intended to model. A static
netlink lower bound is not enough because packets reaching CAKE can be
smaller than any reasonable manual-overhead allowance.
Fold the signed overhead adjustment into the existing datapath MPU clamp
so negative adjusted lengths are clamped before link-layer framing
adjustments.
Fixes: a729b7f0bd ("sch_cake: Add overhead compensation support to the rate shaper")
Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260702000758.297407.e5c888d9d99d.cake-overhead-underflow@trailofbits.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
rtla started to only link parts of the tools library. It now misses the
ctype information used by all the related string operations. Just add
another single file to make it build again.
Signed-off-by: Bastian Blank <waldi@debian.org>
Fixes: 48209d763c ("rtla: Add libsubcmd dependency")
Link: https://lore.kernel.org/r/ako2S4mzIqWwYuas@steamhammer.waldi.eu.org
[ remove duplicated spaces in commit message ]
Signed-off-by: Tomas Glozar <tglozar@redhat.com>
REGMAP_MMIO is a hidden (non-user-visible) tristate symbol. Using
depends on it is incorrect because there is no way for the user to
enable it directly. Change to select, which is the convention used
by every other driver in the tree that needs REGMAP_MMIO.
Fixes: 8057cbb833 ("net: mdio: mscc-miim: Add depend of REGMAP_MMIO on MDIO_MSCC_MIIM")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260702032653.1580616-1-rosenp@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Commit c7f92042d3 ("selftests: gpio: Add gpio-cdev-uaf tests") added
the gpio-cdev-uaf binary to TEST_GEN_PROGS_EXTENDED but never added it
to .gitignore. Building it with:
make -C tools/testing/selftests/gpio TARGETS=gpio
leaves gpio-cdev-uaf as an untracked file.
Fixes: c7f92042d3 ("selftests: gpio: Add gpio-cdev-uaf tests")
Signed-off-by: Cihan Karadag <cihan.cihan@gmail.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260707235707.1349969-1-cihan.cihan@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
RISCV_HWPROBE_EXT_ZICFISS and RISCV_HWPROBE_EXT_ZICFILP are defined in
the hwprobe uAPI but are not documented in
Documentation/arch/riscv/hwprobe.rst. Add documentation for them.
Link: 302a2d45c2
Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-3-2c61f94a695a@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
A handful of vendor-extension entries indent continuation lines with a
tab character, while the rest of hwprobe.rst uses spaces. In addition,
many list items align their continuation lines under the 'm' of
':c:macro:' (column 7) rather than under the item text (column 4), so
the file mixes several indentation styles.
Replace the tabs with spaces and align every list item's continuation
lines under the item text, giving the whole file one consistent style.
Whitespace-only change, no functional change.
[Guodong: extend from tabs->spaces to normalizing all continuation-line
indentation across the file]
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-2-2c61f94a695a@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
The multi-letter extension enum is documented as being sorted
alphanumerically (see the "multi-letter extensions, sorted
alphanumerically" comment), but several Z entries have drifted out of
order.
Reorder the affected entries so the multi-letter Z list is sorted
alphanumerically again.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-1-2c61f94a695a@gmail.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
If the tail data can be inlined into the inode meta block, it should
be converted into a regular tail pcluster.
In principle, it should be converted into an uncompressed pcluster if
there is not enough gain to use compression (map->m_llen < map->m_plen);
but since there are various shipped images, relax the condition for
ztailpacking tail pcluster fallback instead of reporting corruption
incorrectly.
Reported-and-tested-by: Yifan Zhao <zhaoyifan28@huawei.com>
Reported-by: Alberto Salvia Novella <es20490446e@gmail.com>
Closes: https://github.com/erofs/erofs-utils/issues/51
Fixes: a5242d37c8 ("erofs: error out obviously illegal extents in advance")
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Commit 91842ed844 ("ata: libata-core: Set capacity to zero for a
security locked drive") introduced setting the device capacity (n_sectors)
to zero in ata_dev_configure() if the drive is security locked.
However, during runtime revalidation, ata_dev_revalidate() compares the
new capacity (now 0) with the old capacity (>0) and detects a mismatch.
Since it does not consider the locked status, it returns -ENODEV.
This revalidation failure can occur when doing a reset of the PHY (e.g.
hard reset) for a controller that has I/Os in flight. The timed out
I/Os trigger the SCSI Error Handling (EH) path, which in turn invokes
libata device revalidation. If the drive is locked at runtime (e.g.
it lost power during reset and relocked), revalidation sees the capacity
transition to zero and fails, eventually disabling the device.
Fix this by allowing the capacity transition to zero in
ata_dev_revalidate() if the drive is reported as security locked by
ata_id_is_locked().
Fixes: 91842ed844 ("ata: libata-core: Set capacity to zero for a security locked drive")
Cc: stable@vger.kernel.org
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Terrence Adams <tadamsjr@google.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Skip HPA resize in ata_hpa_resize() if the drive is security locked.
If the drive is locked, the command to read the native max address
fails with -EACCES, which currently causes the sticky quirk
ATA_QUIRK_BROKEN_HPA to be set on the device.
Setting this sticky quirk causes subsequent revalidations (after the
drive is unlocked) to bypass HPA checks, preventing the unlocked drive
from exposing its full native capacity without a reboot or device removal.
Cc: stable@vger.kernel.org
Signed-off-by: Terrence Adams <tadamsjr@google.com>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Closing a BO handle clears abo->client, while the underlying GEM object
may remain alive due to internal kernel references. As a result, code
executed after the BO handle is closed may dereference a NULL abo->client
pointer.
Remove accesses to abo->client from code paths that may execute after the
BO handle has been closed.
Fixes: d76856beb4 ("accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260707201556.562191-1-lizhi.hou@amd.com
The return value of init_srcu_struct() is currently ignored. If
initialization fails, subsequent use of hwctx_srcu may result in invalid
memory accesses.
Check the return value of init_srcu_struct() and propagate the error to
the caller.
Fixes: aac243092b ("accel/amdxdna: Add command execution")
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260707172323.539721-1-lizhi.hou@amd.com
drmm_mutex_init() may fail and return an error. Check the return value
and abort initialization if mutex creation fails.
Fixes: 8c9ff1b181 ("accel/amdxdna: Add a new driver for AMD AI Engine")
Reviewed-by: Max Zhen <max.zhen@amd.com>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260707172307.539676-1-lizhi.hou@amd.com
Calling hid_hw_stop() does not stop the device IO.
This results in a race condition between hid_input_report() and the point
immediately following the execution of hid_device_io_start() within
the driver probe function. If the probe operation fails after "io start"
has been initiated, this race condition will result in a UAF vulnerability.
Fix the problem by calling hid_device_io_stop() before calling
hid_hw_stop().
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: f3b4b146eb ("hwmon: Add driver for NZXT Kraken X and Z series AIO CPU coolers")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Calling hid_hw_stop() does not stop the device IO.
This results in a race condition between hid_input_report() and the point
immediately following the execution of hid_device_io_start() within
the driver probe function. If the probe operation fails after "io start"
has been initiated, this race condition will result in a UAF vulnerability.
Fix the problem by calling hid_device_io_stop() before calling
hid_hw_stop().
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: 53e68c20ae ("hwmon: add driver for NZXT RGB&Fan Controller/Smart Device v2")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Calling hid_hw_stop() does not stop the device IO.
This results in a race condition between hid_input_report() and the point
immediately following the execution of hid_device_io_start() within
the driver probe function. If the probe operation fails after "io start"
has been initiated, this race condition will result in a UAF vulnerability.
Fix the problem by calling hid_device_io_stop() before calling
hid_hw_stop().
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: 42ac68e3d4 ("hwmon: Add driver for Gigabyte AORUS Waterforce AIO coolers")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Calling hid_hw_stop() does not stop the device IO.
This results in a race condition between hid_input_report() and the point
immediately following the execution of hid_device_io_start() within
the driver probe function. If the probe operation fails after "io start"
has been initiated, this race condition will result in a UAF vulnerability.
Fix the problem by calling hid_device_io_stop() before calling
hid_hw_stop().
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: 40c3a44542 ("hwmon: add Corsair Commander Pro driver")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
hid_hw_stop() does not stop the device IO.
This results in a race condition between hid_input_report() and the point
immediately following the execution of hid_device_io_start() within
corsairpsu_probe(). If the probe operation fails after "io start" has
been initiated, this race condition will result in a uaf vulnerability
[1].
CPU0 CPU1
==== ====
corsairpsu_probe()
hid_device_io_start()
... unlock driver_input_lock
hid_hw_stop()
kfree(hidraw) __hid_input_report()
... acquire driver_input_lock
hid_report_raw_event()
hidraw_report_event()
... access hidraw's list_lock // trigger uaf
Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to
be executed, the io_started flag is first cleared while holding the
driver_input_lock to prevent potential race conditions involving input
reports.
[1]
BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56
Call Trace:
hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577
hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076
__hid_input_report drivers/hid/hid-core.c:2152 [inline]
hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174
hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286
__usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657
dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005
Allocated by task 10:
hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606
hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277
hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387
corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782
Freed by task 10:
hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662
hid_disconnect drivers/hid/hid-core.c:2362 [inline]
hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407
corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826
Fix the problem by calling hid_device_io_stop() before calling
hid_hw_stop().
Fixes: d115b51e0e ("hwmon: add Corsair PSU HID controller driver")
Reported-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9eebf5f6544c5e873858
Tested-by: syzbot+9eebf5f6544c5e873858@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
Link: https://lore.kernel.org/r/tencent_BB7C33EB9EA41B7B4B5F1B8B25C0BA13BB08@qq.com
[groeck: Updated subject and description;
call hid_device_io_stop() only if IO has been started]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The ptrace_v_not_enabled test expects the child to reach its ebreak
before it has used the vector extension. That is not guaranteed when
using fork(), because libc may run child atfork handlers before
returning to the test code. In those cases PTRACE_GETREGSET for
NT_RISCV_VECTOR then succeeds instead of returning ENODATA for
inactive vector state.
Use the raw clone syscall with SIGCHLD to keep fork-like semantics
while bypassing libc's fork wrapper and atfork handler chain.
Cc: Andy Chiu <tchiu@tenstorrent.com>
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
Link: https://patch.msgid.link/20260707153827.175245-1-andrew.jones@oss.qualcomm.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
The condition 'irq_flag | wake_irq_flag' uses bitwise OR to combine two
integer flags that are used as booleans. Replace with logical OR '||' to
correctly express the intended boolean check.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Fixes: 7f91f012c1 ("ASoC: amd: ps: fix for irq handler return status")
Link: https://patch.msgid.link/20260707060130.2514138-4-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver handles ACP6.3/7.0/7.1/7.2 platforms but the region was
claimed with the stale name "AMD ACP6.2 audio" left over from the
original ACP6.2 driver. Correct it to "AMD ACP6.3 audio".
Fixes: 95e43a170b ("ASoC: amd: add Pink Sardine ACP PCI driver")
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260707060130.2514138-3-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
BIOS/firmware may re-enable MSI in PCI config space during system
level resume even though this driver only uses legacy INTx interrupts.
If MSI is left enabled with stale address/data registers, the device
will write interrupts to a bogus address causing IOMMU IO_PAGE_FAULT
and interrupt delivery failure.
Clear the MSI Enable bit before reinitializing the ACP hardware on
system level resume.
Fixes: 4916283880 ("ASoC: amd: ps: add callback functions for acp pci driver pm ops")
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20260707060130.2514138-2-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The io.stat section says that enabling the io.latency controller exposes
the depth, avg_lat and win stats in addition to the normal ones. However,
these io.latency-specific stats are debug stats and are only emitted when
the blkcg_debug_stats module parameter is enabled, which is disabled by
default.
Make this explicit so users do not expect these fields to appear in
io.stat by default, and qualify the usage text that suggests using
avg_lat to pick an io.latency target.
Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
The v1 RDMA controller documentation only describes rdma.max and
rdma.current, but the controller exposes three more files -- rdma.peak,
rdma.events and rdma.events.local -- which are already documented for
v2. Mirror the v2 wording so the v1 documentation matches the files
actually visible on a v1 mount.
Co-developed-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
The Miscellaneous controller documentation states it "provides 3 interface
files", but misc_cg_files[] actually registers six (max, current, peak,
capacity, events, events.local). Drop the stale count and let the file
list that follows speak for itself.
Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
The "Where to Look" and "ABI Instability" sections state that the ops
table is defined in include/linux/sched/ext.h. However, struct
sched_ext_ops is actually defined in kernel/sched/ext/internal.h, along
with the SCX_OPS_* flags; include/linux/sched/ext.h holds the core data
structures (struct sched_ext_entity, struct scx_dispatch_q, ...) and the
DSQ constants. Point the ops table references to the correct header.
Signed-off-by: Liang Luo <luoliang@kylinos.cn>
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
