summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-06-04libfs: drop redundant SB_I_NOEXEC/SB_I_NODEV in init_pseudo() callersJohn Hubbard
init_pseudo() now sets SB_I_NOEXEC and SB_I_NODEV by default, so the per-caller assignments are redundant. Drop them. Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260604025315.245910-3-jhubbard@nvidia.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04libfs: set SB_I_NOEXEC and SB_I_NODEV by default in init_pseudo()John Hubbard
Since commit 1e7ab6f67824 ("anon_inode: rework assertions"), path_noexec() warns when an anonymous-inode file is mmap'd from a superblock that has not set SB_I_NOEXEC. dma-buf backs its files this way and never set the flag, so mmap of any exported buffer trips the warning on a CONFIG_DEBUG_VFS=y kernel: WARNING: CPU: 11 PID: 121813 at fs/exec.c:118 path_noexec+0x47/0x50 do_mmap+0x2b5/0x680 vm_mmap_pgoff+0x129/0x210 ksys_mmap_pgoff+0x177/0x240 __x64_sys_mmap+0x33/0x70 init_pseudo() sets up internal SB_NOUSER mounts that are never path-reachable. Set both flags here so every pseudo filesystem gets them by default instead of each caller setting them. SB_I_NODEV is inert for unreachable mounts. SB_I_NOEXEC has one visible effect: an executable mapping of a pseudo-fs fd, such as a dma-buf, now fails with -EPERM, which is the invariant the assertion enforces. No in-tree caller maps these executable. Reproduce on CONFIG_DEBUG_VFS=y: make -C tools/testing/selftests/dmabuf-heaps sudo ./tools/testing/selftests/dmabuf-heaps/dmabuf-heap -t system Fixes: 1e7ab6f67824 ("anon_inode: rework assertions") Suggested-by: Christoph Hellwig <hch@infradead.org> Cc: stable@vger.kernel.org Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20260604025315.245910-2-jhubbard@nvidia.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04iomap: avoid potential null folio->mapping deref during error reportingJoanne Koong
When a buffered read fails, iomap_finish_folio_read() reports the error with fserror_report_io(folio->mapping->host, ...). This is called after ifs->read_bytes_pending has been decremented by the bytes attempted to be read. For a folio split across multiple read completions, the folio is only guaranteed to stay locked while read_bytes_pending > 0. Once iomap_finish_folio_read() decrements read_bytes_pending, another in-flight read can complete and end the read on the folio, which unlocks it. This allows truncate logic to run and detach the folio (set folio->mapping to NULL). The error reporting path then can dereference a NULL folio->mapping. As reported by Sam Sun, this is the race that can occur: CPU0: failed completion CPU1: final completion CPU2: truncate ----------------------- ---------------------- -------------- read_bytes_pending -= len finished = false /* preempted before fserror_report_io() */ read_bytes_pending -= len finished = true folio_end_read() truncate clears folio->mapping fserror_report_io( folio->mapping->host, ...) ^ NULL deref Fix this by reporting the error first before decrementing ifs->read_bytes_pending. Fixes: a9d573ee88af ("iomap: report file I/O errors to the VFS") Cc: stable@vger.kernel.org Reported-by: Sam Sun <samsun1006219@gmail.com> Closes: https://lore.kernel.org/linux-fsdevel/CAEkJfYPhWdd59RKmuNLJg-bkypHz7xiOwaWyNVu3A8CUqQCnvg@mail.gmail.com/ Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Link: https://patch.msgid.link/20260604011858.2297561-1-joannelkoong@gmail.com Reviewed-by: "Darrick J. Wong" <djwong@kernel.org> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh()Jann Horn
may_decode_fh() accesses mount::mnt_ns without holding any locks; that means the mount can concurrently be unmounted, and the mnt_namespace can concurrently be freed after an RCU grace period. This race can happens as follows, assuming that the mount point was created by open_tree(..., OPEN_TREE_CLONE): thread 1 thread 2 RCU __do_sys_open_by_handle_at do_handle_open handle_to_path may_decode_fh is_mounted [mount::mnt_ns access] [mount::mnt_ns access] __do_sys_close fput_close_sync __fput dissolve_on_fput umount_tree class_namespace_excl_destructor namespace_unlock free_mnt_ns mnt_ns_tree_remove call_rcu(mnt_ns_release_rcu) mnt_ns_release_rcu mnt_ns_release kfree [mnt_namespace::user_ns access] **UAF** Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like in __prepend_path(). Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE() for writers that can race with lockless readers. This bug is unreachable unless one of the following is set: - CONFIG_PREEMPTION - CONFIG_RCU_STRICT_GRACE_PERIOD because it requires an RCU grace period to happen during a syscall without an explicit preemption. This doesn't seem to have interesting security impact; worst-case, it could leak the result of an integer comparison to userspace (from the level check in cap_capable()), cause an endless loop, or crash the kernel by dereferencing an invalid address. Fixes: 620c266f3949 ("fhandle: relax open_by_handle_at() permission checks") Cc: stable@vger.kernel.org Signed-off-by: Jann Horn <jannh@google.com> Link: https://patch.msgid.link/20260603-vfs-fhandle-uaf-fix-v2-1-d05db76a5084@google.com Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
2026-06-04Merge tag 'zynqmp-soc-for-7.2' of https://github.com/Xilinx/linux-xlnx into ↵Linus Walleij
soc/drivers arm64: Xilinx SOC changes for 7.2 firmware: - Add CSU register discovery with sysfs interface zynqmp_power: - Fix race condition in event registration - Fix shutdown and free rx mailbox channel * tag 'zynqmp-soc-for-7.2' of https://github.com/Xilinx/linux-xlnx: firmware: zynqmp: Add dynamic CSU register discovery and sysfs interface Documentation: ABI: add sysfs interface for ZynqMP CSU registers soc: xilinx: Shutdown and free rx mailbox channel soc: xilinx: Fix race condition in event registration Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-06-04kbuild: rust: rename flag to `-Zdebuginfo-for-profiling` for Rust >= 1.98Miguel Ojeda
Starting with Rust 1.98.0 (expected 2026-08-20), the `-Zdebug-info-for-profiling` flag has been renamed to `-Zdebuginfo-for-profiling` (i.e. one less dash, to match `debuginfo`s in other flags) [1]. Without this change, one gets in the latest nightlies: error: unknown unstable option: `debug-info-for-profiling` Thus pass the right name. Link: https://github.com/rust-lang/rust/pull/156887 [1] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260602151638.14358-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-06-04arm64: dts: hisilicon: hi3660-hikey960: move role-switch endpoint into connectorAkash Sukhavasi
The rt1711h Type-C controller on the HiKey960 has the USB role-switch endpoint placed as a top-level 'port' node, outside the connector subnode. This triggers two dtbs_check warnings against richtek,rt1711h.yaml: - 'port' does not match any of the regexes: '^pinctrl-[0-9]+$' - connector:ports: 'port@0' is a required property Move the role-switch endpoint into the connector's port@0, which is where usb-connector.yaml expects it. Update the DWC3 remote-endpoint phandle accordingly. The TCPM core (tcpm.c) looks up the role switch starting from the connector fwnode via fwnode_usb_role_switch_get(). With the endpoint inside the connector's port@0, it is found through the primary lookup path rather than the device-level fallback. Cross-compiled for arm64. Verified with dt_binding_check and dtbs_check. Not runtime-tested on hardware. Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2026-06-04iommu/vt-d: Fix RB-tree corruption in probe error pathPranjal Shrivastava
The info->node RB-tree member is zero-initialized via kzalloc. If a device does not support ATS, the device_rbtree_insert() call is skipped. If a subsequent probe step fails, the error path jumps to device_rbtree_remove(), which misinterprets the zeroed node as a tree root and corrupts the device RB-tree. Fix this by explicitly initializing the RB-node as empty using RB_CLEAR_NODE() during initialization and guarding the removal with RB_EMPTY_NODE(). Fixes: 4f1492efb495 ("iommu/vt-d: Revert ATS timing change to fix boot failure") Reported-by: sashiko-bot@kernel.org Closes: https://lore.kernel.org/all/20260525205628.CD4431F000E9@smtp.kernel.org/ Suggested-by: Baolu Lu <baolu.lu@linux.intel.com> Signed-off-by: Pranjal Shrivastava <praan@google.com> Link: https://lore.kernel.org/r/20260531170254.60493-2-praan@google.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-06-04iommu/vt-d: Improve IOMMU fault informationGuanghui Feng
In some environments, multiple PCIe segments exist, and PCIe device information needs to be differentiated and identified based on the segment. When an IOMMU fault event occurs, the IOMMU and device segment information should be output in detail in dmar_fault_do_one. Signed-off-by: Guanghui Feng <guanghuifeng@linux.alibaba.com> Link: https://lore.kernel.org/r/20260528022943.1697564-1-guanghuifeng@linux.alibaba.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-06-04iommu/vt-d: Remove typo from pasid_pte_config_nested()Michał Grzelak
Rename pasid_pte_config_nestd() into pasid_pte_config_nested(). Do it to match other function names ending with _nested(). Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://lore.kernel.org/r/20260509174503.831134-1-michal.grzelak@intel.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-06-04iommu/vt-d: Clear Present bit before tearing down scalable-mode context entryMichael Bommarito
device_pasid_table_teardown() zeroes the 128-bit scalable-mode context entry with context_clear_entry() while the Present bit is still set. This creates a window where the hardware can fetch a torn entry, with some fields already zeroed while Present is still set, leading to unpredictable behavior or spurious faults. The context-cache invalidation is issued only after the entry has been zeroed, and intel_pasid_free_table() then frees the PASID directory pages, so the IOMMU can keep walking a stale Present=1 entry that points at freed memory. While x86 provides strong write ordering, the compiler may reorder the two 64-bit writes to the entry, and the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes. Commit c1e4f1dccbe9d ("iommu/vt-d: Clear Present bit before tearing down context entry") fixed this exact pattern in domain_context_clear_one() and the copied-context path, but device_pasid_table_teardown() was not converted. Align it with the "Guidance to Software for Invalidations" in the VT-d spec, Section 6.5.3.3, using the same ownership handshake as the sibling fix: clear only the Present bit, flush it to the IOMMU, perform the context-cache invalidation, and only then zero the rest of the entry. Fixes: 81e921fd32161 ("iommu/vt-d: Fix NULL domain on device release") Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Assisted-by: Claude:claude-opus-4-7 Link: https://lore.kernel.org/r/20260528025557.3209367-1-michael.bommarito@gmail.com Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-06-04iommu/vt-d: Avoid WARNING in sva unbind pathLu Baolu
The Intel IOMMU driver allows SVA on devices even if they do not support PCI/PRI. Commit 39c20c4e83b9 ("iommu/vt-d: Only handle IOPF for SVA when PRI is supported") modified the SVA bind path to allow this configuration by skipping IOPF enablement when PRI is missing. However, it failed to update the unbind path. This creates an imbalance: the unbind path attempts to disable IOPF for a device that never had it enabled, triggering a WARNING in intel_iommu_disable_iopf(): WARNING: drivers/iommu/intel/iommu.c:3475 at intel_iommu_disable_iopf+0x4f/0x90d Call Trace: <TASK> blocking_domain_set_dev_pasid+0x50/0x70 iommu_detach_device_pasid+0x89/0xc0 iommu_sva_unbind_device+0x73/0x150 xe_vm_close_and_put+0x4d2/0x1200 [xe] Fix this by bypassing IOPF operations for SVA domains on non-PRI hardware in both the bind and unbind paths. Fixes: 39c20c4e83b9 ("iommu/vt-d: Only handle IOPF for SVA when PRI is supported") Cc: stable@vger.kernel.org Reported-by: Nareshkumar Gollakoti <naresh.kumar.g@intel.com> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20260519052917.3729796-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-06-04USB: serial: option: add usb-id for Dell Wireless DW5826e-mJack Wu
Add support for Dell DW5826e-m with USB-id 0x413c:0x81ea T: Bus=03 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 8 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=413c ProdID=81ea Rev= 5.04 S: Manufacturer=DELL S: Product=DW5826e-m Qualcomm Snapdragon X12 Global LTE-A S: SerialNumber=358988870177734 C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=88(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Jack Wu <jackbb_wu@compal.com> Reviewed-by: Lars Melin <larsm17@gmail> Cc: stable@vger.kernel.org [ johan: reserve also interface 4 ] Signed-off-by: Johan Hovold <johan@kernel.org>
2026-06-04dmaengine: tegra: Add Tegra264 supportAkhil R
Add compatible and chip data to support GPCDMA in Tegra264, which has differences in register layout and address bits compared to previous versions. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260331102303.33181-10-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: tegra: Use iommu-map for stream IDAkhil R
Use 'iommu-map', when provided, to get the stream ID to be programmed for each channel. Iterate over the channels registered and configure each channel device separately using of_dma_configure_id() to allow it to use a separate IOMMU domain for the transfer. However, do this in a second loop since the first loop populates the DMA device channels list and async_device_register() registers the channels. Both are prerequisites for using the channel device in the next loop. Channels will continue to use the same global stream ID if the 'iommu-map' property is not present in the device tree. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260331102303.33181-9-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: tegra: Use managed DMA controller registrationAkhil R
Switch to managed registration in probe. This simplifies the error paths in the probe and also removes the requirement of the driver remove function. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Suggested-by: Frank Li <frank.li@nxp.com> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260331102303.33181-8-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: tegra: Support address width > 39 bitsAkhil R
Tegra264 supports address width of 41 bits. Unlike older SoCs which use a common high_addr register for upper address bits, Tegra264 has separate src_high and dst_high registers to accommodate this wider address space. Add an addr_bits property to the device data structure to specify the number of address bits supported on each device and use that to program the appropriate registers. Update the sg_req struct to remove the high_addr field and use dma_addr_t for src and dst to store the complete addresses. Extract the high address bits only when programming the registers. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260331102303.33181-7-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: tegra: Use struct for register offsetsAkhil R
Repurpose the struct tegra_dma_channel_regs to define offsets for all the channel registers. Previously, the struct only held the register values for each transfer and was wrapped within tegra_dma_sg_req. Move the values directly into tegra_dma_sg_req and use channel_regs for storing the register offsets. Update all register reads/writes to use the struct channel_regs. This prepares for the register offset change in Tegra264. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260331102303.33181-6-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: tegra: Make reset control optionalAkhil R
On Tegra264, reset is not available for the driver to control as this is handled by the boot firmware. Hence make the reset control optional and update the error message to reflect the correct error. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260331102303.33181-5-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map propertyAkhil R
Add iommu-map property to specify separate stream IDs for each DMA channel. This enables each channel to be in its own IOMMU domain, keeping memory isolated from other devices sharing the same DMA controller. Define the constraints such that if the channel and stream IDs are contiguous, a single entry can map all the channels, but if the channels or stream IDs are non-contiguous support multiple entries. Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260331102303.33181-4-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optionalAkhil R
On Tegra264, GPCDMA reset control is not exposed to Linux and is handled by the boot firmware. Although reset was not exposed in Tegra234 as well, the firmware supported a dummy reset which just returns success on reset without doing an actual reset. This is also not supported in Tegra264 BPMP. Therefore mark 'reset' and 'reset-names' properties as required only for devices prior to Tegra264. This also necessitates that the Tegra264 compatible be standalone and cannot have the fallback compatible of Tegra186. Since there is no functional impact, we keep reset as required for Tegra234 to avoid breaking the ABI. Fixes: bb8c97571db5 ("dt-bindings: dma: Add Tegra264 compatible string") Signed-off-by: Akhil R <akhilrajeev@nvidia.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260331102303.33181-2-akhilrajeev@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04RISC-V: KVM: Fix timer state restoreQiang Ma
The KVM_REG_RISCV_TIMER_REG(state) one-reg write passes the value written by userspace to kvm_riscv_vcpu_timer_next_event() when re-enabling the timer. That value is the timer state, KVM_RISCV_TIMER_STATE_ON, not the timer compare value. During migration or state restore, userspace restores the compare register separately, which stores the target cycle in t->next_cycles. Re-arming the timer with the state value schedules the next event at cycle 1 instead of the restored compare value, causing the virtual timer to fire too early. Use the restored compare value from t->next_cycles when turning the timer back on. Fixes: 3a9f66cb25e1 ("RISC-V: KVM: Add timer functionality") Signed-off-by: Qiang Ma <maqianga@uniontech.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260526075544.796396-1-maqianga@uniontech.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-04dmaengine: imx-sdma: Refine spba bus searching in probeShengjiu Wang
There are multi spba-busses for i.MX8M* platforms, if only search for the first spba-bus in DT, the found spba-bus may not the real bus of audio devices, which cause issue for sdma p2p case, as the sdma p2p script presently does not deal with the transactions involving two devices connected to the AIPS bus. Search the SDMA parent node first, which should be the AIPS bus, then search the child node whose compatible string is spba-bus under that AIPS bus for the above multi spba-busses case. Fixes: 8391ecf465ec ("dmaengine: imx-sdma: Add device to device support") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260407032755.2758049-1-shengjiu.wang@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04RISC-V: KVM: Fix NULL pointer dereference in AIA IMSIC functionsJiakai Xu
Fuzzer reported a NULL pointer dereference in kvm_riscv_vcpu_aia_imsic_put() when a VCPU's imsic_state was NULL while kvm_riscv_aia_initialized() returned true. The global initialized flag is set per-VM in aia_init(), but imsic_state is allocated per-VCPU in kvm_riscv_vcpu_aia_imsic_init(). If a VCPU is created after aia_init() has already run, its imsic_state remains NULL while the global flag is true. When this VCPU is preempted, kvm_sched_out() calls kvm_arch_vcpu_put() -> kvm_riscv_vcpu_aia_put() -> kvm_riscv_vcpu_aia_imsic_put() which dereferences NULL. Add NULL pointer guards to kvm_riscv_vcpu_aia_imsic_put(), consistent with the NULL checks already present in all other functions in the same file. Also add a NULL guard to kvm_riscv_vcpu_aia_imsic_release() and kvm_riscv_vcpu_aia_imsic_has_interrupt() for the same reason. Fixes: 4cec89db80ba ("RISC-V: KVM: Move HGEI[E|P] CSR access to IMSIC virtualization") Signed-off-by: Jiakai Xu <jiakaiPeanut@gmail.com> Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn> Assisted-by: YuanSheng:DeepSeek-V3.2 Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260526031517.1166025-1-xujiakai2025@iscas.ac.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-04RISC-V: KVM: Document a TOCTOU race in SBI system suspend handlerJiakai Xu
The SUSP handler checks that all other vCPUs are stopped before entering system suspend, but a concurrent HSM HART_START can start a vCPU after it has already passed the check. This is a known TOCTOU race. We do not fix it because: 1. Triggering it requires a pathological guest. 2. Only guest state is at risk, not host integrity. 3. Userspace can double-check vCPU states before suspend. Add a comment documenting the race and the rationale for not fixing it. Signed-off-by: Jiakai Xu <jiakaiPeanut@gmail.com> Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn> Assisted-by: YuanSheng:DeepSeek-V3.2 Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260525013642.999187-1-xujiakai2025@iscas.ac.cn Signed-off-by: Anup Patel <anup@brainfault.org>
2026-06-04hwrng: virtio: clamp device-reported used.len at copy_data()Michael Bommarito
random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64). A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng. Concrete impact is inside the guest: - Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB. - Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host. KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000: BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20) Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport. With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request. Fixes: f7f510ec1957 ("virtio: An entropy device, as suggested by hpa.") Cc: stable@vger.kernel.org Suggested-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20260531142251.2792061-1-michael.bommarito@gmail.com>
2026-06-04virtio_pci: fix vq info pointer lookup via wrong indexAmmar Faizi
Unbinding a virtio balloon device: echo virtio0 > /sys/bus/virtio/drivers/virtio_balloon/unbind triggers a NULL pointer dereference. The dmesg says: BUG: kernel NULL pointer dereference, address: 0000000000000008 [...] RIP: 0010:__list_del_entry_valid_or_report+0x5/0xf0 Call Trace: <TASK> vp_del_vqs+0x121/0x230 remove_common+0x135/0x150 virtballoon_remove+0xee/0x100 virtio_dev_remove+0x3b/0x80 device_release_driver_internal+0x187/0x2c0 unbind_store+0xb9/0xe0 kernfs_fop_write_iter.llvm.11660790530567441834+0xf6/0x180 vfs_write+0x2a9/0x3b0 ksys_write+0x5c/0xd0 do_syscall_64+0x54/0x230 entry_SYSCALL_64_after_hwframe+0x29/0x31 [...] </TASK> The virtio_balloon device registers 5 queues (inflate, deflate, stats, free_page, reporting) but only the first two are unconditional. The stats, free_page and reporting queues are each conditional on their respective feature bits. When any of these features are absent, the corresponding vqs_info entry has name == NULL, creating holes in the array. The root cause is an indexing mismatch introduced when vq info storage was changed to be passed as an argument. vp_find_vqs_msix() and vp_find_vqs_intx() store the info pointer at vp_dev->vqs[i], where 'i' is the caller's sparse array index. However, the virtqueue itself gets vq->index assigned from queue_idx, a dense index that skips NULL entries. When holes exist, 'i' and queue_idx diverge. Later, vp_del_vqs() looks up info via vp_dev->vqs[vq->index] using the dense index into the sparsely-populated array, and hits NULL. Fix this by storing info at vp_dev->vqs[queue_idx] instead of vp_dev->vqs[i], so the store index matches the lookup index (vq->index). Apply the fix to both the MSIX and INTX paths. Cc: Yichun Zhang <yichun@openresty.com> Cc: Jiri Pirko <jiri@nvidia.com> Cc: stable@vger.kernel.org # v6.11+ Tested-by: Yuka <yuka@umeyashiki.org> Fixes: 89a1c435aec2 ("virtio_pci: pass vq info as an argument to vp_setup_vq()") Signed-off-by: Ammar Faizi <ammarfaizi2@openresty.com> Message-Id: <20260315141808.547081-1-ammarfaizi2@openresty.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2026-06-04thunderbolt: debugfs: Fix margining error counter buffer leakXu Rao
When USB4 lane margining debugfs write support is enabled, margining_error_counter_write() copies the user input with validate_and_copy_from_user(). This allocates a temporary page that is only needed while parsing the requested error counter mode. The function currently returns without freeing that page. This leaks one page per write to the error_counter debugfs file, including successful writes and writes that later fail while taking the domain lock or because software margining is not enabled. Free the temporary page once parsing has completed, and also before returning from the invalid-input path. Fixes: 10904df3f20c ("thunderbolt: Improve software receiver lane margining") Signed-off-by: Xu Rao <raoxu@uniontech.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-06-04vhost: fix vhost_get_avail_idx for a non empty ringMichael S. Tsirkin
vhost_get_avail_idx is supposed to report whether it has updated vq->avail_idx. Instead, it returns whether all entries have been consumed, which is usually the same. But not always - in drivers/vhost/net.c and when mergeable buffers have been enabled, the driver checks whether the combined entries are big enough to store an incoming packet. If not, the driver re-enables notifications with available entries still in the ring. The incorrect return value from vhost_get_avail_idx propagates through vhost_enable_notify and causes the host to livelock if the guest is not making progress, as vhost will immediately disable notifications and retry using the available entries. This goes back to commit d3bb267bbdcb ("vhost: cache avail index in vhost_enable_notify()") which changed vhost_enable_notify() to compare the freshly read avail index against vq->last_avail_idx instead of the previously cached vq->avail_idx. Commit 7ad472397667 ("vhost: move smp_rmb() into vhost_get_avail_idx()") then carried over the same comparison when refactoring vhost_enable_notify() to call the unified vhost_get_avail_idx(). The obvious fix is to make vhost_get_avail_idx do what the comment says it does and report whether new entries have been added. Reported-by: ShuangYu <shuangyu@yunyoo.cc> Fixes: d3bb267bbdcb ("vhost: cache avail index in vhost_enable_notify()") Cc: Stefan Hajnoczi <stefanha@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <559b04ae6ce52973c535dc47e461638b7f4c3d63.1772441455.git.mst@redhat.com>
2026-06-03clk: keystone: sci-clk: fix application of sizeof to pointerJing Yangyang
Coccinelle (scripts/coccinelle/misc/noderef.cocci) reports: drivers/clk/keystone/sci-clk.c:391:8-14: ERROR: application of sizeof to pointer In sci_clk_get(), 'clk' is declared as 'struct sci_clk **', so sizeof(clk) is sizeof(struct sci_clk **) which is the size of a pointer rather than the size of an array element. provider->clocks is an array of 'struct sci_clk *', so the canonical size argument to bsearch() is sizeof(*clk) (i.e. sizeof(struct sci_clk *)). The two values are equal on every supported architecture, so this is correctness/idiom, not a runtime fix, but the new form matches the rest of the bsearch() callers in the tree and silences the Coccinelle warning the script flagged. Reported-by: Zeal Robot <zealci@zte.com.cn> Closes: https://lore.kernel.org/all/84a6ba16686347099a3dab2e5161a930e792eb6e.1629198281.git.jing.yangyang@zte.com.cn/ Reported-by: kernel test robot <lkp@intel.com> Reported-by: Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/all/202512040525.zrHSDl5h-lkp@intel.com/ Link: https://lore.kernel.org/linux-clk/20211012021931.176727-1-davidcomponentone@gmail.com/ Reviewed-by: Stepan Ionichev <sozdayvek@gmail.com> Reviewed-by: Andrew Davis <afd@ti.com> Signed-off-by: Jing Yangyang <jing.yangyang@zte.com.cn> Signed-off-by: David Yang <davidcomponentone@gmail.com> [nm@ti.com: Improved commit message] Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://patch.msgid.link/20260512110028.2999471-1-nm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-06-03clk: keystone: don't cache clock rateMichael Walle
The TISCI firmware will return 0 if the clock or consumer is not enabled although there is a stored value in the firmware. IOW a call to set rate will work but at get rate will always return 0 if the clock is disabled. The clk framework will try to cache the clock rate when it's requested by a consumer. If the clock or consumer is not enabled at that point, the cached value is 0, which is wrong. Thus, disable the cache altogether. Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Reviewed-by: Randolph Sapp <rs@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Antonios Christidis <a-christidis@ti.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Link: https://patch.msgid.link/20260507-clk-sci-v2-1-38f59b48777a@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-06-03net: axienet: Use dedicated ethtool_ops for the dmaengine pathSuraj Gupta
The dmaengine path shares ethtool_ops with the legacy AXI DMA path, including .get_coalesce/.set_coalesce that poke XAXIDMA_*_CR_OFFSET directly. In dmaengine mode lp->dma_regs is not mapped by axienet, so those ethtool calls touch unmapped/unrelated memory and report values unrelated to the channel actually in use. .get_ringparam/.set_ringparam only touch lp->rx_bd_num/lp->tx_bd_num, fields used only by the legacy path for BD ring sizing. In dmaengine mode the descriptor ring is owned by the dmaengine provider and these fields are not consulted, so reporting them is misleading. No dmaengine API exists today to query or program either coalescing or ring size on behalf of the client, so neither can be exposed meaningfully in dmaengine mode. Add axienet_ethtool_dmaengine_ops without the coalesce and ringparam hooks. Also move the ethtool_ops assignment from early probe into the if/else alongside netdev_ops, so the legacy and dmaengine paths pick their respective ops in one place. No functional change for the legacy DMA path. Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260601124454.3384601-1-suraj.gupta2@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03kconfig: add kconfig-sym-check static checkerAndrew Jones
Add 'make kconfig-sym-check', a static checker that finds Kconfig symbols referenced in expressions (select, depends on, default, etc.) but never defined via config/menuconfig anywhere in the tree. New dangling symbols are reported as errors (exit 1) unless they are listed in an exclusion file, e.g. KCONFIG_SYM_CHECK_EXCLUDES=sym-check-excludes make kconfig-sym-check The exclusion file lists one symbol per line; blank lines and lines starting with '#' are ignored. The checker also warns about uppercase N/Y/M used as tristate literal values following the same logic as checkpatch. This new static checker is the script used for [1] with a few improvements to avoid some false positives. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216748 [1] Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Andrew Jones <andrew.jones@linux.dev> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Julian Braha <julianbraha@gmail.com> Tested-by: Nicolas Schier <nsc@kernel.org> Acked-by: Nicolas Schier <nsc@kernel.org> Link: https://patch.msgid.link/20260527142703.107110-1-andrew.jones@linux.dev Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-06-03net/sun: Fix multiple typos in commentsJakub Raczynski
There are some typos in comments and while they are harmless and not visible, there is no reason not to fix them. Fix the ones that are not register related, which might have intentional naming convention. Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com> Link: https://patch.msgid.link/20260601163727.554364-1-j.raczynski@samsung.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03eth: bnxt: disable rx-copybreak by defaultJakub Kicinski
rx-copybreak requires an extra slab allocation. Since bnxt uses page pool frags and HDS by default, the rx-copybreak doesn't buy us anything. The extra pressure on slab causes overload on pre-sheaves kernels on modern AMD platforms. In synthetic testing on net-next this patch shows little difference but I think copybreak is "obvious waste" at this point. Default rx-copybreak threshold to 0 / disabled. The "copybreak" defines are really the size bounds for the Rx header buffer. Rename them. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20260602003759.1545645-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03Merge branch ↵Jakub Kicinski
'fix-use-after-free-in-metadata-dst-teardown-in-airoha_eth-and-mtk_eth_soc-drivers' Lorenzo Bianconi says: ==================== Fix use-after-free in metadata dst teardown in airoha_eth and mtk_eth_soc drivers airoha_metadata_dst_free() and mtk_free_dev() call metadata_dst_free() which frees the metadata_dst with kfree() immediately, bypassing the RCU grace period. Replace metadata_dst_free() with dst_release() which properly goes through the refcount path and runs call_rcu_hurry() if refcount goes to zero. ==================== Link: https://patch.msgid.link/20260602-airoha-mtk-metadata-uaf-fix-v1-0-3aaa99d83351@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03net: ethernet: mtk_eth_soc: Fix use-after-free in metadata dst teardownLorenzo Bianconi
mtk_free_dev() calls metadata_dst_free() which frees the metadata_dst with kfree() immediately, bypassing the RCU grace period. In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from the skb to the metadata_dst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadata_dst_free() calls kfree() directly, a use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadata_dst_free() with dst_release() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via call_rcu_hurry(), ensuring all RCU readers have completed before the memory is freed. Fixes: 2d7605a72906 ("net: ethernet: mtk_eth_soc: enable hardware DSA untagging") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260602-airoha-mtk-metadata-uaf-fix-v1-2-3aaa99d83351@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03net: airoha: Fix use-after-free in metadata dst teardownLorenzo Bianconi
airoha_metadata_dst_free() runs metadata_dst_free() which frees the metadata_dst with kfree() immediately, bypassing the RCU grace period. In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from the skb to the metadata_dst. This function requires RCU read-side protection and the dst must remain valid until all RCU readers complete. Since metadata_dst_free() calls kfree() directly, an use-after-free can occur if any skb still holds a noref pointer to the dst when the driver tears it down. Replace metadata_dst_free() with dst_release() which properly goes through the refcount path: when the refcount drops to zero, it schedules the actual free via call_rcu_hurry(), ensuring all RCU readers have completed before the memory is freed. Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260602-airoha-mtk-metadata-uaf-fix-v1-1-3aaa99d83351@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03ipv6: exthdrs: recompute network header pointer onceJustin Iurman
In ip6_parse_tlv(), recompute the network header pointer once regardless of the option processed (Hbh or Dest), as missing recomputation for specific options has caused issues in the past. Signed-off-by: Justin Iurman <justin.iurman@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260602213033.12244-1-justin.iurman@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04Merge tag 'amd-drm-next-7.2-2026-06-03' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-7.2-2026-06-03: amdgpu: - BT.2020 fix for DCE - DC bounds checking fixes - SDMA 7.1 fix - UserQ fixes - SI fix - SMU 13 fixes - SMU 14 fixes - GC 12.1 fix - Userptr fix - GC 10.1 fix - GART fix for non-4K pages - DCN 4.x fixes - DCN 4.2 updates - More DC KUnit tests - PSR cleanup - Support for connectors without DDC pins - Initial DCN 4.2.1 support - Initial HDMI 2.1 FRL support - Misc bounds check fixes - RAS fixes - GC 11.5.6 support - SDMA 6.4.0 support - NBIO 7.11.5 support - IH 6.4.0 support - HDP 6.4.0 support - MMHUB 3.4.2 support - SMU 15.0.5 support - ATHUB 3.4.2 support - VPE 2.2 support - Devcoredump fixes - _PR3 fix amdkfd: - UAF race fix - Fix a potential NULL pointer dereference - GC 11 buffer overflow fix for SDMA - Profiler locking order fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260604013527.2373534-1-alexander.deucher@amd.com
2026-06-03net: ibm: emac: fix unchecked platform_get_irq return valueRosen Penev
platform_get_irq() returns a negative errno on failure. Commit a598f66d9169 replaced irq_of_parse_and_map() (which returns 0 on failure) with platform_get_irq() but dropped the error check. Without it, a negative IRQ number is passed to devm_request_irq(), which fails with -EINVAL instead of propagating the real error from platform_get_irq(). Add the missing error check and goto err_gone. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260601040201.103481-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03Merge tag 'for-net-2026-06-03' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - hci_core: fix memory leak in error path of hci_alloc_dev() - hci_sync: reject oversized Broadcast Announcement prepend - MGMT: Fix backward compatibility with userspace - MGMT: validate advertising TLV before type checks - L2CAP: reject BR/EDR signaling packets over MTUsig - RFCOMM: validate skb length in MCC handlers - RFCOMM: hold listener socket in rfcomm_connect_ind() - ISO: Fix not releasing hdev reference on iso_conn_big_sync - ISO: Fix a use-after-free of the hci_conn pointer - ISO: Fix data-race on iso_pi fields in hci_get_route calls - SCO: Fix data-race on sco_pi fields in sco_connect - BNEP: reject short frames before parsing * tag 'for-net-2026-06-03' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: MGMT: Fix backward compatibility with userspace Bluetooth: SCO: Fix data-race on sco_pi fields in sco_connect Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls Bluetooth: ISO: Fix a use-after-free of the hci_conn pointer Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync Bluetooth: fix memory leak in error path of hci_alloc_dev() Bluetooth: bnep: reject short frames before parsing Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig Bluetooth: RFCOMM: validate skb length in MCC handlers Bluetooth: MGMT: validate advertising TLV before type checks Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind() ==================== Link: https://patch.msgid.link/20260603162714.342496-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03Merge tag 'wireless-2026-06-03' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Things are finally quieting down: - iwlwifi: - FW reset handshake removal for older devices - NIC access fix in fast resume - avoid too large command for some BIOSes - fix TX power constraints in AP mode - cfg80211: - fix netlink parse overflow - fix potential 6 GHz scan memory leak - enforce HE/EHT consistency to avoid mac80211 crash - mac80211: guard radiotap antenna parsing * tag 'wireless-2026-06-03' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: cfg80211: enforce HE/EHT cap/oper consistency wifi: fix leak if split 6 GHz scanning fails wifi: mac80211: limit injected antenna index in ieee80211_parse_tx_radiotap wifi: nl80211: reject oversized EMA RNR lists wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used wifi: iwlwifi: mvm: avoid oversized UATS command copy wifi: iwlwifi: mld: send tx power constraints before link activation wifi: iwlwifi: mvm: don't support the reset handshake for old firmwares ==================== Link: https://patch.msgid.link/20260603113208.171874-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03x86/cpuid: Update bitfields to x86-cpuid-db v3.1Maciej Wieczor-Retman
Update leaf_types.h to version 3.1, as generated by x86-cpuid-db. Summary of the v3.1 changes: * Fix a few typos that were found during the kernel CPUID data model review. Also include fixes found using an LLM agent review, from Ahmed. * Rename thrd_director_nclasses to hw_feedback_nclasses as it's the name used in Intel SDM. See https://gitlab.com/x86-cpuid.org/x86-cpuid-db/-/blob/v3.1/CHANGELOG.rst for more info. Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/9653d8690ec7093c8190b12d1fa8c689c4da50fe.1780506200.git.m.wieczorretman@pm.me
2026-06-03Merge branch 'mptcp-misc-fixes-for-v7-1-rc7'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: misc fixes for v7.1-rc7 Here are various unrelated fixes: - Patch 1: fix missing wakeups when multiple threads are reading from the same fd. A fix for v5.7. - Patch 2: fix retransmission loop when MPTCP checksum is enabled. A fix for v5.14. - Patch 3: fix a TOCTOU race while computing rcv_wnd. A fix for v5.11. - Patch 4: allow subflows receive window to shrink if needed. A fix for v5.19. - Patches 5-6: avoid 'extra_subflows' to underflow with the userspace PM. A fix for v5.19. - Patch 7: report errors if one subflow cannot set SO_TIMESTAMPING. A fix for v5.14. - Patch 8: try to set TCP_MAXSEG on all subflows, before reporting errors, if any. A fix for v6.17. - Patch 9: check desc->count in read_sock, to act as expected. A fix for v7.0. - Patch 10: fix an uninit value in mptcp_established_options, reported by syzbot. A fix for v7.1-rc1. - Patch 11: fix a similar issue than the previous patch, exposed by the same modification from v7.1-rc1, but was already causing issues since v5.15. ==================== Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-0-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: change mptcp_established_options() to return opt_sizeEric Dumazet
Instead of passing opt_size address to mptcp_established_options(), change this function to return it by value. This removes the need for an expensive stack canary in tcp_established_options() when CONFIG_STACKPROTECTOR_STRONG=y. $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-92 (-92) Function old new delta tcp_options_write.isra 1423 1407 -16 mptcp_established_options 2746 2720 -26 tcp_established_options 553 503 -50 Total: Before=22110750, After=22110658, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260602125138.2317015-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: add-addr: always drop other suboptionsMatthieu Baerts (NGI0)
When an ADD_ADDR needs to be sent, it could be prepared if there is enough remaining space and even if the packet is not a pure ACK. But it would be dropped soon after. Indeed, in mptcp_pm_add_addr_signal(), there is enough space to fit a DSS of 20 octets and an ADD_ADDR echo containing an IPv4 address on 8 octets for example. In this case, the packet would be prepared, the MPTCP_ADD_ADDR_ECHO bit would be removed from pm->addr_signal, but the option would be silently dropped in mptcp_established_options_add_addr() not to override DSS info in the union from 'struct mptcp_out_options', and also because mptcp_write_options() will enforce mutually exclusion with DSS. Instead, don't even try to send an ADD_ADDR if it is not a pure ACK. Retry for each new packet until a pure-ACK is emitted. That's fine to do that, because each time an ADD_ADDR (echo) is scheduled, a pure ACK is queued. This also simplifies the code, and the skb checks can be done earlier, before the lock. Note: also, since commit 6d0060f600ad ("mptcp: Write MPTCP DSS headers to outgoing data packets"), opts->ahmac would not have been set to 0 when other suboptions were not dropped, and when sending an ADD_ADDR echo. That would have resulted in sending an ADD_ADDR using garbage info, where there was not enough space, instead of an echo one without the ADD_ADDR HMAC. Fixes: 1bff1e43a30e ("mptcp: optimize out option generation") Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-11-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: fix uninit-value in mptcp_established_optionsPaolo Abeni
syzbot reported the following uninit splat: BUG: KMSAN: uninit-value in mptcp_write_data_fin net/mptcp/options.c:542 [inline] BUG: KMSAN: uninit-value in mptcp_established_options_dss net/mptcp/options.c:590 [inline] BUG: KMSAN: uninit-value in mptcp_established_options+0x112f/0x3530 net/mptcp/options.c:874 mptcp_write_data_fin net/mptcp/options.c:542 [inline] mptcp_established_options_dss net/mptcp/options.c:590 [inline] mptcp_established_options+0x112f/0x3530 net/mptcp/options.c:874 tcp_established_options+0x312/0xcc0 net/ipv4/tcp_output.c:1192 __tcp_transmit_skb+0x5dc/0x5fe0 net/ipv4/tcp_output.c:1575 __tcp_send_ack+0x967/0xad0 net/ipv4/tcp_output.c:4499 tcp_send_ack+0x3d/0x60 net/ipv4/tcp_output.c:4505 mptcp_subflow_shutdown+0x164/0x690 net/mptcp/protocol.c:3137 mptcp_check_send_data_fin+0x31b/0x3d0 net/mptcp/protocol.c:3218 __mptcp_wr_shutdown net/mptcp/protocol.c:3234 [inline] __mptcp_close+0x860/0x1360 net/mptcp/protocol.c:3313 mptcp_close+0x42/0x260 net/mptcp/protocol.c:3367 inet_release+0x1ee/0x2a0 net/ipv4/af_inet.c:442 __sock_release net/socket.c:722 [inline] sock_close+0xd6/0x2f0 net/socket.c:1514 __fput+0x60e/0x1010 fs/file_table.c:510 ____fput+0x25/0x30 fs/file_table.c:538 task_work_run+0x208/0x2b0 kernel/task_work.c:233 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] __exit_to_user_mode_loop kernel/entry/common.c:67 [inline] exit_to_user_mode_loop+0x306/0x1b60 kernel/entry/common.c:98 __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline] syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:238 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline] __do_fast_syscall_32+0x2c7/0x460 arch/x86/entry/syscall_32.c:310 do_fast_syscall_32+0x37/0x80 arch/x86/entry/syscall_32.c:332 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:370 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Local variable opts created at: __tcp_transmit_skb+0x4d/0x5fe0 net/ipv4/tcp_output.c:1536 __tcp_send_ack+0x967/0xad0 net/ipv4/tcp_output.c:4499 The output path currently omits initializing the mptcp extension `use_map` flag in a few corner cases. Address the issue always zeroing all the extensions flags before eventually initializing the individual bits. To that extent, introduce and use a struct_group to avoid multiple bitwise operations. Fixes: cfcceb7a39fc ("tcp: shrink per-packet memset in __tcp_transmit_skb()") Cc: stable@vger.kernel.org Reported-by: syzbot+ff020673c5e3d94d9478@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ff020673c5e3d94d9478 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/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-10-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: check desc->count in read_sockGang Yan
__tcp_read_sock() checks desc->count after each skb is consumed and breaks the loop when it reaches 0. The MPTCP variant lacks this check. This is a functional bug, other subsystems also rely on this check: TLS strparser sets desc->count to 0 once a full TLS record is assembled and depends on this break to stop reading. Add the same desc->count check to __mptcp_read_sock(), mirroring __tcp_read_sock(). Fixes: 250d9766a984 ("mptcp: implement .read_sock") Cc: stable@vger.kernel.org Co-developed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Geliang Tang <geliang@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/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-9-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: sockopt: set sockopt on all subflowsMatthieu Baerts (NGI0)
The mptcp_setsockopt_all_sf(), currently used only with TCP_MAXSEG, stopped when one subflow returned an error. Even if it is not wrong, this is different from the other helpers trying to set the option on all subflows, and then returning an error if at least one of them had an issue. Follow this behaviour, for a question of uniformity. Fixes: 51c5fd09e1b4 ("mptcp: add TCP_MAXSEG sockopt support") Cc: stable@vger.kernel.org Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-8-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-20 22:56:18 +0000