| Age | Commit message (Collapse) | Author |
|
Add DRM_FORMAT_HOST_ARGB8888 to the list of supported formats for
virtio-gpu primary planes. Without this, glmark2-drm fails at
startup because it selects ARGB visual configs by default, which
don't match the XRGB-only plane capabilities. This causes
drmModeSetCrtc to fail with EINVAL.
The virtio_gpu_translate_format() function already handles
ARGB8888 translation to VIRTIO_GPU_FORMAT_B8G8R8A8_UNORM,
so this just exposes the existing capability to userspace.
Signed-off-by: Dorinda Bassey <dbassey@redhat.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patch.msgid.link/20260930132707.500748-1-dbassey@redhat.com
|
|
The cursor blending mode was added twice because the same change was
applied by accident from different patches. Revert the second patch.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/dri-devel/ce84d3d2-e78b-4939-aecf-9ef7267bd42a@samsung.com/
Fixes: 6947b78df4d2 ("drm/virtio: Add pixel blend mode property to cursor plane")
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://patch.msgid.link/20261007222244.295186-1-dmitry.osipenko@collabora.com
|
|
br_netfilter has way too many bugs, schedule for removal and disable
the feature in user namespaces.
In particular, we get more and more gadgets to have bridge ports escape
rcu_read_lock() protection, then underlying device gets reconfigured
(macvlan or something else), then reinject into network stack causes
crash because net_device is assumed to still have bridge rx data
associated with it.
br_netfilter is an ancient kludge that emulates ip stack from within the
bridge and then calls into ipv4/ipv6 netfilter hooks to have bridged
frames processed via iptables/ip6tables by setting the 'call-iptables'
sysctls to 1. It is NOT related to ebtables or nftables 'bridge' family
at all.
Note that in addition to call-iptables, sysctls, the bridge also exposes
call-iptables per bridge device via netlink and sysfs
('BROPT_NF_CALL_IPTABLES') toggles.
Those are still available, the brnet structure is scoped to br_netfilter;
exposing it bridge-wide is a big no-no.
This relies on brnf_device_event() no longer registering the base
br_netfilter hooks, so while BROPT_NF_CALL_IPTABLES can be set, it
has no effect because the hooks that evaluate this feature bit
are never registered.
brnf_init_net can no longer depend on CONFIG_SYSCTL, else such builds
never disable support in user namespaces.
Cc: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
The LCPA area is mapped with devm_ioremap(), but lcpa_base and the
per-channel lcpa pointer lack __iomem annotations. This loses the I/O
address space and makes sparse warn when d40_current_addr() assigns
LCPA register addresses to its __iomem pointers.
Annotate both pointers and the LCPA argument of d40_log_lli_lcpa_write()
to preserve the I/O address space from the mapping to the register
accessors. This also fixes the existing LCPA read and write warnings
without changing the generated code.
Fixes: c80edceff29e ("dmaengine: ste_dma40: Fix cyclic transfer residue")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202610090216.pjMRxhRL-lkp@intel.com/
Assisted-by: LLM
Signed-off-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20261010-dma40-smatch-fix-v1-1-26ca10043957@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Sashiko pointed in [1] about the cookie completion order. It is good to
Document that for ensuring that dma buffer is flushed and no stale data
is seeing by consumer, we need to make sure such action is taken before
drivers invoke dma cookie completion.
[1]: https://lore.kernel.org/r/20260917072507.5BDB61F000FF@smtp.kernel.org
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://patch.msgid.link/20261009093745.539924-1-vkoul@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux
Pull Landlock fix from Mickaël Salaün:
"This fixes a Clang bug by removing an annotation, which was introduced
mostly for documentation"
* tag 'landlock-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mic/linux:
landlock: Drop __counted_by from landlock_domain.handled_masks
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small collection of driver specific fixes, plus a new device ID in
the DesignWare device tree binding.
One of the sg2044 fixes which enforces clock limits properly is more
critical than average since getting them wrong might lead to data
corruption"
* tag 'spi-fix-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: dt-bindings: snps,dw-apb-ssi: Add Synaptics sl2610 spi
spi: sg2044-nor: Honor SPI clock limits
spi: sg2044-nor: Return transfer errors
spi: cadence-qspi: Fix status polling with octal DTR chips
spi: spi-nxp-fspi: exit stop mode before waiting for DLL lock
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"There's a couple of core fixes here: there were a couple of issues
with of_regulator_bulk_get_all() not behaving consistently with the
other bulk regulator APIs which caused memory leaks and error handling
issues in users.
We also have a couple of fairly standard driver specific fixes"
* tag 'regulator-fix-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: ltc3676: don't read the write-only HRST and CLIRQ registers
regulator: of: state who owns the array from of_regulator_bulk_get_all()
regulator: of: fill in supply names in of_regulator_bulk_get_all()
regulator: tps6594-regulator: Fix n_linear_ranges for TPS65224 BUCK2-4
|
|
Add a MAINTAINERS entry for the Rust `bug` module, which currently
provides the `warn_on!` macro.
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Link: https://patch.msgid.link/20261004124211.381401-1-tomo@flapping.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
https://github.com/Rust-for-Linux/linux into rust-next
Pull timekeeping updates from Andreas Hindborg:
- Warn and assert when passing out-of-range inputs to 'fsleep' and
'udelay'.
- Rename 'ClockSource' to 'ClockId' to better align with naming
conventions in C kernel.
- Make 'CONFIG_HZ' value available as 'bindings::HZ'.
- Add a conversion method to convert 'Delta' to 'jiffies' for use in
timeout arguments.
- Add implementation detail documentation for 'HrTimer'.
* tag 'rust-timekeeping-for-v7.4-rc1' of https://github.com/Rust-for-Linux/linux:
rust: hrtimer: document handle based design rationale
rust: time: add Delta::to_jiffies_timeout() for timeout conversion
rust: bindings: set HZ to CONFIG_HZ
rust: time: rename ClockSource trait to ClockId
rust: time: warn and assert out-of-range input in fsleep() and udelay()
|
|
rust-next
Pull alloc updates from Danilo Krummrich:
- Add Alice Ryhl as co-maintainer for Rust [ALLOC]
- Allow different error types in KBox::pin_slice(), enabling use of
infallible initializers
- Add NumaNode::id() accessor to retrieve the underlying NUMA node
identifier
* tag 'alloc-7.4-rc1' of https://github.com/Rust-for-Linux/linux:
rust: alloc: add `NumaNode::id()` accessor
rust: alloc: allow different error types in `KBox::pin_slice`
MAINTAINERS: add Alice Ryhl as co-maintainer for Rust [ALLOC]
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Driver (and tape media changer) only fixes. Three of the fixes are
about the same size, (ch, ufs decouble CQ and ufs avoid unsafe MMIO)
but the unsafe MMIO is the least obvious logic change"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: ufs: core: Decouple CQ sweep from request iterator in MCQ
scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock()
scsi: ch: Do not keep references to data transfer element devices
scsi: ufs: mediatek: Handle mPHY power-on failures
scsi: qedi: Initialize callback state before registration
scsi: ufs: core: Hold a clock reference across the probe
|
|
When an MHI endpoint device runs Linux, there is no firmware to implement
the LOOPBACK channel echo that real modem firmware provides. Without an
endpoint-side driver, the host loopback test has no software echo partner
and cannot exercise the full end-to-end MHI data path.
Add an endpoint-side loopback driver that binds to the LOOPBACK channel and
echoes received data back to the host. An ordered workqueue is used for
asynchronous processing to preserve packet ordering. Together with the
host-side loopback driver, this enables complete MHI data path validation
for Linux-based endpoint devices.
Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com>
Link: https://patch.msgid.link/20261005-lb-v7-3-36a268b6386f@oss.qualcomm.com
[mani: fixed checkpatch warnings]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
Some MHI endpoint clients do not use socket buffers and need a way to queue
raw buffers for DL transfers. Add mhi_ep_queue_buf() to support this use
case.
Refactor mhi_ep_queue_skb() to delegate to a new internal mhi_ep_queue()
helper shared by both APIs, and rename mhi_ep_skb_completion() to
mhi_ep_buf_completion() to reflect its broader use.
Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com>
Link: https://patch.msgid.link/20261005-lb-v7-2-36a268b6386f@oss.qualcomm.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
The MHI specification defines a LOOPBACK channel. The endpoint firmware
echoes back whatever the host sends on this channel. Without a host-side
driver, there is no way to exercise this channel to validate MHI data path
integrity between host and endpoint.
Add a host-side loopback driver that binds to the LOOPBACK channel and
expose a sysfs interface for data path testing. The sysfs interface allows
users to configure TRE buffer size and count, trigger a loopback test, and
read the result.
The new sysfs ABI is documented under Documentation/ABI/testing/, not
stable/, since this is a new interface without established API
guarantees yet. It is unrelated to the existing stable MHI sysfs ABI
documented in Documentation/ABI/stable/sysfs-bus-mhi, despite both
being covered by the same MAINTAINERS entry.
Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Signed-off-by: Sumit Kumar <sumit.kumar@oss.qualcomm.com>
Link: https://patch.msgid.link/20261005-lb-v7-1-36a268b6386f@oss.qualcomm.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
The Quectel RM500Q-AE (SDX55) enumerates with the Qualcomm SDX55 ID
17cb:0306 and subsystem ID 17cb:5002, so it binds to the generic
qcom-sdx55m entry. That configuration expects QMI on channels 14/15,
which this module's firmware does not answer: the modem probes, but
every QMI request over the control channel times out and no data
session can be set up. Users of this module have had to fall back to
Quectel's out-of-tree driver.
Like the other Quectel modules, the RM500Q-AE provides MBIM control on
channels 12/13 and data on IP_HW0_MBIM. Add an entry for its subsystem
ID, which no other entry in the table uses, that reuses the Quectel
em1xx channel configuration. The EDL image name is the one the generic
SDX55 entry already uses.
Tested on a Xunison Exigo D50 5G (IPQ5018) with modem firmware
RM500QAEAAR13A03M4G: the modem probes as quectel-rm500q and exposes
wwan0mbim0, wwan0at0 and an MBIM network device. A data session set up
with mbimcli and with OpenWrt's umbim reached 160-180 Mbps, the
limit of the cell.
Assisted-by: LLM
Signed-off-by: Steve Meek <stevemeek82@gmail.com>
Link: https://patch.msgid.link/20261011-mhi-next-v1-1-13a738637ff0@gmail.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- NVMe fixes via Keith:
- Fix swapped ZRASF zone state values for full and read only
- nvme-multipath revalidate head zones after unfreezing the head
queue
- Revert "nvme: do not reset controllers in NVME_CTRL_NEW state",
which broke things
- nvmet fixes for invalid NSIDs on feature 82h and using the local
P2P device on metadata allocation failure
- zloop: zero out only the unread tail of a short read
* tag 'block-7.3-20261010' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
Revert "nvme: do not reset controllers in NVME_CTRL_NEW state"
zloop: zero out only the unread tail of short reads
nvmet: use the local P2P device on metadata allocation failure
nvme-multipath: revalidate head zones after unfreezing the head queue
nvme: fix swapped ZRASF zone state values for full and read only
nvmet: return Invalid Field for invalid NSIDs feature 82h
|
|
With clang 22 and CONFIG_FORTIFY_SOURCE, the second
landlock_restrict_self() call hits a bogus fortify report in
inherit_ruleset():
memcpy: detected buffer overflow: 4 byte write of buffer size 0
Call Trace:
__fortify_panic
landlock_merge_ruleset
__se_sys_landlock_restrict_self
handled_masks[] lives in an anonymous struct inside the anonymous union
that overlays work_free. For such a flexible array, clang computes the
address of the __counted_by counter as the start of the array instead of
&num_layers. The bound is then read from handled_masks[0], i.e. from
the first layer's access masks, which is not a count. The same layout
crashes clang itself in a standalone test.
The annotation was added as documentation, so drop it rather than
restructure the union. Keep the information in the member comment.
Reported-by: syzbot+a0eecb22de4d821a9e5d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=a0eecb22de4d821a9e5d
Fixes: bd3a19800dd1 ("landlock: Add counted_by in landlock_domain")
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Link: https://lore.kernel.org/r/20261010164450.194439-1-ngocthang2710.1999@gmail.com
Reviewed-by: Günther Noack <gnoack3000@gmail.com>
Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reported-by: Mike Bommarito <michael.bommarito@gmail.com>
Closes: https://lore.kernel.org/r/20261009115108.17819-1-michael.bommarito@gmail.com
[mic: Rebased on master, where the array is handled_masks[], updated the
fortify report, added the clang bug link and the other reports]
Signed-off-by: Mickaël Salaün <mic@digikod.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fixes from Jens Axboe:
- Don't spin on local work the exiting task can't run.
For a ring still R_DISABLED when the task got its tctx node, the
submitter is set later and may be another task, so DEFER_TASKRUN
local work stays pending forever and the exiting task spins in
do_exit().
- Don't charge the SQ/CQ rings or provided buffer rings to
RLIMIT_MEMLOCK. The region API conversion started charging them,
which the rings had been exempt from.
- Don't exempt disabled rings from task restrictions on register
- Populate the CONNECT filter fields for a 24-byte sockaddr_in6
* tag 'io_uring-7.3-20261010' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring/cancel: don't spin on local work the task can't run
io_uring/net: populate CONNECT filter fields for 24-byte sockaddr_in6
io_uring/register: don't exempt disabled rings from task restrictions
io_uring/kbuf: don't charge provided buffer rings to RLIMIT_MEMLOCK
io_uring: do not charge the SQ/CQ rings to RLIMIT_MEMLOCK
|
|
Pull xfs fixes from Carlos Maiolino:
"This fixes a data corruption vector where a user could trick the
exchange-range feature to add shared blocks beyond the file's EOF,
which may then be used to modify data on another file"
* tag 'xfs-fixes-7.3-rc7' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: fix exchange-range-to-eof file size exchange
xfs: stop exchanging reflink flags when exchanging mappings
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Ingo Molnar:
- Work around AMD TLBI Erratum #1718 (Borislav Petkov)
* tag 'x86-urgent-2026-10-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/CPU/AMD: Fix AMD TLBI Erratum #1718
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
"Several security fixes, a significant strnlen() regression fix, and
several other miscellaneous fixes:
- Fix a regression in the Zbb-enabled strnlen() implementation when
huge counts are specified
- When userspace pointer masking is enabled, strip the tag from
user-specified pointers in two spots in the RISC-V futex code where
this was missing
- When CONFIG_SHADOW_CALL_STACK=y, use a supervisor mode-only CSR bit
to determine whether the trap came from userspace or not, rather
than a userspace-writable register
- Reset the HSTATUS.HU bit during CPU initialization to avoid
unexpected behavior, as the RISC-V specification does not require
this bit to be hardware-reset
- Fix the T-Head GhostWrite probing code when
!CONFIG_ERRATA_THEAD_MAE
- Fix RV32 boots using 32-bit.config by constraining NR_CPUS
- Implement a workaround for SiFive MAL-9092, which requires fences
around hypervisor load/store instructions
- Fix the RISC-V patch_map() code to work properly for EXECMEM
addresses when !CONFIG_STRICT_MODULE_RWX
- Fix ptrace register set access reporting when CFI landing pad or
shadow stack support is enabled
- Avoid copying garbage into the target's vstate when
PTRACE_SETREGSET is called with a short iov_len
- Fix load_unaligned_zeropad() on RV32 kernels with
CONFIG_RISCV_EFFICIENT_UNALIGNED_ACCESS=y
- Fix build breakage for any userspace program that includes
uapi/asm/vendor/mips.h
- Fix a build warning for 32-bit allmodconfig builds related to
SiFive errata
- Fix misspecified inline assembly constraints in the vector context
save/restore code"
* tag 'riscv-for-linus-7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: fix load_unaligned_zeropad() fixup for RV32
riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp
riscv: ptrace: Zero-initialize regset buffers before copyin
riscv: ptrace: reject CFI regset access when extensions are absent
riscv: fix NR_CPUS range leaking 64-bit default onto 32-bit builds
riscv: errata: select RISCV_ALTERNATIVE_EARLY for THEAD GHOSTWRITE
riscv: futex: untag the user pointer before the atomic access
riscv: lib: Fix ZBB strnlen wrap-around regression on huge counts
riscv: patch: fix handling of bpf-jit execmem addresses
RISC-V: Clear HSTATUS.HU on CPU initialization
RISC-V: errata: Add SiFive MAL-9092 workaround
riscv: vector: Fix output operands in context save
riscv: vector: Fix data pointer constraints in context save/restore
riscv: limit sifive errata to CONFIG_64BIT
riscv: hwprobe: use _BITULL() rather than BIT() in MIPS vendor uapi header
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
- A fix for the ati_remote2 sysfs attributes handling, resolving type
confusion after conversion to dev_groups
- Updates to the xpad joystick driver adding support for the Corsair
Novablade Pro controller (wired and 2.4 GHz wireless) and a newer
hardware revision of the 8BitDo Pro 2 Wired Controller for Xbox.
* tag 'input-for-v7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: xpad - add support for 8BitDo Pro 2 Wired Controller for Xbox
Input: xpad - add support for Corsair Novablade Pro
Input: ati_remote2 - fix type confusion in device attribute handlers
|
|
CCG4 firmware occasionally fails to respond to I2C read requests,
especially when reading cci and intr_reg from the ISR path. In these
cases, i2c_transfer() returns -EREMOTEIO.
The CCG4 is EOL, and Infineon no longer supports firmware updates, so
a software workaround is necessary.
Attempt the read up to CCG_READ_MAX_RETRIES (4) times in total when
-EREMOTEIO is returned, sleeping ~1 ms via fsleep() between attempts.
This allows recovery from transient I2C failures without affecting
other error paths.
The sleep is safe because ccg_read() is called both from process
context and from ccg_irq_handler(), which runs in threaded IRQ
context (registered via request_threaded_irq() with a NULL hard-IRQ
handler), so sleeping is allowed in both cases.
Fixes: 247c554a14aa ("usb: typec: ucsi: add support for Cypress CCGx")
Cc: stable <stable@kernel.org>
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260916061858.1471606-1-waynec@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This change adds Tegra264 XUSB host mode controller support.
The host controller is very similar to the existing Tegra234 XHCI,
except the number of max_num_wakes.
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260903074539.613220-4-waynec@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Tegra264 XUSB does not use the firmware mailbox handshake to enable
controller messages (MBOX_CMD_MSG_ENABLED). Add a per-SoC flag and
short-circuit __tegra_xusb_enable_firmware_messages() so both probe
and resume avoid sending the command.
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260903074539.613220-3-waynec@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Extend the Tegra234 XUSB host binding to cover Tegra264:
- Add nvidia,tegra264-xusb compatible string
- Document optional USB wake interrupts for Tegra264
- Document Tegra264 PMC wake event to port mapping
- List the up to five IOMMU specifiers for the additional XUSB host
stream IDs, since their order is now significant
- Constrain interrupts and iommus counts for both Tegra234 and
Tegra264 via allOf conditionals, since each SoC wires up a fixed
number of wake interrupts and stream IDs
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260903074539.613220-2-waynec@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Alan Maguire says:
====================
kbuild, bpf: Support inline info in BTF
If CONFIG_DEBUG_INFO_BTF_INLINE=y|m, add the "inline" BTF feature
and encode inline site info in BTF alongside standard BTF data.
resolve_btfids will then partition into non- and inline-related
info and split BTF will be used to store inline info in a
.BTF.inline section in vmlinux and modules. For
CONFIG_DEBUG_INFO_BTF=m, vmlinux inline info will be stored
in btf_vmlinux_inline.ko and will be loaded on-demand if used
via /sys/kernel/btf/vmlinux.inline. A .BTF.inline.link section
in vmlinux stores the module name, the SHA of the BTF and the
size so that even without loading the kernel can size the
sysfs representation correctly. This approach is based on [1]
and the .BTF.inline.link section is modeled on .GNU_debuglink.
Because a module can be built with .BTF.base to allow for
BTF relocation, its inline info needs to be relocated also
so a bit more work needs to be done to handle this.
Patches 1, 2 add resolve_btfids support to partition BTF
into .BTF and .BTF.inline and to support populating
a BTF link section for BTF_INLINE=m. Patch 3 handles
vmlinux.inline exposure in sysfs. Patch 4 does prep
work for relocation needed in patch 5 prior to exposing
relocated BTF in sysfs, and patches 6 and 7 test BTF
sysfs representations and inline validity using
bpf_testmod respectively.
To generate inline info the latest pahole is needed [2].
Inline info for vmlinux can be quite large ~10Mb for
over 600,000 inline sites in the kernel, so
CONFIG_DEBUG_INFO_BTF_INLINE=m
is recommended; this brings the on-disk size down below
4Mb for a gzip-compressed btf_vmlinux_inline.ko.
Changes since v3 [3]:
- Retain original BTF in resolve_btfids and be careful about
free order (bots, patch 1)
- Add more failure diagnostics to patching of BTF links
(bots, patch 2)
- Guard vmallocs for zero-sized inline data (bots, patch 3)
- Fix potential NULL pointer BTF deref (bots, patch 5)
- Fix up leaks in sysfs test (bots, patch 6)
- Fix up tests to use kallsyms lookup directly, and improve
validation of location info (bots, patch 7)
Changes since v2 [4]
- Delivered the libbpf, bpftool parts are prerequisites
- Switched to using Eduard's neater BTF partitioning approach which
is fully in resolve_btfids instead of libbpf (Eduard, patch 1)
- Supports mmap()ed vmlinux.inline (Alexei, patch 3, test patch 7)
- Moved to using .BTF.inline.link to store inline BTF size
which avoids need to switch to using kernfs; also allows us
to SHA-verify BTF inline info
[1] https://lore.kernel.org/bpf/20260925224229.1850-1-wanjay@amazon.com/
[2] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/
[3] https://lore.kernel.org/bpf/20261003194323.817885-1-alan.maguire@oracle.com/
[4] https://lore.kernel.org/bpf/20260901165757.801449-1-alan.maguire@oracle.com/
====================
Link: https://patch.msgid.link/20261009112324.1442319-1-alan.maguire@oracle.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
|
For bpf_testmod verify that we have inline info for an
__always_inline'd function and it matches reasonable
expectations (a single location parameter encoded in a
register given that it cannot be compile-time optimized).
Also verify that the offset of the LOCSEC descriptor makes
sense, i.e. that it is in the range of the function where
it was inlined.
Because bpf_testmod is treated as an out-of-tree module,
the inline information will be in btf_testmod.inline which
is relocated using bpf_testmod.ko .BTF.base.
Test is skipped if pahole does not encode inline info.
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261009112324.1442319-8-alan.maguire@oracle.com
|
|
Load vmlinux, vmlinux.inline and all module and module.inline
entries in /sys/fs/btf; this will allow us to sanity-check
- kernel and its inline representations
- in-tree modules and their inline multi-split BTF representations
- out-of-tree modules and the kernel relocation done for
module and module inline BTF
Since bpf_testmod.ko is built as an out-of-tree module, the
combination of vmlinux, normal in-tree module BTF and out-of-tree
testmod ensures we sanity check relocations for each case.
Also test mmap for vmlinux.inline.
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261009112324.1442319-7-alan.maguire@oracle.com
|
|
Module .BTF.inline is split relative to its module BTF. For external
modules, module BTF can instead be split relative to a distilled
.BTF.base and is relocated against vmlinux when the module loads.
Parse ordinary module inline BTF relative to the pre-relocation
module BTF. Retain the module relocation ID and string maps, then
rebase inline type IDs and string offsets onto the final
vmlinux/module BTF space before exposing the result through sysfs.
Malformed or unrelocatable optional inline BTF is warned about and
omitted without preventing normal module BTF registration. The
btf_vmlinux_inline carrier remains on its existing hash-checked,
vmalloc-backed publishing path, preserving mmap support for
vmlinux.inline when delivered by a module.
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261009112324.1442319-6-alan.maguire@oracle.com
|
|
Make btf_relocate() optionally return the string-offset map it builds
while relocating a BTF relative to a distilled base. A subsequent split
BTF object can use that map to rebase references to base strings.
Also account for the accumulated base string offset when assigning a
new BTF base. This is required when the base is itself split.
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261009112324.1442319-5-alan.maguire@oracle.com
|
|
Expose BTF inline-location information from vmlinux .BTF.inline
sections in /sys/kernel/btf as vmlinux.inline. Embedded vmlinux
inline BTF supports read-only mmap().
Provide runtime support for a module-delivered vmlinux inline BTF
carrier. Its link record binds the carrier module name, BTF size, and
SHA-256 digest to the running kernel before its data is made available
through a lazy vmlinux.inline sysfs attribute. The carrier is handled
before ordinary module BTF registration, so its incidental .BTF data is
not exposed.
Make CONFIG_DEBUG_INFO_BTF_INLINE tristate. When configured as a
module, retain vmlinux final split inline BTF for
btf_vmlinux_inline.ko instead of embedding it in vmlinux.
Reserve .BTF.inline.link in vmlinux and extend the final
resolve_btfids patch pass to bind btf_vmlinux_inline to the raw
vmlinux.BTF.inline payload. This preserves the normal built-in
configuration while allowing the large inline BTF payload to load on
demand.
Normal module inline BTF is handled separately, after its
references have been relocated against the final module BTF.
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261009112324.1442319-4-alan.maguire@oracle.com
|
|
Allow the final BTF patch pass to populate one or more BTF link
records. A link identifies the BTF section to be delivered, its
carrier module, and the raw finalized BTF payload:
--btf_link <section>:<module>:<raw-btf-file>
Use the raw file size and SHA-256 digest to populate the corresponding
<section>.link record. This avoids reparsing BTF during final ELF
patching and supports inline vmlinux BTF linking.
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261009112324.1442319-3-alan.maguire@oracle.com
|
|
Extract .BTF.inline via the following logic:
- Traverse all types reachable from LOC_PARAM, LOC_PROTO, LOCSEC
entries and mark them as having LOC color.
- Traverse all types reachable from the remaining types
and mark them as having MAIN or SHARED.
- Create a new base BTF object and copy all MAIN/SHARED types there.
- Create a new .BTF.inline object with base set to the new base BTF
object, and copy all LOC types there.
This way .BTF.inline can refer to types and strings in the new base,
and strings used only by .BTF.inline remain in it.
Additionally, all BTF_KIND_FUNC types that map to ELF symbols with the
same name are forced to be in the base BTF. Same for types referenced
from BTF id sets.
Regular types referenced only from .BTF.inline remain in the base BTF,
and sizes are 5 and 9.5Mb for vmlinux and vmlinux.inline respectively.
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261009112324.1442319-2-alan.maguire@oracle.com
|
|
Instead of hard-coding the TUSB73X0 PCI ID, USB_CTRL register address
and the PWRON_POLARITY, introduce definitions for them to make the code
easier to read.
No functional change.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci_ids.h
Link: https://patch.msgid.link/20261009125154.266435-1-festevam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The Axiado AX3005 xHCI controller is software-compatible with the
generic xHCI programming interface and uses "generic-xhci" as its
fallback, as do the Marvell Armada 37xx/8k controllers.
Add "axiado,ax3005-xhci" to the existing compatible enum instead of
adding a separate schema entry. Since the enum no longer covers only
Armada parts, drop the "Armada 37xx/8k SoCs" description rather than
leave it inaccurate.
Signed-off-by: Swark Yang <syang@axiado.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260805-upstrea-ax3005-usb-v4-v4-1-796af97bfce4@axiado.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
It seems the xhci-pci-prom21 module only has IDs for the 800 series
chipsets. However, the 600 series chipsets also have Promontory 21
chips, so we should add their IDs to the list as well.
I have tested this on my X670 board featuring DID `0x43f7`.
`1022:43f7` also appears on the PCI ID database
(https://pci-ids.ucw.cz/read/PC/1022/43f7).
Device IDs `0x43f9` (B665) & `0x43fa` (A620) were suggested by Shyam.
Also list the new IDs in Documentation/hwmon/prom21-xhci.rst.
Cc: stable@vger.kernel.org # 7.2.x
Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Cc: Jihong Min <hurryman2212@gmail.com>
Signed-off-by: Stephen Horvath <linux@stevetech.au>
Tested-by: Mirko Jechow <mirko.jechow@gmx.de>
[mirko.jechow@gmx.de: add new IDs to prom21-xhci.rst]
Signed-off-by: Mirko Jechow <mirko.jechow@gmx.de>
Link: https://patch.msgid.link/20261004002731.49927-1-mirko.jechow@gmx.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Offloaded USB audio devices using the xhci-sideband API store a pointer to
the xhci virtual device (vdev) in the sideband structure when registering.
This pointer typically remains valid throughout the lifetime of the USB
device. If a configured offloaded device requires a reset, the USB core
usually unbinds or notifies the audio driver beforehand, ensuring that the
sideband is unregistered before the vdev is freed.
An exception occurs when the USB core resets a device to recover from a
failed resume, but a subsequent 'address device' request also fails. To
recover in this specific scenario, the xHCI driver disables and re-enables
the slot, which frees and re-allocates the vdev.
xhci_sideband_unregister() later dereferences the stale, previously freed
vdev pointer during disconnect, triggering a kernel oops:
Unable to handle kernel paging request at virtual address dead000000000122
Call trace:
xhci_get_ep_ctx+0x0/0x38
xhci_sideband_unregister+0x68/0xf0
uaudio_disconnect+0x70/0x144
usb_audio_disconnect+0x7c/0x268
usb_unbind_interface+0x13c/0x340
device_release_driver_internal+0x1c4/0x2bc
usb_disable_device+0x84/0x190
usb_disconnect+0xe8/0x338
hub_event+0xbd8/0x19ac
Fix this by preventing the reallocation of the vdev in this specific error
path if the device is registered for sideband use.
Just propagate the error directly to the USB core. It should either retry
enumeration or detect the disconnected device, and handle it accordingly.
Debugging this issue to the dangling vdev pointer, reporting it, testing,
and initial patch with different solution by Lianqin Hu
Reported-by: Lianqin Hu <hulianqin@vivo.com>
Closes: https://lore.kernel.org/linux-usb/TYUPR06MB6217000B59003EDF233D7246D2B22@TYUPR06MB6217.apcprd06.prod.outlook.com/
Tested-by: Lianqin Hu <hulianqin@vivo.com>
Fixes: de66754e9f80 ("xhci: sideband: add initial api to register a secondary interrupter entity")
Cc: stable@vger.kernel.org
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-12-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
High-speed devices with out of spec 1024 byte bulk endpoints exist and
are allowed by USB core, but xhci-hcd always sets packet size to 512.
The exact nature of these devices isn't documented, commit fb5ee84ea72c
("USB: Accept bulk endpoints with 1024-byte maxpacket") only states
that they "don't work with xHCI host controllers", whatever it means.
But somebody (or a malicious device) can try, and then the driver will
allocate a 512 byte bounce buffer for this endpoint and may write up to
1024 bytes into it if particular scatter-gather URBs are used, because
xhci_align_td() obtains packet size from the descriptor. Fix this.
As a side effect, TRBs will be aligned to the packet size chosen by the
driver on all endpoints of all speeds. Alignment serves the xHC, not
device, so this is fine. Only out of spec devices are affected anyway.
Reported-by: co+fd80bc5967eb22c3@bugs.sh
Link: https://lore.kernel.org/linux-usb/D4tcSGerkYkIV1DmaUo1t8TaR5qQElDLkidn@bugs.sh/
Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a bounce buffer")
Cc: stable@vger.kernel.org
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-11-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Matching events with TDs and giving back missed TDs is carried out
by a complicated loop. Replace it with a simpler linear logic:
0. Having verified that 'td_list' isn't empty,
1. Scan it to find the matching TD and count missed TDs,
2. Perform necessary adjustments for corner cases,
3. Give back missed TDs, if applicable, using a short and tidy loop,
4. Check if the event refers to the expected TD and proceed as usual.
Besides cleaning up the code, this provides a few improvements:
- when the skip flag is set, no TD is given back unless we found a match
or otherwise know how many TDs should be given back
- when the skip flag is clear, we know if the event refers to a "future"
TD so we can log this in the Scary Error Message to aid debugging.
While altering the error message, drop a pointless goto.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-10-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Half of this loop is code which only executes once to deal with cases
where no TD matches the event and then it returns. This code needs not
to be in any kind of loop, so get it out.
Optimize conditionals remaining in the loop body.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-9-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
These events are unique to isochronous endpoints, ignore them otherwise.
Update debug messages to reflect new policies. We could also log invalid
events as errors, but it seems nobody has ever had problems with that,
so don't bother.
This allows dropping the isoc check when skipping TDs.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-8-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In this case we know that the xHC has released ownership of all missed
TDs, we only don't know which were missed and which were queued later.
URBs are queued atomically, so we can safely give back all TDs of the
currently executing URB. Unlike the previous policy, this does actually
ensure that the class driver will learn about the error and won't see
all of its URBs still in progress when all TDs are missed on xHCI 1.0.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-7-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
dbc_tty_minors is protected by dbc_tty_minors_lock when entries are
allocated and during normal device removal. The registration error path
removes an entry without taking that lock. Different DbC instances have
separate event work items, so this removal can race with an IDR update
for another instance.
Take the same mutex around the error-path removal.
Fixes: e1ec140f273e ("xhci: dbgtty: use IDR to support several dbc instances.")
Reported-by: Changyul Lee <lcy8047@gmail.com>
Assisted-by: LLM
Signed-off-by: Sang-Hoon Choi <csh0052@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-6-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The xHCI driver programs the Device Notification Control register to
only enable the Function Wake device notification (N1), so any Device
Notification Event TRB received is expected to be a function wake
notification. handle_device_notification() does however not check the
Notification Type field of the event (xHCI 1.2 section 6.4.2.7, DW0
bits 7:4), and forwards every device notification event as a function
wake.
A host controller that delivers an unexpected notification type (e.g.
due to broken firmware or emulation) would trigger a spurious wake
notification on the parent hub.
Parse the notification type and drop events other than Function Wake
with a warning, mirroring the slot ID validation in the same function.
DEV_NOTE_FWAKE is the DNCTRL register bit for notification type 1
(N1), while the event TRB carries the notification type value itself,
so add a separate DEV_NOTE_TYPE_FWAKE constant for the comparison.
[mn:] reduce warning to a debug message
Signed-off-by: Hongyu Xie <xiehongyu1@kylinos.cn>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Fix various spelling mistakes in comments found by codespell.
Assisted-by: Claude:claude-opus-5-5 codespell
Signed-off-by: Zain Aboobacker <zainaboobacker33@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
xhci_abort_cmd_ring() requests abort, waits for the CRR bit to clear,
drops xhci->lock and waits for the Command Ring Stopped event.
The CRR wait timeout is 5 seconds as suggested by xHCI 4.6.1.2, which
means that if the xHC fails to complete the operation at all, we poll
with the lock held and IRQs disabled for several seconds. If any other
CPU tries to acquire the lock, it will spin likewise. IRQs get delays,
drivers log errors, tasks freeze, it's a mess.
So drop the lock earlier, before waiting for the CRR bit. It should be
safe - the sole caller sets cmd_ring_state to CMD_RING_STATE_ABORTED
before calling us, which will prevent others from ringing the command
doorbell and interfering with the abort. Queuing new commands during
this time poses no danger, and if the command we try to abort actually
completes concurrently, existing code already needs to deal with this.
And in my testing it does - it's trivial to trigger this on ASM1042,
where Address Device can't be aborted, but it completes as soon as the
offending device is unplugged, including during abort attempt.
Note that the lock still covers reinit_completion(), so it won't race
with complete() being called by the event handler. And works are not
reentrant, so another timeout can't expire while the lock is dropped.
We will configure timeout anew when restarting the ring.
One other difference is that now we also drop the lock if abort fails.
This too should be harmless. Commands queued during this time will be
released like any other pending commands. If the aborted command does
complete before we regain the lock, it's a waste, but not regression.
Reported-by: Pedro Fonseca <pedro@fonseca.com.pt>
Link: https://lore.kernel.org/linux-usb/16f65081-5a3c-4c30-9811-9017796a3373@fonseca.com.pt/
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
xhci_reset() returns 0 when the host is not halted, without ever writing
CMD_RESET. Every other path that fails to reset the host returns an
error, so callers that check the return value are told the reset
succeeded on the one path where it did not happen.
Return -EBUSY when the reset is aborted because the host is not halted.
Signed-off-by: Henry Tseng <henrytseng@qnap.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://patch.msgid.link/20261009151624.618967-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When the PPM reports more than one DisplayPort alternate mode for a
connector, ucsi_ccg_update_altmodes() merges them into a single entry
in uc->updated[] and sets uc->has_multiple_dp. In that case,
ucsi_ccg_update_get_current_cam_cmd() rewrites the response of the
GET_CURRENT_CAM command. The response is a single byte holding the
index of the currently active alternate mode, and it is provided by
the PPM firmware.
The function uses this byte directly as an index into uc->orig[], and
then uses the linked_idx read from that entry as the translated index
into uc->updated[]. Both arrays have UCSI_MAX_ALTMODES entries, but
neither index is checked against that size.
If a malicious or buggy PPM reports a value of UCSI_MAX_ALTMODES or
larger, e.g. 0xFF, uc->orig[cam].linked_idx reads over the end of
uc->orig[]. The byte read from there is then used as the index for
writing cam into uc->updated[new_cam].active_idx, so the out-of-bounds
read is followed by an out-of-bounds write. This happens without any
userspace action, since the UCSI core issues GET_CURRENT_CAM on its own
when handling connector changes.
Fix this by rejecting responses whose index is out of range, printing an
error and returning -EPROTO, so that the caller cannot accept this.
Also check linked_idx before using it as an index, so that the write into
uc->updated[] is always within bounds.
The response is now only processed when the command completed without
an error. ucsi_sync_control_common() only reads the response when the
CCI reports command completion, so otherwise the buffer is not filled
and must not be mistaken for an invalid index.
This bug was found with a Python script that traces where firmware input
is used.
Fixes: 170a6726d0e2 ("usb: typec: ucsi: add support for separate DP altmode devices")
Cc: stable <stable@kernel.org>
Reported-by: Nathan Rebello <nathan.c.rebello.27@dartmouth.edu>
Assisted-by: LLM
Signed-off-by: Seungjin Bae <eeodqql09@gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20261003215520.611083-2-eeodqql09@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|