summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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>
2026-06-03mptcp: sockopt: check timestamping ret valueMatthieu Baerts (NGI0)
sock_set_timestamping() can fail for different reasons. The returned value should then be checked. If sock_set_timestamping() fails for at least one subflow, the first error is now reported to the userspace, similar to what is done with other socket options. Fixes: 9061f24bf82e ("mptcp: sockopt: propagate timestamp request to subflows") Cc: stable@vger.kernel.org Reported-by: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Closes: https://lore.kernel.org/willemdebruijn.kernel.178a41a53d041@gmail.com 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-7-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03selftests: mptcp: add test for extra_subflows underflow on userspace PMTao Cui
Add a test to verify that when userspace PM fails to create a subflow (e.g. using an unreachable address), the extra_subflows counter is not decremented below zero. Fixes: 77e4b94a3de6 ("mptcp: update userspace pm infos") Cc: stable@vger.kernel.org Signed-off-by: Tao Cui <cuitao@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-6-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: pm: fix extra_subflows underflow on userspace PM subflow creationTao Cui
The userspace PM increments extra_subflows after __mptcp_subflow_connect() succeeds, but __mptcp_subflow_connect() calls mptcp_pm_close_subflow() on failure to roll back the pre-increment done by the kernel PM's fill_*() helpers. Because the userspace PM hasn't incremented yet at that point, this decrement is spurious and causes extra_subflows to underflow. Fix it by aligning the userspace PM with the kernel PM: increment extra_subflows before calling __mptcp_subflow_connect(), so the existing error path in subflow.c correctly rolls it back on failure. Also simplify the error handling by taking pm.lock only when needed for cleanup. Fixes: 77e4b94a3de6 ("mptcp: update userspace pm infos") Cc: stable@vger.kernel.org Signed-off-by: Tao Cui <cuitao@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-5-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: allow subflow rcv wnd to shrinkPaolo Abeni
In MPTCP connection, the `window` field in the TCP header refers to the MPTCP-level rcv_nxt and it's right edge should not move backward. Such constraint is enforced at DSS option generation time. At the same time, the TCP stack ensures independently that the TCP-level rcv wnd right's edge does not move backward. That in turn causes artificial inflating of the MPTCP rcv window when the incoming data is acked at the TCP level and is OoO in the MPTCP sequence space (or lands in the backlog). As a consequence, the incoming traffic can exceed the receiver rcvbuf size even when the sender is not misbehaving. Prevent such scenario forcibly allowing the TCP subflow to shrink the TCP-level rcv wnd regardless of the current netns setting. Fixes: f3589be0c420 ("mptcp: never shrink offered window") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-4-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: close TOCTOU race while computing rcv_wndPaolo Abeni
The MPTCP output path access locklessly the MPTCP-level ack_seq in multiple times, using possibly different values for the data_ack in the DSS option and to compute the announced rcv wnd for the same packet. Refactor the cote to avoid inconsistencies which may confuse the peer. Also ensure that the MPTCP level rcv wnd is updated only when the egress packet actually contains a DSS ack. Fixes: fa3fe2b15031 ("mptcp: track window announced to peer") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-3-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: fix retransmission loop when csum is enabledPaolo Abeni
Sashiko noted that retransmission with csum enabled can actually transmit new data, but currently the relevant code does not update accordingly snd_nxt. The may cause incoming ack drop and an endless retransmission loop. Address the issue incrementing snd_nxt as needed. Fixes: 4e14867d5e91 ("mptcp: tune re-injections for csum enabled mode") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-2-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03mptcp: fix missing wakeups in edge scenariosPaolo Abeni
The mptcp_recvmsg() can fill MPTCP socket receive queue via mptcp_move_skbs(), but currently does not try to wakeup any listener, because the same process is going to check the receive queue soon. When multiple threads are reading from the same fd, the above can cause stall. Add the missing wakeup. Fixes: 6771bfd9ee24 ("mptcp: update mptcp ack sequence from work queue") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260602-net-mptcp-misc-fixes-7-1-rc7-v2-1-856831229976@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03drivers/of: fdt: Make ibm,phandle logic only happen on pseriesDaniel Palmer
The "ibm,phandle" thing only seems to be needed on pseries machines but everyone gets it so they get a string and a little bit of useless code. In __of_attach_node() the pseries specific part uses IS_ENABLED(CONFIG_PPC_PSERIES) so do that here too. Signed-off-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260603151809.3256280-1-daniel@thingy.jp Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-06-03tools/x86/kcpuid: Update bitfields to x86-cpuid-db v3.1Maciej Wieczor-Retman
Update kcpuid's CSV file 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. * 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/cbe9ff395b3269e112ff7ca414d726ffd7bf0787.1780506200.git.m.wieczorretman@pm.me
2026-06-03ptp: vclock: Switch from RCU to SRCUKurt Kanzenbach
The usage of PTP vClocks leads immediately to the following issues with ptp4l with LOCKDEP and DEBUG_ATOMIC_SLEEP enabled: "BUG: sleeping function called from invalid context". ptp_convert_timestamp() acquires a mutex_t within a RCU read section. This is illegal, because acquiring a mutex_t can result in voluntary scheduling request which is not allowed within a RCU read section. Replace the RCU usage with SRCU where sleeping is allowed. Reported-by: Florian Zeitz <florian.zeitz@schettke.com> Closes: https://lore.kernel.org/all/00a8cce8-410e-4038-98af-49be6d93d7bd@schettke.com/ Fixes: 67d93ffc0f3c ("ptp: vclock: use mutex to fix "sleep on atomic" bug") Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://patch.msgid.link/20260529-vclock_rcu-v2-1-02a5531fab92@linutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03ipv4: raw: remove six obsolete EXPORT_SYMBOL_GPL()Eric Dumazet
IPv6 can not be a module anymore, we no longer need to export: - raw_hash_sk() - raw_unhash_sk() - raw_abort() - raw_seq_start() - raw_seq_next() - raw_seq_stop() Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260602165036.2712408-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03ipv4: restrict IPOPT_SSRR and IPOPT_LSRR optionsEric Dumazet
This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAP_NET_RAW capability. This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information. While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths. RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Tamir Shahar <tamirthesis@gmail.com> Reported-by: Amit Klein <aksecurity@gmail.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260602161547.2642155-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-03Merge branch 'af_unix-fix-inq_len-update-issue'Jakub Kicinski
Jianyu Li says: ==================== af_unix: Fix inq_len update issue From: Jianyu Li <jianyu.li@mediatek.com> This series fix the problem that inq_len is inconsistent with actual remaining byte count when only part of a skb is consumed. ==================== Link: https://patch.msgid.link/20260601113640.231897-1-jianyu.li@mediatek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-14 07:52:04 +0000