summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
8 daysusb: dwc3: qcom: Add support to skip phy management by USB coreKrishna Kurapati
DWC3 driver does manage phys itself sufficiently for Qualcomm platforms. If xhci-skip-phy-init is not set, the HCD core does a phy_init and phy_ exit is done only when roothub is being destroyed. Due to this, during system suspend in host mode, although phy_exit is done by DWC3 core, the init_count on phy is never down to zero since HCD core also did an init. consequently causing phy's exit routine to not be called. Hence, add support to skip phy management by USB core. Some Exynos platforms still do rely on USB core for phy_calibrate calls, hence disable USB core management for Qualcomm platforms only. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://patch.msgid.link/20260723-dwc3-skip-init-quirk-v1-1-97682bb44ebd@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysHID: bpf: mark struct hid_device as safe BPF pointerBenjamin Tissoires
Commit ee9ad135b208 ("bpf: Reject a store through a fault prone pointer") in the BPF tree makes the verifier reject any writes to hid_device->{name,uniq,phys}. A simple solution is to mark the struct hid_device as safe from a BPF point of view. Suggested-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
8 daysPCI: cadence: Fix enum type mismatch warning in LTSSM debugfsHans Zhang
Fix Clang -Wenum-compare-conditional warning by using a single u32 variable to hold the LTSSM status value, replacing two separate enum variables of different types. Fixes: d70e964dc099 ("PCI: cadence: Add LGA IP debugfs for LTSSM status") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202608201933.w2579mwx-lkp@intel.com/ Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Aksh Garg <a-garg7@ti.com> Link: https://patch.msgid.link/20260820232305.80596-1-18255117159@163.com
8 daysIB/mlx4: Fix use-after-free on pkey sysfs registration failureShuangpeng Bai
register_pkey_tree() ignores errors from register_one_pkey_tree() and continues registering the remaining slaves. The per-slave error path has already released the pkey parent kobjects, but their pointers remain stored in the device. A later device cleanup therefore passes the stale pointers to kobject_put(), causing a use-after-free. Clear the parent pointers after releasing a failed slave tree and skip unregistered trees during device cleanup. This preserves the existing best-effort registration behavior while preventing a second cleanup of the failed tree. Fixes: c1e7e466120b ("IB/mlx4: Add iov directory in sysfs under the ib device") Cc: stable@vger.kernel.org Signed-off-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com> Link: https://patch.msgid.link/20260816044510.3848996-1-shuangpeng.kernel@gmail.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysRDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependencyOr Har-Toov
Commit 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages") introduced disassociation_lock to protect new mmap registrations against uverbs_user_mmap_disassociate(), but created an ABBA deadlock: Thread A (mmap / fork): mmap_lock -> disassociation_lock Thread B (disassociate): disassociation_lock -> mmap_lock Fix by removing disassociation_lock entirely and using the pre-existing hw_destroy_rwsem instead. hw_destroy_rwsem already provides the same protection: rdma_umap_open() and ib_uverbs_mmap() both use down_read_trylock() before registering a new VMA, so holding hw_destroy_rwsem in uverbs_user_mmap_disassociate() is sufficient to block new registrations. trylock is used in both mmap paths (not blocking down_read) because mmap_lock is already held on entry, and uverbs_user_mmap_disassociate() acquires mmap_lock internally — a blocking read would recreate the same deadlock. The only caller that was not taking hw_destroy_rwsem for write was rdma_user_mmap_disassociate(). Fix it to take the rwsem per-ufile while iterating under lists_mutex. This is safe because ib_uverbs_close() releases hw_destroy_rwsem entirely before acquiring lists_mutex, so the two locks are never held simultaneously. lockdep warning: [ 776.654252] ====================================================== [ 776.655214] WARNING: possible circular locking dependency detected [ 776.656167] 6.18.0for-upstream_debug_94e244d9ccab #1 Not tainted [ 776.657114] ------------------------------------------------------ [ 776.658087] devlink/14824 is trying to acquire lock: [ 776.658879] ffff88811170c800 (&mm->mmap_lock){++++}-{4:4}, at: uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs] [ 776.660479] [ 776.660479] but task is already holding lock: [ 776.661460] ffff888142d92b08 (&file->disassociation_lock){+.+.}-{4:4}, at: uverbs_user_mmap_disassociate+0x39/0x780 [ib_uverbs] [ 776.663177] [ 776.663177] which lock already depends on the new lock. [ 776.663177] [ 776.664525] [ 776.664525] the existing dependency chain (in reverse order) is: [ 776.665724] [ 776.665724] -> #2 (&file->disassociation_lock){+.+.}-{4:4}: [ 776.666887] __mutex_lock+0x16d/0x2330 [ 776.667633] rdma_umap_open+0x129/0x280 [ib_uverbs] [ 776.668489] dup_mmap+0xa40/0x1790 [ 776.669170] copy_process+0x5dd2/0x6170 [ 776.669933] kernel_clone+0xb6/0x610 [ 776.670636] __do_sys_clone+0xb5/0xf0 [ 776.671354] do_syscall_64+0x70/0x12e0 [ 776.672083] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.672940] [ 776.672940] -> #1 (&mm->mmap_lock/1){+.+.}-{4:4}: [ 776.673985] down_write_nested+0x90/0x1e0 [ 776.674751] dup_mmap+0x201/0x1790 [ 776.675448] copy_process+0x5dd2/0x6170 [ 776.676180] kernel_clone+0xb6/0x610 [ 776.676904] __do_sys_clone+0xb5/0xf0 [ 776.677615] do_syscall_64+0x70/0x12e0 [ 776.678351] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.679239] [ 776.679239] -> #0 (&mm->mmap_lock){++++}-{4:4}: [ 776.680253] __lock_acquire+0x18c6/0x2ec0 [ 776.681018] lock_acquire+0x10e/0x2e0 [ 776.681742] down_read+0x95/0x430 [ 776.682395] uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs] [ 776.683436] uverbs_destroy_ufile_hw+0x1ae/0x270 [ib_uverbs] [ 776.684416] ib_uverbs_remove_one+0x22b/0x420 [ib_uverbs] [ 776.685371] remove_client_context+0xa6/0xf0 [ib_core] [ 776.686342] disable_device+0x12b/0x240 [ib_core] [ 776.687249] __ib_unregister_device+0x269/0x460 [ib_core] [ 776.688233] ib_unregister_device+0x21/0x30 [ib_core] [ 776.689140] mlx5r_remove+0xd0/0x170 [mlx5_ib] [ 776.689999] device_release_driver_internal+0x3b2/0x560 [ 776.694876] bus_remove_device+0x1f5/0x3e0 [ 776.695638] device_del+0x3b9/0x990 [ 776.696329] mlx5_detach_device+0x17e/0x350 [mlx5_core] [ 776.697429] mlx5_unload_one_devl_locked+0x3f/0xb0 [mlx5_core] [ 776.698578] mlx5_devlink_reload_down+0x1f9/0x550 [mlx5_core] [ 776.699712] devlink_reload+0x13e/0x680 [ 776.700456] devlink_nl_reload_doit+0xc29/0x1160 [ 776.701293] genl_family_rcv_msg_doit+0x1c9/0x2a0 [ 776.702135] genl_rcv_msg+0x3f0/0x6b0 [ 776.702854] netlink_rcv_skb+0x11d/0x370 [ 776.703605] genl_rcv+0x24/0x40 [ 776.704236] netlink_unicast+0x5b4/0x970 [ 776.704984] netlink_sendmsg+0x730/0xbf0 [ 776.705748] __sock_sendmsg+0xc5/0x190 [ 776.706461] __sys_sendto+0x201/0x2f0 [ 776.707188] __x64_sys_sendto+0xdc/0x1b0 [ 776.707931] do_syscall_64+0x70/0x12e0 [ 776.708643] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.709546] [ 776.709546] other info that might help us debug this: [ 776.709546] [ 776.710910] Chain exists of: [ 776.710910] &mm->mmap_lock --> &mm->mmap_lock/1 --> &file->disassociation_lock [ 776.710910] [ 776.712805] Possible unsafe locking scenario: [ 776.712805] [ 776.713828] CPU0 CPU1 [ 776.714589] ---- ---- [ 776.715347] lock(&file->disassociation_lock); [ 776.716097] lock(&mm->mmap_lock/1); [ 776.717067] lock(&file->disassociation_lock); [ 776.718199] rlock(&mm->mmap_lock); [ 776.718857] [ 776.718857] *** DEADLOCK *** Fixes: 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages") Signed-off-by: Or Har-Toov <ohartoov@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260811-fix-mmap-lockdep-v1-1-1151b41063b4@nvidia.com Acked-by: Junxian Huang <huangjunxian6@hisilicon.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysMerge patch series "usb: gpio-sbu-mux: add FUSB340 and enable option for ↵Greg Kroah-Hartman
orientation" Fabrice Gasnier <fabrice.gasnier@foss.st.com> says: Add a new compatible for FUSB340. Also manage the enable GPIO, when used as orientation-switch only. It is used on STM32MP25 DK boards, as orientation-switch only for USB SuperSpeed lines on the Type-C connector, the enable GPIO being connected to the SoC. - - - - SoC - - - - - - - - - - board - - - - - | USB-C +------+ +----------+ | +-+ | |--| USB2PHY |<-----------------HS->|*| | |--| HS |<-----------------HS->|*| | | +----------+ | | | | | | ________ | | + dwc3 | +----------+ | / |<-SS->|*| | | | |<--->/ |<-SS->|*| | |--| ComboPHY |<---> FUSB340 | | | | | | SS | | \ __ |<-SS->|*| +------+ +----------+ | \_en__sw_|<-SS->|*| | ^ ^ | | +----------+ | | | ... [ GPIO ]--------+ | [ GPIO ]------------+ +----------+ | - - - - - - - - - - - - - - - - - - - - - - -- This is a subset of STM32MP25 Type-C support [1]. [1] https://lore.kernel.org/all/20260821-ucpd-host-fusb340-v7-2-rfc-v1-0-c5e27cbc0795@foss.st.com/ Link: https://patch.msgid.link/20260826-usb-fusb340-v1-v3-0-11927682504d@foss.st.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysusb: typec: mux: gpio-sbu: enable when only used for orientationFabrice Gasnier
When used as orientation-switch only (no mode-switch, e.g. no altmode), the optional enable gpio remains disabled. Enable it from the switch_set() routine, in this case, when the orientation is set and the enable-gpios property has been provided. Move enable GPIO configuration after the swapped configuration has been done, to avoid possible glitches in case both signals are changed. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260826-usb-fusb340-v1-v3-2-11927682504d@foss.st.com
8 daysstaging: rtl8723bs: avoid CamelCase in rtw_efusePhilip Nielsen
Avoid CamelCase naming for local variables, function parameters, and static helper functions in rtw_efuse.c as well as associated prototypes in rtw_efuse.h to adhere to the Linux kernel coding style and clear checkpatch.pl checks. Signed-off-by: Philip Nielsen <philipnielsen64@gmail.com> Link: https://patch.msgid.link/20260901103919.20245-1-philipnielsen64@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: sm750fb: fix mono image source stride mismatch in ↵Muhammad Bilal
lynxfb_ops_imageblit() sm750_hw_imageblit() advances its monochrome source pointer by src_delta per scanline, and computes the correct rounded-up stride internally as: bytes_per_scan = (width + start_bit + 7) / 8; Its only caller, lynxfb_ops_imageblit(), instead passed src_delta as image->width >> 3. For widths not a multiple of 8 this under-counted the stride, so the source pointer fell further behind the real per-scanline layout on every line, corrupting the rendered image. Rather than just fixing the caller's calculation, remove src_delta as a parameter entirely and have sm750_hw_imageblit() advance by the bytes_per_scan it already computes for itself. There has only ever been one caller, and that caller was passing an out-of-sync derivative of the same width/start_bit values sm750_hw_imageblit() already has, so keeping stride as a separate parameter served no purpose beyond letting the two calculations drift apart, which is exactly what happened here. Rounding up, rather than down, is the direction consistent with the rest of the fbdev core: struct fb_image mono bitmap data (the same image->data this driver receives) is walked elsewhere with byte strides derived from a ceiling division of width by 8. The generic mono bit iterator in drivers/video/fbdev/core/fb_imageblit.h advances scanlines with "iter->data += BITS_TO_BYTES(iter->width)", and BITS_TO_BYTES() (include/linux/bitops.h) is a ceiling division. sm750_hw_imageblit()'s own "(width + start_bit + 7) / 8" is that same ceiling division with an added start_bit offset, so the caller's ">> 3" (floor) was the one calculation out of step with how this data layout is handled everywhere else. Found by code review of sm750_hw_imageblit()'s internal stride calculation against what its only caller was passing in, and confirmed with a clean -Werror build. I do not have this hardware, so this has not been exercised at runtime on real sm750 silicon. Fixes: 81dee67e215b2 ("staging: sm750fb: add sm750 to staging") Cc: stable@vger.kernel.org Reviewed-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Muhammad Bilal <meatuni001@gmail.com> Link: https://patch.msgid.link/20260901113031.161610-1-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysRDMA/core: Reject unregistering netdevs in ib_get_eth_speedKrystian Kaniewski
ib_device_get_netdev() intentionally returns a referenced net_device even when it is unregistering, so matching and cleanup callers can still find the association. The reference keeps struct net_device allocated, but does not guarantee that the device remains operational. ib_get_eth_speed() uses the returned device operationally by invoking its ethtool callback. Although that call is made under RTNL, the function does not verify the registration state first. An asynchronous RDMA port query can therefore call into a netdev after NETDEV_UNREGISTER and ndo_uninit have completed. Check for NETREG_REGISTERED while holding RTNL and return -ENODEV for a device which is being unregistered. Keeping RTNL across the check and the ethtool operation prevents unregister from starting between them. Keep the speed fallback and warning under RTNL as well, so the warning can safely read netdev->name. Drop the netdev reference before releasing RTNL once all accesses to the device are complete. Fixes: d41861942fc5 ("IB/core: Add generic function to extract IB speed from netdev") Reported-by: syzbot+5fe14f2ff4ccbace9a26@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=5fe14f2ff4ccbace9a26 Signed-off-by: Krystian Kaniewski <krystianmkaniewski@gmail.com> Link: https://patch.msgid.link/20260812081708.32468-1-krystianmkaniewski@gmail.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysRDMA/mlx5: Remove obsolete 32-bit DMA mask fallbackRuizhe Zhou
The DMA API guarantees support for masks of 32 bits or wider and explicitly identifies retrying a 32-bit mask after a 64-bit request as incorrect: https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities Remove the obsolete fallback from data direct while retaining the error check so that a genuine DMA setup failure is still reported and aborts initialization. Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com> Link: https://patch.msgid.link/20260812033647.2281547-3-zhouruizhe@resnics.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysRDMA/hfi1: Remove obsolete 32-bit DMA mask fallbackRuizhe Zhou
The DMA API guarantees support for masks of 32 bits or wider and explicitly identifies retrying a 32-bit mask after a 64-bit request as incorrect: https://docs.kernel.org/core-api/dma-api-howto.html#dma-addressing-capabilities Remove the obsolete fallback while retaining the error check so that a genuine DMA setup failure is still reported and aborts initialization. Signed-off-by: Ruizhe Zhou <zhouruizhe@resnics.com> Link: https://patch.msgid.link/20260812033647.2281547-2-zhouruizhe@resnics.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysRDMA/mlx5: Remove warn on missing representor in query_port_speedOr Har-Toov
The representor ib_device's phys_port_cnt is set to the total vport count when the uplink vport rep loads. Individual port[i].rep entries are populated only as each VF/SF vport rep registers. A NULL .rep for a given port index is therefore expected while VF reps are still loading or haven't been enabled yet. Tools like ibstat and ibv_devinfo iterate over all ports of all RDMA devices. Some ports may not have an eswitch representor, causing repeated dmesg warnings when these tools run without a device argument. This causes dmesg to be flooded with this message on every ibstat invocation. Remove the warning and return -ENODEV when no representor exists for the queried port. Fixes: aaecff5e13cd ("RDMA/mlx5: Implement query_port_speed callback") Signed-off-by: Or Har-Toov <ohartoov@nvidia.com> Reviewed-by: Shay Drory <shayd@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Link: https://patch.msgid.link/20260811-remove-warn-on-miss-rep-v1-1-eccf399bc6af@nvidia.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysIB/hfi1: Fix the PIO_CRED credit-return mmapShuhei Takeshita
hfi1_file_mmap()'s PIO_CRED case must hand user space the single credit-return page that holds this context's entry. That page is the second or third page of the per-node credit-return allocation once the hardware send context index reaches 64 or 128, so the failure below is intermittent: when the entry lands on the first page the offset is zero and everything works. Two things are wrong. First, cr_page_offset is a byte offset but .va is a struct credit_return *, so adding it is pointer arithmetic and scales the offset by sizeof(struct credit_return) == 64. memvirt then lands 256 KiB or 512 KiB past a 10240-byte allocation. With an IOMMU translating, that address is inside the vmalloc range but in no vm_area, so dma_mmap_coherent() -> iommu_dma_mmap() finds no pages, vmalloc_to_pfn() returns page_to_pfn(NULL), and remap_pfn_range() installs a frame above MAXPHYADDR. The first user read then takes: psm2_ep_open_pr: Corrupted page table at address 7a14d007e000 PGD 800000013886a067 P4D 800000013886a067 PUD 13886b067 PMD 13886c067 PTE 800049168e911235 Oops: Bad pagetable: 000d [#1] SMP PTI Second, and still wrong once the arithmetic is corrected, dma_mmap_coherent() describes a whole coherent buffer and selects the page within it with vma->vm_pgoff. Offsetting cpu_addr has no effect: for a vmap'd allocation iommu_dma_mmap() uses cpu_addr only to locate the vm_area and then maps pages[vm_pgoff], which hfi1_file_mmap() has just set to 0. User space therefore always receives the first credit-return page, every credit read is for the wrong context, and send PIO stalls forever. Use the DMA API as intended: pass the base of the allocation with its full length and select the page with vm_pgoff. A separate length is needed because memlen must keep describing the VMA for the existing size check. The dma-direct path stays correct as well, since dma_direct_mmap() adds the same vm_pgoff to the base pfn. Tested on a Dell T7610 (Xeon E5-2650 v2, Intel IOMMU in DMA-FQ mode) against a Threadripper PRO 3995WX peer, both Omni-Path 100. Before this change psm2_ep_open() Oopses the kernel; with only the arithmetic corrected psm2_ep_open() succeeds but any transfer that uses send PIO hangs, PSM2_SDMA=2 (send PIO disabled) completing normally while PSM2_SDMA=0 (send PIO only) hangs every time. With this change send PIO, send DMA and the default mixed mode all work. Fixes: 1ec82317a1da ("IB/hfi1: Use dma_mmap_coherent for matching buffers") Cc: stable@vger.kernel.org Signed-off-by: Shuhei Takeshita <jyohuku.alterego@gmail.com> Link: https://patch.msgid.link/20260809032743.2671579-3-jyohuku.alterego@gmail.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysIB/hfi1: Resolve the credit-return buffer through the send context's nodeShuhei Takeshita
hfi1_file_mmap()'s PIO_CRED case derives this context's credit-return page offset, and the DMA handle for it, from dd->cr_base[uctxt->numa_id]. uctxt->numa_id is the node of whichever CPU the process happened to be running on, but the entry itself lives in the credit-return allocation of the send context's own node: sc->hw_free = &sc->dd->cr_base[sc->node].va[gc].cr[index]; and user send contexts are allocated with sc_alloc(dd, SC_USER, ..., dd->node), the HFI-local node. On a multi-socket host with the process running off that node the two allocations differ, so the subtraction produces an offset into an unrelated buffer and the DMA handle belongs to the wrong allocation. Use the send context's own node for all three references. The continuation lines are reindented at the same time; they mixed spaces and tabs. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Cc: stable@vger.kernel.org Signed-off-by: Shuhei Takeshita <jyohuku.alterego@gmail.com> Link: https://patch.msgid.link/20260809032743.2671579-2-jyohuku.alterego@gmail.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysRDMA/rxe: Hold netdev reference for transmit skbsxiongweimin
rxe_init_packet() assigns skb->dev from an RCU-protected GID attribute without holding a netdev reference. If the netdev is unregistered before the skb is freed, subsequent accesses to skb->dev are unsafe. Hold a reference with dev_hold() when the skb is initialized and release it from the transmit destructor or via rxe_put_skb() on error paths that run before the destructor is installed. skb->dev can change on the TX path (VLAN/bond/tunnel, ip_finish_output2, etc.), so put must use the same netdev that was held. Stash that pointer in skb_shinfo()->destructor_arg: skb->cb is already used by rxe_pkt_info and is rewritten by IP control blocks. To avoid blocking netdev unregistration on held skbs, flush all QPs to the error state on NETDEV_GOING_DOWN and NETDEV_UNREGISTER so pending TX work is drained and references can be dropped. Signed-off-by: xiongweimin <xiongweimin@kylinos.cn> Link: https://patch.msgid.link/20260716055255.157674-1-xiongwm2026@163.com Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysdm cache: fix demotion stats in passthrough modeMing-Hung Tsai
The demotion counter is incremented per incoming write bio before the invalidation begins, causing the demotion count to exceed the actual number of cached blocks when multiple bios target the same cached block. Additionally, the counter is incremented unconditionally regardless of invalidation failure. Reproduce steps: 1. Create a cache device consisting of 512 cache entries modprobe brd rd_size=262144 dmsetup create cmeta --table "0 8192 linear /dev/ram0 0" dmsetup create cdata --table "0 65536 linear /dev/ram0 8192" dmsetup create corig --table "0 65536 linear /dev/ram0 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 65536 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. Populate the cache, and record the number of cached blocks fio --name=populate --filename=/dev/mapper/cache --rw=randwrite --bs=4k \ --direct=1 --ioengine=libaio --iodepth=32 --io_size=2048m nr_cached=$(dmsetup status cache | awk '{split($7, a, "/"); print a[1]}') 3. Reload the cache into passthrough mode dmsetup suspend cache dmsetup reload cache --table "0 65536 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 passthrough smq 0" dmsetup resume cache 4. Write to the passthrough cache with multiple jobs to trigger multiple bios hitting the same cached block. fio --filename=/dev/mapper/cache --name=test --rw=write --bs=4k \ --direct=1 --ioengine=libaio --iodepth=32 --numjobs=4 5. Check if demoted matches cached block count. These numbers should match but may differ due to overcounting per bio. nr_demoted=$(dmsetup status cache | awk '{print $12}') echo "$nr_cached, $nr_demoted" Fix by moving the demotion counter increment into invalidate_complete(), gated on the success flag. Reported-by: Ben Marzinski <bmarzins@redhat.com> Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Cc: stable@vger.kernel.org Signed-off-by: Ming-Hung Tsai <mtsai@redhat.com> Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
8 daysnet: stmmac: Remove ARP offload codeMaxime Chevallier
dwmac can do ARP offloading, where the HW replies to incoming ARP requests. This requires multiple steps to work well : - Program the local IP address in a dedicated register - Enable ARP offloading This is halfway implemented in stmmac, as it's only ever used by selftests, and these selftests are failing on at least 2 platforms : stm32mp1, and jh7110. There have been some attempts in the past to support this feature, but this never made it upstream. Let's just remove the test and that code, until someone actually wants that to work. We should likely have a proper API for that so that drivers can use it. Let's also not mention ARP offload in the stmmac documentation. Leave the defines in place and the capability detection, this doesn't hurt and gives some information about how the IP is synthesized. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Link: https://patch.msgid.link/20260831071351.354255-1-maxime.chevallier@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysRDMA/rxe: insert mcg into mcg_tree only after rxe_mcast_add() succeedsMichael Bommarito
rxe_get_mcg() publishes a newly allocated multicast group in rxe->mcg_tree before programming the backing Ethernet multicast address with rxe_mcast_add(), which runs outside mcg_lock. A local userspace RDMA client reaches this path with ATTACH_MCAST on a UD QP; if rxe_mcast_add() then returns an error (for example -ENODEV when the backing netdev has been removed, or a propagated dev_mc_add() error), the unwind frees the published group without removing it from the tree. A later lookup of the same MGID dereferences the freed struct rxe_mcg from __rxe_lookup_mcg(). Fix this by keeping the new mcg private until rxe_mcast_add() succeeds. Split the tree publication into __rxe_publish_mcg(), call rxe_mcast_add() before taking the tree reference, and free the still-private mcg on failure. Because the group is never visible in mcg_tree until the multicast address is programmed, no concurrent caller can look it up or attach a QP to a group that is about to be torn down, so the error path needs no conditional unwind. If another caller publishes the same MGID while the address is being programmed, the post-add re-check under mcg_lock finds the winner; this caller then drops its private object and balances its own rxe_mcast_add() with rxe_mcast_del() before returning the winner. Reproduced by forcing the rxe_mcast_add() error return under KASAN: without the change the next attach to the same MGID reports a slab-use-after-free in __rxe_lookup_mcg(); with it the forced failure returns cleanly. A no-injection attach/detach regression, including a two-QP shared join/leave and re-attach, stays KASAN- and leak-clean. Fixes: a926a903b7dc ("RDMA/rxe: Do not call dev_mc_add/del() under a spinlock") Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Link: https://patch.msgid.link/20260617022728.2770116-1-michael.bommarito@gmail.com Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysRDMA/mana_ib: fixed send wqe size support for RC QPsKonstantin Taranov
Support fixed-size send WQEs for RC QPs when requested by userspace. Calculate the WQE size from the maximum send SGE count and the 32-byte inline OOB size, round it up to a power of two, and pass the size to hardware in basic units. When supported by the adapter, also enable placing the message sequence number in the WQE. Preserve the existing variable-size WQE behavior when userspace does not request fixed-size WQEs. Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://patch.msgid.link/20260827143736.2013093-4-kotaranov@linux.microsoft.com Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysRDMA/mana_ib: MMQ creation for RC QPsKonstantin Taranov
Create an MMQ for an RC QP when userspace sets the corresponding compatibility-mask flag. Register the userspace MMQ buffer and pass the queue to hardware instead of setting the NO_MMQ creation flag. Keep the MMQ disabled for applications that do not request it, preserving the existing behavior. Return the created MMQ ID to userspace in the extended RC QP response. Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://patch.msgid.link/20260827143736.2013093-3-kotaranov@linux.microsoft.com Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysRDMA/mana_ib: Extend RC QP udata request and responseKonstantin Taranov
Extend the RC QP creation UAPI to support optional fixed-size WQEs and an MMQ. Add a compatibility mask to the request, return the MMQ ID in the response, and advertise the extended ABI through ucontext capabilities. Use compatibility-aware udata validation so existing userspace remains supported. Rename the legacy FMR queue definitions to MMQ and add the corresponding hardware creation flags. Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com> Link: https://patch.msgid.link/20260827143736.2013093-2-kotaranov@linux.microsoft.com Reviewed-by: Long Li <longli@microsoft.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysPCI: qcom: Block accesses to downstream devices on link downQiang Yu
After a PCIe link goes down, software may still access the BAR (MMIO) space or configuration space of devices behind that link before recovery has run. As the link is down, these accesses never complete, resulting in a storm of Completion Timeout AERs. Use the controller's ECAM blocker to drop these accesses to the PCIe address space as soon as the link-down interrupt fires, so that Completion Timeout AERs are reduced. The blocked range covers the entire address space (base 0x0, all-ones limit), since the Root Port's own DBI/iATU register space remains accessible regardless. The range is programmed once in the host init path, since the range registers are wiped by BCR reset. This leaves only the ECAM_BLOCKER_EN bit to be flipped from the link-down IRQ handler, so the blocker can be armed with a single fast register write for immediate effect. The subsequent Root Port reset re-initialises the controller, which clears the enable bit and re-programs the range for the fresh link. Some IP revisions implement the ECAM blocker registers but do not wire up the "global" interrupt used to deliver the link-down event that arms the blocker, so there is no way to enable the blocker on those platforms. Restrict blocker initialization to the post_init hooks of the IP revisions that do have a global IRQ wired up (qcom_pcie_post_init_2_3_3(), qcom_pcie_post_init_2_7_0() and qcom_pcie_post_init_2_9_0()), instead of unconditionally programming it from the common host_init path. The link-down IRQ thread's blocker-enable write to PARF_SYS_CTRL can race with a Root Port reset triggered independently through AER, which reprograms PARF_SYS_CTRL as part of reinitializing the controller. Serialize these with a per-controller mutex. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> [mani: renamed hw_lock to reset_lock and used guard(mutex)] Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # X1E80100 CRD + ASUS PA27AC Link: https://patch.msgid.link/20260819-ecam_blocker-v2-1-e7a8fdc1c5cb@oss.qualcomm.com
8 daysRDMA/rxe: Restore HMM_PFN_WRITE check in ODP write pathsWeiming Shi
Commit 0b261d7c1cd3 ("RDMA/rxe: Break endless pagefault loop for RO pages") dropped the access permission test from rxe_check_pagefault() and left only HMM_PFN_VALID. A page faulted in read-only, for example a page-cache folio behind a PROT_READ file mapping, then satisfies the check and ODP write operations (RDMA WRITE, RDMA READ response, SEND payload, atomics) modify it through kmap without ever breaking CoW. An unprivileged user can register an ODP MR over such a mapping and have incoming RDMA traffic overwrite the page cache of a file it only holds O_RDONLY, including /etc/passwd or setuid binaries. This is the same primitive class as Dirty COW and CVE-2022-2590. mlx5 has the missing invariant: its ODP path sets the device write bit only for pfns that carry HMM_PFN_WRITE. Restore it in rxe by requiring HMM_PFN_WRITE in rxe_check_pagefault() for every operation except RXE_PAGEFAULT_RDONLY. A write to a non-writable VMA now fails the one fault attempt with -EPERM from hmm_vma_fault() instead of re-faulting forever. For a writable VMA the fault breaks CoW and the write lands in the private page. Keep pmem flushes on the read-only check. arch_wb_cache_pmem() never modifies memory, and the FLUSH access bits do not make the umem writable, so classifying flushes as writes would make every flush against a flush-only MR fail. Fixes: 0b261d7c1cd3 ("RDMA/rxe: Break endless pagefault loop for RO pages") Signed-off-by: Weiming Shi <bestswngs@gmail.com> Link: https://patch.msgid.link/20260726111533.1037819-1-bestswngs@gmail.com Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Tested-by: Hongqiang Luo <wanbafv@gmail.com> Tested-by: Xinyu Ma <mmmxny@gmail.com> Tested-by: Zhanbo Ye <cainyzb@gmail.com> Reported-by: Weiming Shi <bestswngs@gmail.com> Reported-by: Shaomin Chen <eeesssooo020@gmail.com> Reported-by: Rui Ding <threonine42@gmail.com> Reported-by: Miao Zhao <muel@nova.gal> Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysdm-integrity: fix infinite loop on discard with large tag sizeBen Cressey
When integrity_metadata handles a discard, it fills a buffer with DISCARD_FILLER and writes it over the tags, max_blocks blocks at a time. If the kmalloc fails, the buffer is the on-stack array checksums_onstack and max_size is set to HASH_MAX_DIGESTSIZE. So if the tag size is larger than HASH_MAX_DIGESTSIZE, max_blocks is zero, bi_size is never decremented and the loop never terminates. Fix this by using sizeof(checksums_onstack) as max_size. The array has MAX_TAG_SIZE bytes since commit b93b6643e9b5 ("dm integrity: fix a crash with unusually large tag size"), so max_blocks is at least 1. Fixes: 84597a44a9d8 ("dm integrity: add optional discard support") Cc: stable@vger.kernel.org Reviewed-by: Jose Fernandez (Anthropic) <jose.fernandez@linux.dev> Signed-off-by: Ben Cressey <ben@cressey.dev> Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
8 daysdm-integrity: fix buffer overflow with keyed discardBen Cressey
Since commit 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker"), integrity_metadata computes a checksum for every discarded block into the "checksums" buffer. integrity_sector_checksum always writes the whole digest. So if the tag size is smaller than the digest size, the checksum of the last block that fits into the buffer is written past the end of it. For example, with hmac(sha256) and tag size 16, a 4MiB discard writes 16 bytes past the kmalloc'ed page. Fix this by subtracting extra_space from the buffer size when computing max_blocks, like we do for writes. Fixes: 68c5c42567bc ("dm-integrity: replace forgeable discard filler with a keyed sector marker") Reviewed-by: Jose Fernandez (Anthropic) <jose.fernandez@linux.dev> Signed-off-by: Ben Cressey <ben@cressey.dev> Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
8 daysdm-integrity: require stable writes for internal hash modesChen Cheng
dm-integrity direct, bitmap and inline internal-hash modes compute integrity tags from the pages carried by the write bio. The lower data write also uses those pages, so the tag and the data write depend on the same memory contents staying unchanged while writeback is in flight. Without stable writes, a buffered writer can modify a writeback folio after dm-integrity has submitted the data bio and before the lower device has consumed the data. After a crash, this can leave data from the later contents with a tag calculated from the earlier contents, causing permanent checksum failures on read. Set BLK_FEAT_STABLE_WRITES for internal-hash D, B and I modes so filesystems wait for writeback folios to become stable before modifying them again. Journal mode is left unchanged because it copies data into the journal before computing and persisting the tag. Tested using dm-delay over a virtio-blk test disk, dm-integrity internal_hash:crc32c and no-journal ext4. The D and B reproducers both failed with checksum errors before this change and completed with READ_RC=0 and zero mismatches after it. Fixes: 7eada909bfd7 ("dm: add integrity target") Cc: stable@vger.kernel.org Reported-by: Sun Yangkai <sunyangkai@fygo.io> Link: https://github.com/chencheng-fnnas/reproducer/blob/main/dm-integrity-writeback-race.py Signed-off-by: Chen Cheng <chencheng@fnnas.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
8 daysdm cache: fix issue with background work lockingBenjamin Marzinski
dm cache used a rw_semaphore for background_work_lock. Write locks on rw_semaphores have strict owner semantics, but there was no guarantee that the process that locked background_work_lock was the same process that unlocked it. This can be easily seen using a kernel compiled with CONFIG_DEBUG_RWSEMS. Given a dm cache device <cache>, run: 'dmsetup suspend <cache> && dmsetup resume <cache>'. This will trigger a kernel warning: DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)) triggered by cache_resume(). To fix this, switch from a rw_semaphore to a spinlock and a wait queue. dm cache already has a wait queue and associated counter, migration_wait and nr_allocated_migrations, that was getting woken up when background work was getting completed, but wasn't actually used by anything. This is replaced by the background_work queue and counter. Fixes: b29d4986d0da ("dm cache: significant rework to leverage dm-bio-prison-v2") Cc: stable@vger.kernel.org Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com> Reviewed-by: Matthew Sakai <msakai@redhat.com> Reviewed-by: Ming-Hung Tsai <mtsai@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
8 daysdm-crypt: fix a tiny race condition in crypt_dec_pendingBen Cressey
crypt_dec_pending reads io->error before calling atomic_dec_and_test. Another context, for example crypt_endio called from an interrupt, may set io->error and drop its reference between the read and the decrement. crypt_dec_pending then drops the last reference and completes the bio with the stale status - so a read that failed and was never decrypted, or a write that failed, is reported as successful. The read was placed before the decrement by commit b35f8caa0890 ("dm crypt: wait for endio to complete before destruction"), because that commit freed dm_crypt_io before calling bio_endio. This is no longer the case, dm_crypt_io lives in the per-bio data now. Read io->error after atomic_dec_and_test instead. atomic_dec_and_test is fully ordered, so no additional barrier is needed. Fixes: b35f8caa0890 ("dm crypt: wait for endio to complete before destruction") Cc: stable@vger.kernel.org Reviewed-by: Jose Fernandez (Anthropic) <jose.fernandez@linux.dev> Signed-off-by: Ben Cressey <ben@cressey.dev> Assisted-by: Claude:unspecified Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
8 daysclk: fix self-consuming provider module pinningJerome Brunet
clk_hw_get_clk() lets a provider get a struct clk for one of its own struct clk_hw. When a struct clk is created, the module usage count of the provider is unconditionally increased. For a self-consuming provider, this means it pins itself and the module can never be unloaded. Increasing the module usage count should only be done when the consumer lives in a different module from the provider. Use THIS_MODULE to capture caller's module and increase the module usage count accordingly. It is OK for consumer-only APIs such as clk_get() or of_clk_get() to pass a NULL owner. As a result, any provider module will get pinned, same as before. Fixes: 30d6f8c15d2c ("clk: add api to get clk consumer from clk_hw") Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Brian Masney <bmasney@redhat.com>
8 daysclk: scpi: use PLATFORM_DEVID_NONE for scpi-cpufreqXixin Liu
Replace the magic -1 passed to platform_device_register_simple() with PLATFORM_DEVID_NONE. This is a readability cleanup only and does not change behavior. Signed-off-by: Xixin Liu <liuxixin@kylinos.cn> Link: https://patch.msgid.link/fb51cfbfbb41.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
8 daysclk: scpi: register scpi-cpufreq once and clear on failureXixin Liu
scpi_clocks_probe() walks clock children and, for each DVFS provider, calls platform_device_register_simple("scpi-cpufreq", -1, ...). Two related bugs: Since all DVFS providers register the fixed scpi-cpufreq device using PLATFORM_DEVID_NONE, a second registration fails with -EEXIST and overwrites the pointer to the successfully registered device. The first device can then no longer be unregistered. Register the virtual device only once. If registration fails, reset the pointer to NULL so a subsequent DVFS provider can retry and the global pointer only represents a successfully registered device. Fixes: 9490f01e2471 ("clk: scpi: add support for cpufreq virtual device") Fixes: 67bcc2c5f1da ("clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled") Signed-off-by: Xixin Liu <liuxixin@kylinos.cn> Link: https://patch.msgid.link/fd1b9199a9c3.v2.1785200642.git.liuxixin@kylinos.cn (sudeep.holla: reworded the commit message to improve readability) Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
8 daysclk: scpi: bound-check DVFS index in scpi_dvfs_recalc_rateXixin Liu
dvfs_get_idx() may return an out-of-range index if the SCP firmware is buggy or returns a stale value. Only negative indexes were rejected, so a large index walked past info->opps and could treat garbage as a clock rate (KASAN OOB / wrong frequency to consumers). The missing upper bound dates back to the original SCPI clock driver. Treat indexes >= opp count as invalid and return 0, same as idx < 0. Fixes: cd52c2a4b5c4 ("clk: add support for clocks provided by SCP(System Control Processor)") Signed-off-by: Xixin Liu <liuxixin@kylinos.cn> Link: https://patch.msgid.link/04f9ab766e07.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
8 daysfirmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPSXixin Liu
scpi_dvfs_get_info() already rejected a zero opp_count, but still trusted any larger value from the SCP firmware. The shared-memory reply only holds MAX_DVFS_OPPS entries in buf.opps[]; a bigger count over-reads that array and then sizes the allocated OPP table incorrectly (garbage OPPs / OOB). The missing upper bound dates back to the original SCPI DVFS support. Reject zero and out-of-range counts in one check and return -EINVAL. Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") Signed-off-by: Xixin Liu <liuxixin@kylinos.cn> Link: https://patch.msgid.link/022802f0b38f.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
8 daysfirmware: arm_scpi: fix device_node leak in scpi_dev_domain_idXixin Liu
of_parse_phandle_with_args() takes a reference on clkspec.np that must be released with of_node_put(). scpi_dev_domain_id() returned clkspec.args[0] without dropping that reference, so every domain lookup leaked a device node. Paths such as scpi_dvfs_info() / cpufreq init call this per CPU, so the leak accumulates over time. Save the domain id, of_node_put(clkspec.np), then return the saved value. Signed-off-by: Xixin Liu <liuxixin@kylinos.cn> Link: https://patch.msgid.link/84fdd490495b.v2.1785200642.git.liuxixin@kylinos.cn Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
8 dayss390/zcrypt: Fix uninitialized padding in CRT key structureHarald Freudenberger
The zcrypt_type6_crt_key() function leaves padding bytes uninitialized between key components and the modulus in the CCA CRT key token. These padding bytes are sent to the crypto card, potentially leaking kernel memory contents. The initial memset() only zeros fixed structure fields, not the flexible array member key_parts[] where the padding resides. While key components are properly copied from userspace, the calculated pad_len bytes between them remain uninitialized. Fix by explicitly zeroing the padding bytes after copying the CRT key components. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reviewed-by: Finn Callies <fcallies@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
8 daysRDMA/mana_ib: Remove redundant NULL check before netdev_put()Sang-Heon Jeon
netdev_put() does nothing if dev is NULL, so the check before the call is redundant. So remove it. No functional change. This is the result of running the Coccinelle script from scripts/coccinelle/free/ifnulldev_put.cocci after commit f83b8a58695c ("coccinelle: ifnulldev_put: update outdated helper names"). Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Link: https://patch.msgid.link/20260831052108.903019-1-ekffu200098@gmail.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysnet: bonding: annotate lockless writes with WRITE_ONCE()Eric Dumazet
Several fields in bonding are read locklessly using READ_ONCE() (or ACCESS_ONCE() previously) but have corresponding writes that do not use WRITE_ONCE(). Add WRITE_ONCE() annotations to: - bond->send_peer_notif decrements in bond_peer_notify_may_events() and reset in bond_close(). - bond->slave_cnt increments and decrements in bond_enslave() and __bond_release_one(). - bond->recv_probe updates in bond_open(), bond_option_arp_interval_set() and rlb_initialize(). - slaves->count decrement in bond_skip_slave(). Fixes: 4d97480b1806 ("bonding: use local function pointer of bond->recv_probe in bond_handle_frame") Fixes: 9a72c2da690d ("bonding: fix div by zero while enslaving and transmitting") Fixes: ee6377147409 ("bonding: Simplify the xmit function for modes that use xmit_hash") Fixes: 429208aab9db ("net: bonding: add the READ_ONCE/WRITE_ONCE for outside lock accessing") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Jay Vosburgh <jv@jvosburgh.net> Reviewed-by: Xuanqiang Luo<luoxuanqiang@kylinos.cn> Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn> Link: https://patch.msgid.link/20260831081027.3209554-1-edumazet@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
8 daysRDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB accessGang Yan
mr_check_range() validates that [iova, iova+length) falls within the registered MR range using wraparound-prone arithmetic: if (iova < mr->ibmr.iova || iova + length > mr->ibmr.iova + mr->ibmr.length) A remote peer can craft an RDMA-Write/Read RETH so that iova + length wraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the check. rxe_mr_iova_to_index() then computes a huge index (int idx, only guarded by WARN_ON) and rxe_mr_copy_xarray() dereferences mr->page_info[huge], causing an out-of-bounds read/write and a kernel oops that is triggerable by an unauthenticated remote peer. Rewrite the check in overflow-safe form; the first two clauses guarantee that the subsequent subtractions do not underflow: if (iova < mr->ibmr.iova || length > mr->ibmr.length || iova - mr->ibmr.iova > mr->ibmr.length - length) With the fix, mr_check_range() returns -EINVAL for the crafted iova and the responder reports REMOTE_ACCESS_ERROR instead of triggering the OOB. Fixes: 8700e3e7c485 ("Soft RoCE driver") Signed-off-by: Gang Yan <yangang@kylinos.cn> Link: https://patch.msgid.link/20260814093740.292954-1-gang.yan@linux.dev Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Reviewed-by: Shukai Ni <shukai.ni@kuleuven.be> Tested-by: Shukai Ni <shukai.ni@kuleuven.be> Signed-off-by: Leon Romanovsky <leon@kernel.org>
8 daysstaging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie()Muhammad Bilal
rtw_restruct_wmm_ie() scans in_ie for a WMM IE with: while (i < in_len) { ... if (i + 5 < in_len && in_ie[i] == 0xDD && ...) { ... break; } i += (in_ie[i + 1] + 2); /* to the next IE element */ } When the "i + 5 < in_len" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of in_ie), execution falls through to "i += (in_ie[i + 1] + 2)", which reads in_ie[i + 1]. If i == in_len - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data. Commit a75281626fc8f ("staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie") added the "i + 5 < in_len" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path. Add an explicit bounds check before advancing to the next IE. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal <meatuni001@gmail.com> Link: https://patch.msgid.link/20260728125456.32359-4-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: rtl8723bs: fix OOB read in rtw_action_frame_parse()Muhammad Bilal
rtw_action_frame_parse() takes a frame_len parameter but never actually checks it before indexing into the frame body: const u8 *frame_body = frame + sizeof(struct ieee80211_hdr_3addr); ... c = frame_body[0]; ... a = frame_body[1]; frame_body already points 24 bytes (sizeof(struct ieee80211_hdr_3addr)) into frame, so reading frame_body[0] and frame_body[1] requires frame_len >= 26. A management action frame shorter than that (e.g. exactly 24 bytes, the minimum a malicious peer can send) causes a 1-2 byte out-of-bounds read. This is reachable from rtw_cfg80211_monitor_if_xmit_entry() and cfg80211_rtw_mgmt_tx() in ioctl_cfg80211.c, both of which pass attacker/user-influenced frame buffers and lengths straight through. Add the missing length check before frame_body is dereferenced. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal <meatuni001@gmail.com> Link: https://patch.msgid.link/20260728125456.32359-3-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr()Muhammad Bilal
rtw_get_wps_attr() walks WPS attributes inside a WPS IE taken from a wireless management frame. For each candidate attribute it only checks that the fixed 4-byte attribute header (2-byte ID + 2-byte length) fits inside the IE: if (attr_ptr + 4 > wps_ie + wps_ielen) break; u16 attr_id = get_unaligned_be16(attr_ptr); u16 attr_data_len = get_unaligned_be16(attr_ptr + 2); u16 attr_len = attr_data_len + 4; attr_data_len (and therefore attr_len) is read directly from the wire and is never checked against the remaining bytes in the IE before being used as the size of: memcpy(buf_attr, attr_ptr, attr_len); Since attr_len is fully attacker controlled (0 to 65535+4), this is both a heap OOB read of wps_ie, and, more seriously, a stack buffer overflow at several call sites where buf_attr is a single-byte stack variable, e.g. rtw_get_wps_attr_content()'s callers passing WPS_ATTR_SELECTED_REGISTRAR into a stack "u8 sr"/"u8 selected_registrar" (drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c, drivers/staging/rtl8723bs/core/rtw_mlme_ext.c). A crafted WPS IE in a beacon or probe response processed during scanning can therefore smash the stack of the parsing thread. rtw_get_wps_attr_content() itself has no independent length check and simply trusts the attr_len it gets back from rtw_get_wps_attr(), so fixing the bound here also fixes that caller. The "attr_ptr + 4 > wps_ie + wps_ielen" header check above was added by commit 1463ca3ec6601 ("staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(), rtw_get_wapi_ie(), and rtw_get_wps_attr()"), which bounded the fixed header but never extended the check to cover the variable-length attribute data that follows it. Add that missing check before attr_len is used as a memcpy() length or accepted as a match. Fixes: 554c0a3abf216 ("staging: Add rtl8723bs sdio wifi driver") Cc: stable@vger.kernel.org Signed-off-by: Muhammad Bilal <meatuni001@gmail.com> Link: https://patch.msgid.link/20260728125456.32359-2-meatuni001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: fbtft: make dirty_lock IRQ-safeHui Su
fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled. Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again. The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled: WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2} CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); <Interrupt> lock(console_owner); *** DEADLOCK *** Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Hui Su <sh_def@163.com> Link: https://lore.kernel.org/lkml/20260804173712.176017-1-sh_def@163.com/ Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260807150953.2811933-3-sh_def@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: rtl8723bs: remove unused chip-type enums and definesAdriano Cordova
Remove enums and defines left over from other Realtek chips: - the RF_8225, RF_8256, RF_8258, RF_6052 and RF_PSEUDO_11N RF-type enum - TX_2S, TX_3S and TX_4S - RF_PATH_MAX_92C_88E and RF_PATH_MAX_90_8812 - TX_POWER_NEAR_FIELD_THRESH_8812 - ODM_ITRF_ALL None of them is referenced anywhere in the driver. Signed-off-by: Adriano Cordova <adrianox@gmail.com> Link: https://patch.msgid.link/20260831020557.1235504-3-adrianox@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: rtl8723bs: remove dead beamforming codeAdriano Cordova
The beamforming declarations are guarded by #if (BEAMFORMING_SUPPORT == 1) but BEAMFORMING_SUPPORT is defined to 0, so they are never compiled. The types they use (RT_BEAMFORMING_INFO, BEAMFORMING_CAP, PMGNT_INFO) are not defined anywhere either. Remove the dead declarations and the now unused macro. Signed-off-by: Adriano Cordova <adrianox@gmail.com> Link: https://patch.msgid.link/20260831020557.1235504-2-adrianox@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: rtl8723bs: refactor traffic_stat access in collect_traffic_statisticsMirza Ishan Beg
Replace repetitive `pdvobjpriv->traffic_stat.` dereferencing with a local pointer `ts` to improve readability and reduce line length. This resolves multiple checkpatch line-length warnings without manual wrapping. Suggested-by: Nikolay Kulikov <nikolayof23@gmail.com> Signed-off-by: Mirza Ishan Beg <seedandsyntax@gmail.com> Link: https://lore.kernel.org/linux-staging/agDaGJ5UKndFUNPY@archlinux/ Link: https://patch.msgid.link/20260829154838.4533-1-seedandsyntax@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: rtl8723bs: remove unnecessary parentheses in ioctl_cfg80211.cRomeu Gomes
Remove unnecessary parentheses around the right-hand side of assignments and around function arguments. This clears up all "Unnecessary parentheses" warnings reported by checkpatch.pl. Signed-off-by: Romeu Gomes <asm.artisan256@gmail.com> Link: https://patch.msgid.link/20260828101701.18750-1-asm.artisan256@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: rtl8723bs: make rtw_free_xmitbuf() return voidHungyu Lin
The return value of rtw_free_xmitbuf() is never checked. Change its return type to void and remove the redundant _SUCCESS and _FAIL return values. Also remove the unnecessary extern keyword from its declaration. Signed-off-by: Hungyu Lin <dennylin0707@gmail.com> Link: https://patch.msgid.link/20260825125406.1710-3-dennylin0707@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: rtl8723bs: make rtw_free_xmitbuf_ext() return voidHungyu Lin
The return value of rtw_free_xmitbuf_ext() is never checked. Change its return type to void and remove the redundant _SUCCESS and _FAIL return values. Also remove the unnecessary extern keyword from its declaration. Signed-off-by: Hungyu Lin <dennylin0707@gmail.com> Link: https://patch.msgid.link/20260825125406.1710-2-dennylin0707@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
8 daysstaging: rtl8723bs: use bool for PMKSA flagsTiago Panizio Gottardo
The inserted and matched variables only track boolean state in the PMKSA helpers. Use bool instead of u8 and give the variables clearer names. No functional changes intended. Signed-off-by: Tiago Panizio Gottardo <tiago.panizio@hotmail.com> Link: https://patch.msgid.link/CPYP284MB0854D9AB7B360D108DFC7116FFA32@CPYP284MB0854.BRAP284.PROD.OUTLOOK.COM Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-09 21:11:59 +0000