commit 5a08b69dd2fd2dbcabfae0b92baf0bc660b9a51d
Author: Alexandre Frade <kernel@xanmod.org>
Date:   Thu Feb 19 22:42:40 2026 +0000

    Linux 6.18.13-rt-xanmod1
    
    Signed-off-by: Alexandre Frade <kernel@xanmod.org>

commit 134bda61771efbd22942778bf8ea45e99a1c4f02
Merge: f3d23a5c6fec 1c34c76dcee6
Author: Alexandre Frade <kernel@xanmod.org>
Date:   Thu Feb 19 22:41:51 2026 +0000

    Merge branch '6.18' into 6.18-rt

commit 1c34c76dcee6549c44c5724cb2afb51c9a0c7425
Author: Alexandre Frade <kernel@xanmod.org>
Date:   Thu Feb 19 22:39:38 2026 +0000

    Linux 6.18.13-xanmod1
    
    Signed-off-by: Alexandre Frade <kernel@xanmod.org>

commit 54498a9f81ede21d798a4ab336f7653516b358e7
Merge: 04b5bae7c5a2 25e0b1c206e3
Author: Alexandre Frade <kernel@xanmod.org>
Date:   Thu Feb 19 22:37:08 2026 +0000

    Merge tag 'v6.18.13' into 6.18
    
    This is the 6.18.13 stable release

commit 25e0b1c206e3def1bd3bf9dcba980c5138c637a9
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Feb 19 16:31:37 2026 +0100

    Linux 6.18.13
    
    Link: https://lore.kernel.org/r/20260217200006.470920131@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Brett A C Sheffield <bacs@librecast.net>
    Tested-by: Luna Jernberg <droidbittin@gmail.com>
    Tested-by: Jeffrin Jose T <jeffrin@rajagiritech.edu.in>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Miguel Ojeda <ojeda@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df337ba02ca53ca9cfcefc1ed7ca38424daa52a0
Author: Daeho Jeong <daehojeong@google.com>
Date:   Mon Jan 26 14:28:01 2026 -0800

    f2fs: fix incomplete block usage in compact SSA summaries
    
    commit 91b76f1059b60f453b51877f29f0e35693737383 upstream.
    
    In a previous commit, a bug was introduced where compact SSA summaries
    failed to utilize the entire block space in non-4KB block size
    configurations, leading to inefficient space management.
    
    This patch fixes the calculation logic to ensure that compact SSA
    summaries can fully occupy the block regardless of the block size.
    
    Reported-by: Chris Mason <clm@meta.com>
    Fixes: e48e16f3e37f ("f2fs: support non-4KB block size without packed_ssa feature")
    Signed-off-by: Daeho Jeong <daehojeong@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 855c54f1803e3ebc613677b4f389c7f92656a1fc
Author: Chao Yu <chao@kernel.org>
Date:   Tue Feb 17 12:42:38 2026 -0500

    f2fs: fix to do sanity check on node footer in {read,write}_end_io
    
    [ Upstream commit 50ac3ecd8e05b6bcc350c71a4307d40c030ec7e4 ]
    
    -----------[ cut here ]------------
    kernel BUG at fs/f2fs/data.c:358!
    Call Trace:
     <IRQ>
     blk_update_request+0x5eb/0xe70 block/blk-mq.c:987
     blk_mq_end_request+0x3e/0x70 block/blk-mq.c:1149
     blk_complete_reqs block/blk-mq.c:1224 [inline]
     blk_done_softirq+0x107/0x160 block/blk-mq.c:1229
     handle_softirqs+0x283/0x870 kernel/softirq.c:579
     __do_softirq kernel/softirq.c:613 [inline]
     invoke_softirq kernel/softirq.c:453 [inline]
     __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680
     irq_exit_rcu+0x9/0x30 kernel/softirq.c:696
     instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1050 [inline]
     sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1050
     </IRQ>
    
    In f2fs_write_end_io(), it detects there is inconsistency in between
    node page index (nid) and footer.nid of node page.
    
    If footer of node page is corrupted in fuzzed image, then we load corrupted
    node page w/ async method, e.g. f2fs_ra_node_pages() or f2fs_ra_node_page(),
    in where we won't do sanity check on node footer, once node page becomes
    dirty, we will encounter this bug after node page writeback.
    
    Cc: stable@kernel.org
    Reported-by: syzbot+803dd716c4310d16ff3a@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=803dd716c4310d16ff3a
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    [ Context ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd2fec912a0f04390d446ed692f73f2da842855f
Author: Chao Yu <chao@kernel.org>
Date:   Tue Feb 17 12:42:37 2026 -0500

    f2fs: fix to do sanity check on node footer in __write_node_folio()
    
    [ Upstream commit 0a736109c9d29de0c26567e42cb99b27861aa8ba ]
    
    Add node footer sanity check during node folio's writeback, if sanity
    check fails, let's shutdown filesystem to avoid looping to redirty
    and writeback in .writepages.
    
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 715a7a72e47361548a377996effb8f4ed869e84e
Author: Fabio Porcedda <fabio.porcedda@gmail.com>
Date:   Fri Jan 23 16:19:16 2026 +0100

    USB: serial: option: add Telit FN920C04 RNDIS compositions
    
    commit 509f403f3ccec14188036212118651bf23599396 upstream.
    
    Add the following compositions:
    
    0x10a1: RNDIS + tty (AT/NMEA) + tty (AT) + tty (diag)
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  9 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a1 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=d128dba9
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x10a6: RNDIS + tty (AT/NMEA) + tty (AT) + tty (diag)
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a6 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=d128dba9
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x10ab: RNDIS + tty (AT) + tty (diag) + DPL (Data Packet Logging) + adb
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 11 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10ab Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=d128dba9
    C:  #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f611dafe0ffd33bc3fe522506af38903f34ffcc1
Author: Danilo Krummrich <dakr@kernel.org>
Date:   Wed Jan 21 15:12:01 2026 +0100

    iommu/arm-smmu-qcom: do not register driver in probe()
    
    commit ed1ac3c977dd6b119405fa36dd41f7151bd5b4de upstream.
    
    Commit 0b4eeee2876f ("iommu/arm-smmu-qcom: Register the TBU driver in
    qcom_smmu_impl_init") intended to also probe the TBU driver when
    CONFIG_ARM_SMMU_QCOM_DEBUG is disabled, but also moved the corresponding
    platform_driver_register() call into qcom_smmu_impl_init() which is
    called from arm_smmu_device_probe().
    
    However, it neither makes sense to register drivers from probe()
    callbacks of other drivers, nor does the driver core allow registering
    drivers with a device lock already being held.
    
    The latter was revealed by commit dc23806a7c47 ("driver core: enforce
    device_lock for driver_match_device()") leading to a deadlock condition
    described in [1].
    
    Additionally, it was noted by Robin that the current approach is
    potentially racy with async probe [2].
    
    Hence, fix this by registering the qcom_smmu_tbu_driver from
    module_init(). Unfortunately, due to the vendoring of the driver, this
    requires an indirection through arm-smmu-impl.c.
    
    Reported-by: Mark Brown <broonie@kernel.org>
    Closes: https://lore.kernel.org/lkml/7ae38e31-ef31-43ad-9106-7c76ea0e8596@sirena.org.uk/
    Link: https://lore.kernel.org/lkml/DFU7CEPUSG9A.1KKGVW4HIPMSH@kernel.org/ [1]
    Link: https://lore.kernel.org/lkml/0c0d3707-9ea5-44f9-88a1-a65c62e3df8d@arm.com/ [2]
    Fixes: dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()")
    Fixes: 0b4eeee2876f ("iommu/arm-smmu-qcom: Register the TBU driver in qcom_smmu_impl_init")
    Acked-by: Robin Murphy <robin.murphy@arm.com>
    Tested-by: Bjorn Andersson <andersson@kernel.org>
    Reviewed-by: Bjorn Andersson <andersson@kernel.org>
    Acked-by: Konrad Dybcio <konradybcio@kernel.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com> #LX2160ARDB
    Tested-by: Wang Jiayue <akaieurus@gmail.com>
    Reviewed-by: Wang Jiayue <akaieurus@gmail.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Acked-by: Joerg Roedel <joerg.roedel@amd.com>
    Link: https://patch.msgid.link/20260121141215.29658-1-dakr@kernel.org
    Signed-off-by: Danilo Krummrich <dakr@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0415ae51a40e346ca233dcc1b4b7c486d70e69d2
Author: Yeongjin Gil <youngjin.gil@samsung.com>
Date:   Thu Jan 22 19:45:27 2026 +0900

    f2fs: optimize f2fs_overwrite_io() for f2fs_iomap_begin
    
    commit d860974a7e38d35e9e2c4dc8a9f4223b38b6ad99 upstream.
    
    When overwriting already allocated blocks, f2fs_iomap_begin() calls
    f2fs_overwrite_io() to check block mappings. However,
    f2fs_overwrite_io() iterates through all mapped blocks in the range,
    which can be inefficient for fragmented files with large I/O requests.
    
    This patch optimizes f2fs_overwrite_io() by adding a 'check_first'
    parameter and introducing __f2fs_overwrite_io() helper. When called from
    f2fs_iomap_begin(), we only check the first mapping to determine if the
    range is already allocated, which is sufficient for setting
    map.m_may_create.
    
    This optimization significantly reduces the number of f2fs_map_blocks()
    calls in f2fs_overwrite_io() when called from f2fs_iomap_begin(),
    especially for fragmented files with large I/O requests.
    
    Cc: stable@kernel.org
    Fixes: 351bc761338d ("f2fs: optimize f2fs DIO overwrites")
    Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
    Reviewed-by: Sunmin Jeong <s_min.jeong@samsung.com>
    Signed-off-by: Yeongjin Gil <youngjin.gil@samsung.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fee27b69dde1a05908b350eea42937af2387c4fe
Author: Chao Yu <chao@kernel.org>
Date:   Tue Jan 13 14:22:29 2026 +0800

    f2fs: fix to avoid mapping wrong physical block for swapfile
    
    commit 5c145c03188bc9ba1c29e0bc4d527a5978fc47f9 upstream.
    
    Xiaolong Guo reported a f2fs bug in bugzilla [1]
    
    [1] https://bugzilla.kernel.org/show_bug.cgi?id=220951
    
    Quoted:
    
    "When using stress-ng's swap stress test on F2FS filesystem with kernel 6.6+,
    the system experiences data corruption leading to either:
    1 dm-verity corruption errors and device reboot
    2 F2FS node corruption errors and boot hangs
    
    The issue occurs specifically when:
    1 Using F2FS filesystem (ext4 is unaffected)
    2 Swapfile size is less than F2FS section size (2MB)
    3 Swapfile has fragmented physical layout (multiple non-contiguous extents)
    4 Kernel version is 6.6+ (6.1 is unaffected)
    
    The root cause is in check_swap_activate() function in fs/f2fs/data.c. When the
    first extent of a small swapfile (< 2MB) is not aligned to section boundaries,
    the function incorrectly treats it as the last extent, failing to map
    subsequent extents. This results in incorrect swap_extent creation where only
    the first extent is mapped, causing subsequent swap writes to overwrite wrong
    physical locations (other files' data).
    
    Steps to Reproduce
    1 Setup a device with F2FS-formatted userdata partition
    2 Compile stress-ng from https://github.com/ColinIanKing/stress-ng
    3 Run swap stress test: (Android devices)
    adb shell "cd /data/stressng; ./stress-ng-64 --metrics-brief --timeout 60
    --swap 0"
    
    Log:
    1 Ftrace shows in kernel 6.6, only first extent is mapped during second
    f2fs_map_blocks call in check_swap_activate():
    stress-ng-swap-8990: f2fs_map_blocks: ino=11002, file offset=0, start
    blkaddr=0x43143, len=0x1
    (Only 4KB mapped, not the full swapfile)
    2 in kernel 6.1, both extents are correctly mapped:
    stress-ng-swap-5966: f2fs_map_blocks: ino=28011, file offset=0, start
    blkaddr=0x13cd4, len=0x1
    stress-ng-swap-5966: f2fs_map_blocks: ino=28011, file offset=1, start
    blkaddr=0x60c84b, len=0xff
    
    The problematic code is in check_swap_activate():
    if ((pblock - SM_I(sbi)->main_blkaddr) % blks_per_sec ||
        nr_pblocks % blks_per_sec ||
        !f2fs_valid_pinned_area(sbi, pblock)) {
        bool last_extent = false;
    
        not_aligned++;
    
        nr_pblocks = roundup(nr_pblocks, blks_per_sec);
        if (cur_lblock + nr_pblocks > sis->max)
            nr_pblocks -= blks_per_sec;
    
        /* this extent is last one */
        if (!nr_pblocks) {
            nr_pblocks = last_lblock - cur_lblock;
            last_extent = true;
        }
    
        ret = f2fs_migrate_blocks(inode, cur_lblock, nr_pblocks);
        if (ret) {
            if (ret == -ENOENT)
                ret = -EINVAL;
            goto out;
        }
    
        if (!last_extent)
            goto retry;
    }
    
    When the first extent is unaligned and roundup(nr_pblocks, blks_per_sec)
    exceeds sis->max, we subtract blks_per_sec resulting in nr_pblocks = 0. The
    code then incorrectly assumes this is the last extent, sets nr_pblocks =
    last_lblock - cur_lblock (entire swapfile), and performs migration. After
    migration, it doesn't retry mapping, so subsequent extents are never processed.
    "
    
    In order to fix this issue, we need to lookup block mapping info after
    we migrate all blocks in the tail of swapfile.
    
    Cc: stable@kernel.org
    Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices")
    Cc: Daeho Jeong <daehojeong@google.com>
    Reported-and-tested-by: Xiaolong Guo <guoxiaolong2008@gmail.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220951
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 97e4f479939e5ac6272e2e2473297942c6549ed3
Author: Daeho Jeong <daehojeong@google.com>
Date:   Sat Jan 10 15:54:05 2026 -0800

    f2fs: support non-4KB block size without packed_ssa feature
    
    commit e48e16f3e37fac76e2f0c14c58df2b0398a323b0 upstream.
    
    Currently, F2FS requires the packed_ssa feature to be enabled when
    utilizing non-4KB block sizes (e.g., 16KB). This restriction limits
    the flexibility of filesystem formatting options.
    
    This patch allows F2FS to support non-4KB block sizes even when the
    packed_ssa feature is disabled. It adjusts the SSA calculation logic to
    correctly handle summary entries in larger blocks without the packed
    layout.
    
    Cc: stable@kernel.org
    Fixes: 7ee8bc3942f2 ("f2fs: revert summary entry count from 2048 to 512 in 16kb block support")
    Signed-off-by: Daeho Jeong <daehojeong@google.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 995030be4ce6338c6ff814583c14166446a64008
Author: Chao Yu <chao@kernel.org>
Date:   Wed Jan 7 19:22:18 2026 +0800

    f2fs: fix to avoid UAF in f2fs_write_end_io()
    
    commit ce2739e482bce8d2c014d76c4531c877f382aa54 upstream.
    
    As syzbot reported an use-after-free issue in f2fs_write_end_io().
    
    It is caused by below race condition:
    
    loop device                             umount
    - worker_thread
     - loop_process_work
      - do_req_filebacked
       - lo_rw_aio
        - lo_rw_aio_complete
         - blk_mq_end_request
          - blk_update_request
           - f2fs_write_end_io
            - dec_page_count
            - folio_end_writeback
                                            - kill_f2fs_super
                                             - kill_block_super
                                              - f2fs_put_super
                                             : free(sbi)
           : get_pages(, F2FS_WB_CP_DATA)
             accessed sbi which is freed
    
    In kill_f2fs_super(), we will drop all page caches of f2fs inodes before
    call free(sbi), it guarantee that all folios should end its writeback, so
    it should be safe to access sbi before last folio_end_writeback().
    
    Let's relocate ckpt thread wakeup flow before folio_end_writeback() to
    resolve this issue.
    
    Cc: stable@kernel.org
    Fixes: e234088758fc ("f2fs: avoid wait if IO end up when do_checkpoint for better performance")
    Reported-by: syzbot+b4444e3c972a7a124187@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=b4444e3c972a7a124187
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d4a594dd952df123cbdcdee9b9640d9d55e4a954
Author: Yongpeng Yang <yangyongpeng@xiaomi.com>
Date:   Wed Jan 7 10:33:46 2026 +0800

    f2fs: fix out-of-bounds access in sysfs attribute read/write
    
    commit 98ea0039dbfdd00e5cc1b9a8afa40434476c0955 upstream.
    
    Some f2fs sysfs attributes suffer from out-of-bounds memory access and
    incorrect handling of integer values whose size is not 4 bytes.
    
    For example:
    vm:~# echo 65537 > /sys/fs/f2fs/vde/carve_out
    vm:~# cat /sys/fs/f2fs/vde/carve_out
    65537
    vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_threshold
    vm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold
    1
    
    carve_out maps to {struct f2fs_sb_info}->carve_out, which is a 8-bit
    integer. However, the sysfs interface allows setting it to a value
    larger than 255, resulting in an out-of-range update.
    
    atgc_age_threshold maps to {struct atgc_management}->age_threshold,
    which is a 64-bit integer, but its sysfs interface cannot correctly set
    values larger than UINT_MAX.
    
    The root causes are:
    1. __sbi_store() treats all default values as unsigned int, which
    prevents updating integers larger than 4 bytes and causes out-of-bounds
    writes for integers smaller than 4 bytes.
    
    2. f2fs_sbi_show() also assumes all default values are unsigned int,
    leading to out-of-bounds reads and incorrect access to integers larger
    than 4 bytes.
    
    This patch introduces {struct f2fs_attr}->size to record the actual size
    of the integer associated with each sysfs attribute. With this
    information, sysfs read and write operations can correctly access and
    update values according to their real data size, avoiding memory
    corruption and truncation.
    
    Fixes: b59d0bae6ca3 ("f2fs: add sysfs support for controlling the gc_thread")
    Cc: stable@kernel.org
    Signed-off-by: Jinbao Liu <liujinbao1@xiaomi.com>
    Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bd66b4c487d5091d2a65d6089e0de36f0c26a4c7
Author: Yongpeng Yang <yangyongpeng@xiaomi.com>
Date:   Tue Jan 6 20:12:11 2026 +0800

    f2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes
    
    commit 7633a7387eb4d0259d6bea945e1d3469cd135bbc upstream.
    
    During SPO tests, when mounting F2FS, an -EINVAL error was returned from
    f2fs_recover_inode_page. The issue occurred under the following scenario
    
    Thread A                                     Thread B
    f2fs_ioc_commit_atomic_write
     - f2fs_do_sync_file // atomic = true
      - f2fs_fsync_node_pages
        : last_folio = inode folio
        : schedule before folio_lock(last_folio) f2fs_write_checkpoint
                                                  - block_operations// writeback last_folio
                                                  - schedule before f2fs_flush_nat_entries
        : set_fsync_mark(last_folio, 1)
        : set_dentry_mark(last_folio, 1)
        : folio_mark_dirty(last_folio)
        - __write_node_folio(last_folio)
          : f2fs_down_read(&sbi->node_write)//block
                                                  - f2fs_flush_nat_entries
                                                    : {struct nat_entry}->flag |= BIT(IS_CHECKPOINTED)
                                                  - unblock_operations
                                                    : f2fs_up_write(&sbi->node_write)
                                                 f2fs_write_checkpoint//return
          : f2fs_do_write_node_page()
    f2fs_ioc_commit_atomic_write//return
                                                 SPO
    
    Thread A calls f2fs_need_dentry_mark(sbi, ino), and the last_folio has
    already been written once. However, the {struct nat_entry}->flag did not
    have the IS_CHECKPOINTED set, causing set_dentry_mark(last_folio, 1) and
    write last_folio again after Thread B finishes f2fs_write_checkpoint.
    
    After SPO and reboot, it was detected that {struct node_info}->blk_addr
    was not NULL_ADDR because Thread B successfully write the checkpoint.
    
    This issue only occurs in atomic write scenarios. For regular file
    fsync operations, the folio must be dirty. If
    block_operations->f2fs_sync_node_pages successfully submit the folio
    write, this path will not be executed. Otherwise, the
    f2fs_write_checkpoint will need to wait for the folio write submission
    to complete, as sbi->nr_pages[F2FS_DIRTY_NODES] > 0. Therefore, the
    situation where f2fs_need_dentry_mark checks that the {struct
    nat_entry}->flag /wo the IS_CHECKPOINTED flag, but the folio write has
    already been submitted, will not occur.
    
    Therefore, for atomic file fsync, sbi->node_write should be acquired
    through __write_node_folio to ensure that the IS_CHECKPOINTED flag
    correctly indicates that the checkpoint write has been completed.
    
    Fixes: 608514deba38 ("f2fs: set fsync mark only for the last dnode")
    Cc: stable@kernel.org
    Signed-off-by: Sheng Yong <shengyong1@xiaomi.com>
    Signed-off-by: Jinbao Liu <liujinbao1@xiaomi.com>
    Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70cf1e96bde07a1a75ce3a479132d06b4950c801
Author: Chao Yu <chao@kernel.org>
Date:   Tue Jan 6 14:31:17 2026 +0800

    f2fs: fix to check sysfs filename w/ gc_pin_file_thresh correctly
    
    commit 0eda086de85e140f53c6123a4c00662f4e614ee4 upstream.
    
    Sysfs entry name is gc_pin_file_thresh instead of gc_pin_file_threshold,
    fix it.
    
    Cc: stable@kernel.org
    Fixes: c521a6ab4ad7 ("f2fs: fix to limit gc_pin_file_threshold")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fb9f7e52273db15dd8c0e2fc107a986b87240bb4
Author: Zhiguo Niu <zhiguo.niu@unisoc.com>
Date:   Fri Dec 26 10:56:04 2025 +0800

    f2fs: fix to add gc count stat in f2fs_gc_range
    
    commit 761dac9073cd67d4705a94cd1af674945a117f4c upstream.
    
    It missed the stat count in f2fs_gc_range.
    
    Cc: stable@kernel.org
    Fixes: 9bf1dcbdfdc8 ("f2fs: fix to account gc stats correctly")
    Signed-off-by: Zhiguo Niu <zhiguo.niu@unisoc.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c008ad0f0d1c1523902b9cdb08e404129677bfc
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Dec 28 14:17:03 2025 +0100

    fbdev: smscufx: properly copy ioctl memory to kernelspace
    
    commit 120adae7b42faa641179270c067864544a50ab69 upstream.
    
    The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from
    userspace to kernelspace, and instead directly references the memory,
    which can cause problems if invalid data is passed from userspace.  Fix
    this all up by correctly copying the memory before accessing it within
    the kernel.
    
    Reported-by: Tianchu Chen <flynnnchen@tencent.com>
    Cc: stable <stable@kernel.org>
    Cc: Steve Glendinning <steve.glendinning@shawell.net>
    Cc: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3e4cbd1d46c246dfa684c8e9d8c20ae0b960c50a
Author: Guangshuo Li <lgs201920130244@gmail.com>
Date:   Sun Dec 7 15:25:32 2025 +0800

    fbdev: rivafb: fix divide error in nv3_arb()
    
    commit 0209e21e3c372fa2da04c39214bec0b64e4eb5f4 upstream.
    
    A userspace program can trigger the RIVA NV3 arbitration code by calling
    the FBIOPUT_VSCREENINFO ioctl on /dev/fb*. When doing so, the driver
    recomputes FIFO arbitration parameters in nv3_arb(), using state->mclk_khz
    (derived from the PRAMDAC MCLK PLL) as a divisor without validating it
    first.
    
    In a normal setup, state->mclk_khz is provided by the real hardware and is
    non-zero. However, an attacker can construct a malicious or misconfigured
    device (e.g. a crafted/emulated PCI device) that exposes a bogus PLL
    configuration, causing state->mclk_khz to become zero.  Once
    nv3_get_param() calls nv3_arb(), the division by state->mclk_khz in the gns
    calculation causes a divide error and crashes the kernel.
    
    Fix this by checking whether state->mclk_khz is zero and bailing out before
    doing the division.
    
    The following log reveals it:
    
    rivafb: setting virtual Y resolution to 2184
    divide error: 0000 [#1] PREEMPT SMP KASAN PTI
    CPU: 0 PID: 2187 Comm: syz-executor.0 Not tainted 5.18.0-rc1+ #1
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
    RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline]
    RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546
    Call Trace:
      nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603
      nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline]
      CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246
      riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779
      rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196
      fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033
      do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109
      fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188
      __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 98d91080517d4c642820b5d8219cb759ddaf79b7
Author: Chen Ridong <chenridong@huawei.com>
Date:   Wed Jan 14 01:51:29 2026 +0000

    cpuset: Fix missing adaptation for cpuset_is_populated
    
    Commit b1bcaed1e39a ("cpuset: Treat cpusets in attaching as populated")
    was backported to the long‑term support (LTS) branches. However, because
    commit d5cf4d34a333 ("cgroup/cpuset: Don't track # of local child
    partitions") was not backported, a corresponding adaptation to the
    backported code is still required.
    
    To ensure correct behavior, replace cgroup_is_populated with
    cpuset_is_populated in the partition_is_populated function.
    
    Cc: stable@vger.kernel.org      # 6.1+
    Fixes: b1bcaed1e39a ("cpuset: Treat cpusets in attaching as populated")
    Cc: Waiman Long <longman@redhat.com>
    Cc: Tejun Heo <tj@kernel.org>
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit eaa9fcf57934cda01e9f34b232ca78187b344ad1
Author: Tiezhu Yang <yangtiezhu@loongson.cn>
Date:   Tue Feb 10 19:31:17 2026 +0800

    LoongArch: Rework KASAN initialization for PTW-enabled systems
    
    commit 5ec5ac4ca27e4daa234540ac32f9fc5219377d53 upstream.
    
    kasan_init_generic() indicates that kasan is fully initialized, so it
    should be put at end of kasan_init().
    
    Otherwise bringing up the primary CPU failed when CONFIG_KASAN is set
    on PTW-enabled systems, here are the call chains:
    
        kernel_entry()
          start_kernel()
            setup_arch()
              kasan_init()
                kasan_init_generic()
    
    The reason is PTW-enabled systems have speculative accesses which means
    memory accesses to the shadow memory after kasan_init() may be executed
    by hardware before. However, accessing shadow memory is safe only after
    kasan fully initialized because kasan_init() uses a temporary PGD table
    until we have populated all levels of shadow page tables and writen the
    PGD register. Moving kasan_init_generic() later can defer the occasion
    of kasan_enabled(), so as to avoid speculative accesses on shadow pages.
    
    After moving kasan_init_generic() to the end, kasan_init() can no longer
    call kasan_mem_to_shadow() for shadow address conversion because it will
    always return kasan_early_shadow_page. On the other hand, we should keep
    the current logic of kasan_mem_to_shadow() for both the early and final
    stage because there may be instrumentation before kasan_init().
    
    To solve this, we factor out a new mem_to_shadow() function from current
    kasan_mem_to_shadow() for the shadow address conversion in kasan_init().
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
    Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b671f6f432be07c0ddd66e437d6d0e0db684f83
Author: David Hildenbrand (Red Hat) <david@kernel.org>
Date:   Tue Dec 23 22:40:37 2025 +0100

    mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using mmu_gather
    
    commit 8ce720d5bd91e9dc16db3604aa4b1bf76770a9a1 upstream.
    
    As reported, ever since commit 1013af4f585f ("mm/hugetlb: fix
    huge_pmd_unshare() vs GUP-fast race") we can end up in some situations
    where we perform so many IPI broadcasts when unsharing hugetlb PMD page
    tables that it severely regresses some workloads.
    
    In particular, when we fork()+exit(), or when we munmap() a large
    area backed by many shared PMD tables, we perform one IPI broadcast per
    unshared PMD table.
    
    There are two optimizations to be had:
    
    (1) When we process (unshare) multiple such PMD tables, such as during
        exit(), it is sufficient to send a single IPI broadcast (as long as
        we respect locking rules) instead of one per PMD table.
    
        Locking prevents that any of these PMD tables could get reused before
        we drop the lock.
    
    (2) When we are not the last sharer (> 2 users including us), there is
        no need to send the IPI broadcast. The shared PMD tables cannot
        become exclusive (fully unshared) before an IPI will be broadcasted
        by the last sharer.
    
        Concurrent GUP-fast could walk into a PMD table just before we
        unshared it. It could then succeed in grabbing a page from the
        shared page table even after munmap() etc succeeded (and supressed
        an IPI). But there is not difference compared to GUP-fast just
        sleeping for a while after grabbing the page and re-enabling IRQs.
    
        Most importantly, GUP-fast will never walk into page tables that are
        no-longer shared, because the last sharer will issue an IPI
        broadcast.
    
        (if ever required, checking whether the PUD changed in GUP-fast
         after grabbing the page like we do in the PTE case could handle
         this)
    
    So let's rework PMD sharing TLB flushing + IPI sync to use the mmu_gather
    infrastructure so we can implement these optimizations and demystify the
    code at least a bit. Extend the mmu_gather infrastructure to be able to
    deal with our special hugetlb PMD table sharing implementation.
    
    To make initialization of the mmu_gather easier when working on a single
    VMA (in particular, when dealing with hugetlb), provide
    tlb_gather_mmu_vma().
    
    We'll consolidate the handling for (full) unsharing of PMD tables in
    tlb_unshare_pmd_ptdesc() and tlb_flush_unshared_tables(), and track
    in "struct mmu_gather" whether we had (full) unsharing of PMD tables.
    
    Because locking is very special (concurrent unsharing+reuse must be
    prevented), we disallow deferring flushing to tlb_finish_mmu() and instead
    require an explicit earlier call to tlb_flush_unshared_tables().
    
    From hugetlb code, we call huge_pmd_unshare_flush() where we make sure
    that the expected lock protecting us from concurrent unsharing+reuse is
    still held.
    
    Check with a VM_WARN_ON_ONCE() in tlb_finish_mmu() that
    tlb_flush_unshared_tables() was properly called earlier.
    
    Document it all properly.
    
    Notes about tlb_remove_table_sync_one() interaction with unsharing:
    
    There are two fairly tricky things:
    
    (1) tlb_remove_table_sync_one() is a NOP on architectures without
        CONFIG_MMU_GATHER_RCU_TABLE_FREE.
    
        Here, the assumption is that the previous TLB flush would send an
        IPI to all relevant CPUs. Careful: some architectures like x86 only
        send IPIs to all relevant CPUs when tlb->freed_tables is set.
    
        The relevant architectures should be selecting
        MMU_GATHER_RCU_TABLE_FREE, but x86 might not do that in stable
        kernels and it might have been problematic before this patch.
    
        Also, the arch flushing behavior (independent of IPIs) is different
        when tlb->freed_tables is set. Do we have to enlighten them to also
        take care of tlb->unshared_tables? So far we didn't care, so
        hopefully we are fine. Of course, we could be setting
        tlb->freed_tables as well, but that might then unnecessarily flush
        too much, because the semantics of tlb->freed_tables are a bit
        fuzzy.
    
        This patch changes nothing in this regard.
    
    (2) tlb_remove_table_sync_one() is not a NOP on architectures with
        CONFIG_MMU_GATHER_RCU_TABLE_FREE that actually don't need a sync.
    
        Take x86 as an example: in the common case (!pv, !X86_FEATURE_INVLPGB)
        we still issue IPIs during TLB flushes and don't actually need the
        second tlb_remove_table_sync_one().
    
        This optimized can be implemented on top of this, by checking e.g., in
        tlb_remove_table_sync_one() whether we really need IPIs. But as
        described in (1), it really must honor tlb->freed_tables then to
        send IPIs to all relevant CPUs.
    
    Notes on TLB flushing changes:
    
    (1) Flushing for non-shared PMD tables
    
        We're converting from flush_hugetlb_tlb_range() to
        tlb_remove_huge_tlb_entry(). Given that we properly initialize the
        MMU gather in tlb_gather_mmu_vma() to be hugetlb aware, similar to
        __unmap_hugepage_range(), that should be fine.
    
    (2) Flushing for shared PMD tables
    
        We're converting from various things (flush_hugetlb_tlb_range(),
        tlb_flush_pmd_range(), flush_tlb_range()) to tlb_flush_pmd_range().
    
        tlb_flush_pmd_range() achieves the same that
        tlb_remove_huge_tlb_entry() would achieve in these scenarios.
        Note that tlb_remove_huge_tlb_entry() also calls
        __tlb_remove_tlb_entry(), however that is only implemented on
        powerpc, which does not support PMD table sharing.
    
        Similar to (1), tlb_gather_mmu_vma() should make sure that TLB
        flushing keeps on working as expected.
    
    Further, note that the ptdesc_pmd_pts_dec() in huge_pmd_share() is not a
    concern, as we are holding the i_mmap_lock the whole time, preventing
    concurrent unsharing. That ptdesc_pmd_pts_dec() usage will be removed
    separately as a cleanup later.
    
    There are plenty more cleanups to be had, but they have to wait until
    this is fixed.
    
    [david@kernel.org: fix kerneldoc]
      Link: https://lkml.kernel.org/r/f223dd74-331c-412d-93fc-69e360a5006c@kernel.org
    Link: https://lkml.kernel.org/r/20251223214037.580860-5-david@kernel.org
    Fixes: 1013af4f585f ("mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race")
    Signed-off-by: David Hildenbrand (Red Hat) <david@kernel.org>
    Reported-by: "Uschakow, Stanislav" <suschako@amazon.de>
    Closes: https://lore.kernel.org/all/4d3878531c76479d9f8ca9789dc6485d@amazon.de/
    Tested-by: Laurence Oberman <loberman@redhat.com>
    Acked-by: Harry Yoo <harry.yoo@oracle.com>
    Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Cc: Lance Yang <lance.yang@linux.dev>
    Cc: Liu Shixin <liushixin2@huawei.com>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Rik van Riel <riel@surriel.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c74d37343b93ac6503fceb762459d1fb9dea486
Author: Otto Pflüger <otto.pflueger@abscue.de>
Date:   Tue Jan 6 11:11:12 2026 +0100

    arm64: dts: mediatek: mt8183: Add missing endpoint IDs to display graph
    
    commit be0b304eeb8c5f77e4f98f64e58729d879195f2f upstream.
    
    The endpoint IDs in the display graph are expected to match the
    associated display path number, i.e. all endpoints connected to
    mmsys_ep_main must have reg = <0> and all endpoints connected to
    mmsys_ep_ext must have reg = <1>.
    
    Add the missing ID to all endpoints in the display graph, based on
    mt8365.dtsi as an existing example that does this correctly.
    
    Fixes: e72d63fa0563 ("arm64: dts: mediatek: mt8183: Migrate to display controller OF graph")
    Reported-by: Evans Jahja <evansjahja13@gmail.com>
    Closes: https://lore.kernel.org/linux-mediatek/CAAq5pW9o3itC0G16LnJO7KMAQ_XoqXUpB=cuJ_7e3-H11zKd5Q@mail.gmail.com/
    Tested-by: Chen-Yu Tsai <wenst@chromium.org>
    Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
    [Angelo: Fixed dtbs_check issues]
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Cc: Thorsten Leemhuis <regressions@leemhuis.info>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6d66464d1a059d92df8a5454d5bc9414f6ec0b03
Author: Alban Bedel <alban.bedel@lht.dlh.de>
Date:   Thu Jan 29 15:59:44 2026 +0100

    gpiolib: acpi: Fix gpio count with string references
    
    [ Upstream commit c62e0658d458d8f100445445c3ddb106f3824a45 ]
    
    Since commit 9880702d123f2 ("ACPI: property: Support using strings in
    reference properties") it is possible to use strings instead of local
    references. This work fine with single GPIO but not with arrays as
    acpi_gpio_package_count() didn't handle this case. Update it to handle
    strings like local references to cover this case as well.
    
    Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
    Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Link: https://patch.msgid.link/20260129145944.3372777-1-alban.bedel@lht.dlh.de
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fa4938e0d0d64a5623629470eefb5547495e7aa6
Author: Jens Axboe <axboe@kernel.dk>
Date:   Tue Feb 3 09:56:55 2026 -0700

    io_uring/fdinfo: be a bit nicer when looping a lot of SQEs/CQEs
    
    [ Upstream commit 38cfdd9dd279473a73814df9fd7e6e716951d361 ]
    
    Add cond_resched() in those dump loops, just in case a lot of entries
    are being dumped. And detect invalid CQ ring head/tail entries, to avoid
    iterating more than what is necessary. Generally not an issue, but can be
    if things like KASAN or other debugging metrics are enabled.
    
    Reported-by: 是参差 <shicenci@gmail.com>
    Link: https://lore.kernel.org/all/PS1PPF7E1D7501FE5631002D242DD89403FAB9BA@PS1PPF7E1D7501F.apcprd02.prod.outlook.com/
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cab928242853a832ffa7efda270ecfb9efeebb6e
Author: Ziyi Guo <n7l8m4@u.northwestern.edu>
Date:   Mon Feb 2 17:41:12 2026 +0000

    ASoC: fsl_xcvr: fix missing lock in fsl_xcvr_mode_put()
    
    [ Upstream commit f514248727606b9087bc38a284ff686e0093abf1 ]
    
    fsl_xcvr_activate_ctl() has
    lockdep_assert_held(&card->snd_card->controls_rwsem),
    but fsl_xcvr_mode_put() calls it without acquiring this lock.
    
    Other callers of fsl_xcvr_activate_ctl() in fsl_xcvr_startup() and
    fsl_xcvr_shutdown() properly acquire the lock with down_read()/up_read().
    
    Add the missing down_read()/up_read() calls around fsl_xcvr_activate_ctl()
    in fsl_xcvr_mode_put() to fix the lockdep assertion and prevent potential
    race conditions when multiple userspace threads access the control.
    
    Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu>
    Link: https://patch.msgid.link/20260202174112.2018402-1-n7l8m4@u.northwestern.edu
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 00c57e2369386e244de92db0d58548cea574fedd
Author: Melissa Wen <mwen@igalia.com>
Date:   Fri Jan 16 12:50:49 2026 -0300

    drm/amd/display: remove assert around dpp_base replacement
    
    [ Upstream commit 84962445cd8a83dc5bed4c8ad5bbb2c1cdb249a0 ]
    
    There is nothing wrong if in_shaper_func type is DISTRIBUTED POINTS.
    Remove the assert placed for a TODO to avoid misinterpretations.
    
    Signed-off-by: Melissa Wen <mwen@igalia.com>
    Reviewed-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 1714dcc4c2c53e41190896eba263ed6328bcf415)
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8e6f50396170939e4444ae18cd488f24b41bd5fd
Author: Melissa Wen <mwen@igalia.com>
Date:   Mon Dec 8 22:44:15 2025 -0100

    drm/amd/display: extend delta clamping logic to CM3 LUT helper
    
    [ Upstream commit d25b32aa829a3ed5570138e541a71fb7805faec3 ]
    
    Commit 27fc10d1095f ("drm/amd/display: Fix the delta clamping for shaper
    LUT") fixed banding when using plane shaper LUT in DCN10 CM helper.  The
    problem is also present in DCN30 CM helper, fix banding by extending the
    same bug delta clamping fix to CM3.
    
    Signed-off-by: Melissa Wen <mwen@igalia.com>
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 0274a54897f356f9c78767c4a2a5863f7dde90c6)
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f2584f791a10343bdc995ff6ff402db45b95de69
Author: Deepanshu Kartikey <kartikey406@gmail.com>
Date:   Fri Jan 30 21:22:15 2026 +0530

    tracing/dma: Cap dma_map_sg tracepoint arrays to prevent buffer overflow
    
    [ Upstream commit daafcc0ef0b358d9d622b6e3b7c43767aa3814ee ]
    
    The dma_map_sg tracepoint can trigger a perf buffer overflow when
    tracing large scatter-gather lists. With devices like virtio-gpu
    creating large DRM buffers, nents can exceed 1000 entries, resulting
    in:
    
      phys_addrs: 1000 * 8 bytes = 8,000 bytes
      dma_addrs:  1000 * 8 bytes = 8,000 bytes
      lengths:    1000 * 4 bytes = 4,000 bytes
      Total: ~20,000 bytes
    
    This exceeds PERF_MAX_TRACE_SIZE (8192 bytes), causing:
    
      WARNING: CPU: 0 PID: 5497 at kernel/trace/trace_event_perf.c:405
      perf buffer not large enough, wanted 24620, have 8192
    
    Cap all three dynamic arrays at 128 entries using min() in the array
    size calculation. This ensures arrays are only as large as needed
    (up to the cap), avoiding unnecessary memory allocation for small
    operations while preventing overflow for large ones.
    
    The tracepoint now records the full nents/ents counts and a truncated
    flag so users can see when data has been capped.
    
    Changes in v2:
    - Use min(nents, DMA_TRACE_MAX_ENTRIES) for dynamic array sizing
      instead of fixed DMA_TRACE_MAX_ENTRIES allocation (feedback from
      Steven Rostedt)
    - This allocates only what's needed up to the cap, avoiding waste
      for small operations
    
    Reported-by: syzbot+28cea38c382fd15e751a@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=28cea38c382fd15e751a
    Tested-by: syzbot+28cea38c382fd15e751a@syzkaller.appspotmail.com
    Signed-off-by: Deepanshu Kartikey <Kartikey406@gmail.com>
    Reviwed-by: Sean Anderson <sean.anderson@linux.dev>
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Link: https://lore.kernel.org/r/20260130155215.69737-1-kartikey406@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7bc40c6f36575291ed04470e0e15bddb19f5b6b6
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Fri Jan 30 15:09:27 2026 +0000

    ASoC: cs42l43: Correct handling of 3-pole jack load detection
    
    [ Upstream commit e77a4081d7e324dfa876a9560b2a78969446ba82 ]
    
    The load detection process for 3-pole jacks requires slightly
    updated reference values to ensure an accurate result. Update
    the code to apply different tunings for the 3-pole and 4-pole
    cases. This also updates the thresholds overall so update the
    relevant comments to match.
    
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://patch.msgid.link/20260130150927.2964664-1-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8ed5b974a24418d43697c2ee828df10c450b987
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Jan 20 16:43:44 2026 +0100

    platform/x86: panasonic-laptop: Fix sysfs group leak in error path
    
    [ Upstream commit 43b0b7eff4b3fb684f257d5a24376782e9663465 ]
    
    The acpi_pcc_hotkey_add() error path leaks sysfs group pcc_attr_group
    if platform_device_register_simple() fails for the "panasonic" platform
    device.
    
    Address this by making it call sysfs_remove_group() in that case for
    the group in question.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Link: https://patch.msgid.link/3398370.44csPzL39Z@rafael.j.wysocki
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2ca80dd4bb0e2050586bb8c549bcc72d16bd8bcd
Author: Maciej Strozek <mstrozek@opensource.cirrus.com>
Date:   Wed Jan 28 09:24:05 2026 +0000

    ASoC: sof_sdw: Add a quirk for Lenovo laptop using sidecar amps with cs42l43
    
    [ Upstream commit 1425900231372acf870dd89e8d3bb4935f7f0c81 ]
    
    Add a quirk for a Lenovo laptop (SSID: 0x17aa3821) to allow using sidecar
    CS35L57 amps with CS42L43 codec.
    
    Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
    Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://patch.msgid.link/20260128092410.1540583-1-mstrozek@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bb6ff25035da56aa915e4974f68649fa74659e66
Author: gongqi <550230171hxy@gmail.com>
Date:   Thu Jan 22 23:55:00 2026 +0800

    platform/x86/amd/pmc: Add quirk for MECHREVO Wujie 15X Pro
    
    [ Upstream commit 2b4e00d8e70ca8736fda82447be6a4e323c6d1f5 ]
    
    The MECHREVO Wujie 15X Pro suffers from spurious IRQ issues related to
    the AMD PMC. Add it to the quirk list to use the spurious_8042 fix.
    
    Signed-off-by: gongqi <550230171hxy@gmail.com>
    Link: https://patch.msgid.link/20260122155501.376199-4-550230171hxy@gmail.com
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a9584e9e464480042a5fc43bf097fa0837da8856
Author: Breno Baptista <brenomb07@gmail.com>
Date:   Wed Feb 4 23:43:41 2026 -0300

    ALSA: hda/realtek: Enable headset mic for Acer Nitro 5
    
    [ Upstream commit 51db05283f7c9c95a3e6853a3044cd04226551bf ]
    
    Add quirk to support microphone input through headphone jack on Acer Nitro 5 AN515-57 (ALC295).
    
    Signed-off-by: Breno Baptista <brenomb07@gmail.com>
    Link: https://patch.msgid.link/20260205024341.26694-1-brenomb07@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 78783e8d588cf79abcbe487b1c4da80621c39070
Author: Dirk Su <dirk.su@canonical.com>
Date:   Thu Jan 29 14:50:19 2026 +0800

    ASoC: amd: yc: Add quirk for HP 200 G2a 16
    
    [ Upstream commit 611c7d2262d5645118e0b3a9a88475d35a8366f2 ]
    
    Fix the missing mic on HP 200 G2a 16 by adding quirk with the
    board ID 8EE4
    
    Signed-off-by: Dirk Su <dirk.su@canonical.com>
    Link: https://patch.msgid.link/20260129065038.39349-1-dirk.su@canonical.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c3b2e922924bfbb9a2f4541bec2c7d2249399631
Author: Tagir Garaev <tgaraev653@gmail.com>
Date:   Sun Feb 1 15:17:28 2026 +0300

    ASoC: Intel: sof_es8336: Add DMI quirk for Huawei BOD-WXX9
    
    [ Upstream commit 6b641122d31f9d33e7d60047ee0586d1659f3f54 ]
    
    Add DMI entry for Huawei Matebook D (BOD-WXX9) with HEADPHONE_GPIO
    and DMIC quirks.
    
    This device has ES8336 codec with:
    - GPIO 16 (headphone-enable) for headphone amplifier control
    - GPIO 17 (speakers-enable) for speaker amplifier control
    - GPIO 269 for jack detection IRQ
    - 2-channel DMIC
    
    Hardware investigation shows that both GPIO 16 and 17 are required
    for proper audio routing, as headphones and speakers share the same
    physical output (HPOL/HPOR) and are separated only via amplifier
    enable signals.
    
    RFC: Seeking advice on GPIO control issue:
    
    GPIO values change in driver (gpiod_get_value() shows logical value
    changes) but not physically (debugfs gpio shows no change). The same
    gpiod_set_value_cansleep() calls work correctly in probe context with
    msleep(), but fail when called from DAPM event callbacks.
    
    Context information from diagnostics:
    - in_atomic=0, in_interrupt=0, irqs_disabled=0
    - Process context: pipewire
    - GPIO 17 (speakers): changes in driver, no physical change
    - GPIO 16 (headphone): changes in driver, no physical change
    
    In Windows, audio switching works without visible GPIO changes,
    suggesting possible ACPI/firmware involvement.
    
    Any suggestions on how to properly control these GPIOs from DAPM
    events would be appreciated.
    
    Signed-off-by: Tagir Garaev <tgaraev653@gmail.com>
    Link: https://patch.msgid.link/20260201121728.16597-1-tgaraev653@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 97528b1622b8f129574d29a571c32a3c85eafa3c
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon Jan 26 21:02:40 2026 +0100

    platform/x86: classmate-laptop: Add missing NULL pointer checks
    
    [ Upstream commit fe747d7112283f47169e9c16e751179a9b38611e ]
    
    In a few places in the Classmate laptop driver, code using the accel
    object may run before that object's address is stored in the driver
    data of the input device using it.
    
    For example, cmpc_accel_sensitivity_store_v4() is the "show" method
    of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(),
    before calling dev_set_drvdata() for inputdev->dev.  If the sysfs
    attribute is accessed prematurely, the dev_get_drvdata(&inputdev->dev)
    call in in cmpc_accel_sensitivity_store_v4() returns NULL which
    leads to a NULL pointer dereference going forward.
    
    Moreover, sysfs attributes using the input device are added before
    initializing that device by cmpc_add_acpi_notify_device() and if one
    of them is accessed before running that function, a NULL pointer
    dereference will occur.
    
    For example, cmpc_accel_sensitivity_attr_v4 is added before calling
    cmpc_add_acpi_notify_device() and if it is read prematurely, the
    dev_get_drvdata(&acpi->dev) call in cmpc_accel_sensitivity_show_v4()
    returns NULL which leads to a NULL pointer dereference going forward.
    
    Fix this by adding NULL pointer checks in all of the relevant places.
    
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Link: https://patch.msgid.link/12825381.O9o76ZdvQC@rafael.j.wysocki
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit efdb9c8ca3cfb132b29d68d506e3bb5dee3b9c83
Author: Brahmajit Das <listout@listout.xyz>
Date:   Tue Sep 2 02:50:20 2025 +0530

    drm/tegra: hdmi: sor: Fix error: variable ‘j’ set but not used
    
    [ Upstream commit 1beee8d0c263b3e239c8d6616e4f8bb700bed658 ]
    
    The variable j is set, however never used in or outside the loop, thus
    resulting in dead code.
    Building with GCC 16 results in a build error due to
    -Werror=unused-but-set-variable= enabled by default.
    This patch clean up the dead code and fixes the build error.
    
    Example build log:
    drivers/gpu/drm/tegra/sor.c:1867:19: error: variable ‘j’ set but not used [-Werror=unused-but-set-variable=]
     1867 |         size_t i, j;
          |                   ^
    
    Signed-off-by: Brahmajit Das <listout@listout.xyz>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Link: https://lore.kernel.org/r/20250901212020.3757519-1-listout@listout.xyz
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4b71ad7676564a94ec5f7d18298f51e8ae53db73
Author: Deepanshu Kartikey <kartikey406@gmail.com>
Date:   Tue Jan 13 14:10:37 2026 +0530

    romfs: check sb_set_blocksize() return value
    
    [ Upstream commit ab7ad7abb3660c58ffffdf07ff3bb976e7e0afa0 ]
    
    romfs_fill_super() ignores the return value of sb_set_blocksize(), which
    can fail if the requested block size is incompatible with the block
    device's configuration.
    
    This can be triggered by setting a loop device's block size larger than
    PAGE_SIZE using ioctl(LOOP_SET_BLOCK_SIZE, 32768), then mounting a romfs
    filesystem on that device.
    
    When sb_set_blocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the
    device has logical_block_size=32768, bdev_validate_blocksize() fails
    because the requested size is smaller than the device's logical block
    size. sb_set_blocksize() returns 0 (failure), but romfs ignores this and
    continues mounting.
    
    The superblock's block size remains at the device's logical block size
    (32768). Later, when sb_bread() attempts I/O with this oversized block
    size, it triggers a kernel BUG in folio_set_bh():
    
        kernel BUG at fs/buffer.c:1582!
        BUG_ON(size > PAGE_SIZE);
    
    Fix by checking the return value of sb_set_blocksize() and failing the
    mount with -EINVAL if it returns 0.
    
    Reported-by: syzbot+9c4e33e12283d9437c25@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=9c4e33e12283d9437c25
    Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
    Link: https://patch.msgid.link/20260113084037.1167887-1-kartikey406@gmail.com
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d2e01e0c5e947da0b5005ca89efa82baeb232adc
Author: Kailang Yang <kailang@realtek.com>
Date:   Fri Jan 23 15:21:36 2026 +0800

    ALSA: hda/realtek - fixed speaker no sound
    
    [ Upstream commit 630fbc6e870eb06c5126cc97a3abecbe012272c8 ]
    
    If it play a 5s above silence media stream, it will cause silence
    detection trigger.
    Speaker will make no sound when you use another app to play a stream.
    Add this patch will solve this issue.
    
    GPIO2: Mute Hotkey GPIO3: Mic Mute LED
    Enable this will turn on hotkey and LED support.
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Link: https://lore.kernel.org/f4929e137a7949238cc043d861a4d9f8@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20bc7062c352fcb252dce1901930c3948d4585c7
Author: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
Date:   Thu Jan 15 19:25:10 2026 +0000

    ASoC: cs35l45: Corrects ASP_TX5 DAPM widget channel
    
    [ Upstream commit 6dd0fdc908c02318c28ec2c0979661846ee0a9f7 ]
    
    ASP_TX5 was incorrectly mapped to a channel value of 3 corrects,
    the channel value of 4.
    
    Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Signed-off-by: Ricardo Rivera-Matos <rriveram@opensource.cirrus.com>
    Link: https://patch.msgid.link/20260115192523.1335742-2-rriveram@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1bdbcf326474cd962a2388df52525e14b42a44d5
Author: Zhang Heng <zhangheng@kylinos.cn>
Date:   Mon Jan 26 15:35:08 2026 +0800

    ALSA: hda/realtek: Add quirk for Inspur S14-G1
    
    [ Upstream commit 9e18920e783d0bcd4c127a7adc66565243ab9655 ]
    
    Inspur S14-G1 is equipped with ALC256.
    Enable "power saving mode" and Enable "headset jack mode".
    
    Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
    Link: https://patch.msgid.link/20260126073508.3897461-2-zhangheng@kylinos.cn
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b0b2cb84b64a9e380a27ab7e006cb1dd2474a4a7
Author: Xuewen Yan <xuewen.yan@unisoc.com>
Date:   Mon Jan 26 17:42:09 2026 +0800

    gpio: sprd: Change sprd_gpio lock to raw_spin_lock
    
    [ Upstream commit 96313fcc1f062ba239f4832c9eff685da6c51c99 ]
    
    There was a lockdep warning in sprd_gpio:
    
    [    6.258269][T329@C6] [ BUG: Invalid wait context ]
    [    6.258270][T329@C6] 6.18.0-android17-0-g30527ad7aaae-ab00009-4k #1 Tainted: G        W  OE
    [    6.258272][T329@C6] -----------------------------
    [    6.258273][T329@C6] modprobe/329 is trying to lock:
    [    6.258275][T329@C6] ffffff8081c91690 (&sprd_gpio->lock){....}-{3:3}, at: sprd_gpio_irq_unmask+0x4c/0xa4 [gpio_sprd]
    [    6.258282][T329@C6] other info that might help us debug this:
    [    6.258283][T329@C6] context-{5:5}
    [    6.258285][T329@C6] 3 locks held by modprobe/329:
    [    6.258286][T329@C6]  #0: ffffff808baca108 (&dev->mutex){....}-{4:4}, at: __driver_attach+0xc4/0x204
    [    6.258295][T329@C6]  #1: ffffff80965e7240 (request_class#4){+.+.}-{4:4}, at: __setup_irq+0x1cc/0x82c
    [    6.258304][T329@C6]  #2: ffffff80965e70c8 (lock_class#4){....}-{2:2}, at: __setup_irq+0x21c/0x82c
    [    6.258313][T329@C6] stack backtrace:
    [    6.258314][T329@C6] CPU: 6 UID: 0 PID: 329 Comm: modprobe Tainted: G        W  OE       6.18.0-android17-0-g30527ad7aaae-ab00009-4k #1 PREEMPT  3ad5b0f45741a16e5838da790706e16ceb6717df
    [    6.258316][T329@C6] Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
    [    6.258317][T329@C6] Hardware name: Unisoc UMS9632-base Board (DT)
    [    6.258318][T329@C6] Call trace:
    [    6.258318][T329@C6]  show_stack+0x20/0x30 (C)
    [    6.258321][T329@C6]  __dump_stack+0x28/0x3c
    [    6.258324][T329@C6]  dump_stack_lvl+0xac/0xf0
    [    6.258326][T329@C6]  dump_stack+0x18/0x3c
    [    6.258329][T329@C6]  __lock_acquire+0x824/0x2c28
    [    6.258331][T329@C6]  lock_acquire+0x148/0x2cc
    [    6.258333][T329@C6]  _raw_spin_lock_irqsave+0x6c/0xb4
    [    6.258334][T329@C6]  sprd_gpio_irq_unmask+0x4c/0xa4 [gpio_sprd 814535e93c6d8e0853c45c02eab0fa88a9da6487]
    [    6.258337][T329@C6]  irq_startup+0x238/0x350
    [    6.258340][T329@C6]  __setup_irq+0x504/0x82c
    [    6.258342][T329@C6]  request_threaded_irq+0x118/0x184
    [    6.258344][T329@C6]  devm_request_threaded_irq+0x94/0x120
    [    6.258347][T329@C6]  sc8546_init_irq+0x114/0x170 [sc8546_charger 223586ccafc27439f7db4f95b0c8e6e882349a99]
    [    6.258352][T329@C6]  sc8546_charger_probe+0x53c/0x5a0 [sc8546_charger 223586ccafc27439f7db4f95b0c8e6e882349a99]
    [    6.258358][T329@C6]  i2c_device_probe+0x2c8/0x350
    [    6.258361][T329@C6]  really_probe+0x1a8/0x46c
    [    6.258363][T329@C6]  __driver_probe_device+0xa4/0x10c
    [    6.258366][T329@C6]  driver_probe_device+0x44/0x1b4
    [    6.258369][T329@C6]  __driver_attach+0xd0/0x204
    [    6.258371][T329@C6]  bus_for_each_dev+0x10c/0x168
    [    6.258373][T329@C6]  driver_attach+0x2c/0x3c
    [    6.258376][T329@C6]  bus_add_driver+0x154/0x29c
    [    6.258378][T329@C6]  driver_register+0x70/0x10c
    [    6.258381][T329@C6]  i2c_register_driver+0x48/0xc8
    [    6.258384][T329@C6]  init_module+0x28/0xfd8 [sc8546_charger 223586ccafc27439f7db4f95b0c8e6e882349a99]
    [    6.258389][T329@C6]  do_one_initcall+0x128/0x42c
    [    6.258392][T329@C6]  do_init_module+0x60/0x254
    [    6.258395][T329@C6]  load_module+0x1054/0x1220
    [    6.258397][T329@C6]  __arm64_sys_finit_module+0x240/0x35c
    [    6.258400][T329@C6]  invoke_syscall+0x60/0xec
    [    6.258402][T329@C6]  el0_svc_common+0xb0/0xe4
    [    6.258405][T329@C6]  do_el0_svc+0x24/0x30
    [    6.258407][T329@C6]  el0_svc+0x54/0x1c4
    [    6.258409][T329@C6]  el0t_64_sync_handler+0x68/0xdc
    [    6.258411][T329@C6]  el0t_64_sync+0x1c4/0x1c8
    
    This is because the spin_lock would change to rt_mutex in PREEMPT_RT,
    however the sprd_gpio->lock would use in hard-irq, this is unsafe.
    
    So change the spin_lock_t to raw_spin_lock_t to use the spinlock
    in hard-irq.
    
    Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com>
    Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: https://lore.kernel.org/r/20260126094209.9855-1-xuewen.yan@unisoc.com
    [Bartosz: tweaked the commit message]
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 652667ac1369eaf1eb03ef7db01bd94ac12dcc53
Author: Anatolii Shirykalov <pipocavsobake@gmail.com>
Date:   Mon Jan 19 15:56:18 2026 +0100

    ASoC: amd: yc: Add ASUS ExpertBook PM1503CDA to quirks list
    
    [ Upstream commit 018b211b1d321a52ed8d8de74ce83ce52a2e1224 ]
    
    Add ASUS ExpertBook PM1503CDA to the DMI quirks table to enable
    internal DMIC support via the ACP6x machine driver.
    
    Signed-off-by: Anatolii Shirykalov <pipocavsobake@gmail.com>
    Link: https://patch.msgid.link/20260119145618.3171435-1-pipocavsobake@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 464a50c6b23aab9bd0041725e84f386c3cf9af9f
Author: Alice Ryhl <aliceryhl@google.com>
Date:   Sat Dec 27 15:47:21 2025 +0000

    rust: driver: fix broken intra-doc links to example driver types
    
    commit 4c9f6a782f6078dc94450fcb22e65d520bfa0775 upstream.
    
    The `auxiliary` and `pci` modules are conditional on
    `CONFIG_AUXILIARY_BUS` and `CONFIG_PCI` respectively. When these are
    disabled, the intra-doc links to `auxiliary::Driver` and `pci::Driver`
    break, causing rustdoc warnings (or errors with `-D warnings`).
    
    error: unresolved link to `kernel::auxiliary::Driver`
      --> rust/kernel/driver.rs:82:28
       |
    82 | //! [`auxiliary::Driver`]: kernel::auxiliary::Driver
       |                            ^^^^^^^^^^^^^^^^^^^^^^^^^ no item named `auxiliary` in module `kernel`
    
    Fix this by making the documentation for these examples conditional on
    the corresponding configuration options.
    
    Fixes: 970a7c68788e ("driver: rust: expand documentation for driver infrastructure")
    Signed-off-by: Alice Ryhl <aliceryhl@google.com>
    Reported-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
    Closes: https://lore.kernel.org/rust-for-linux/20251209.151817.744108529426448097.fujita.tomonori@gmail.com/
    Link: https://patch.msgid.link/20251227-driver-types-v1-1-1916154fbe5e@google.com
    Signed-off-by: Danilo Krummrich <dakr@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d82e965fe0e3aa6776d4965af1f42dd132281f4
Author: FUJITA Tomonori <fujita.tomonori@gmail.com>
Date:   Wed Dec 31 13:57:27 2025 +0900

    rust: dma: fix broken intra-doc links
    
    commit 32cb3840386fd3684fbe8294cfc0a6684417139e upstream.
    
    The `pci` module is conditional on CONFIG_PCI. When it's disabled, the
    intra-doc link to `pci::Device` causes rustdoc warnings:
    
    warning: unresolved link to `::kernel::pci::Device`
      --> rust/kernel/dma.rs:30:70
       |
    30 | /// where the underlying bus is DMA capable, such as [`pci::Device`](::kernel::pci::Device) or
       |                                                                      ^^^^^^^^^^^^^^^^^^^^^ no item named `pci` in module `kernel`
    
    Fix this by making the documentation conditional on CONFIG_PCI.
    
    Fixes: d06d5f66f549 ("rust: dma: implement `dma::Device` trait")
    Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
    Reviewed-by: Dirk Behme <dirk.behme@de.bosch.com>
    Link: https://patch.msgid.link/20251231045728.1912024-1-fujita.tomonori@gmail.com
    [ Keep the "such as" part indicating a list of examples; fix typos in
      commit message. - Danilo ]
    Signed-off-by: Danilo Krummrich <dakr@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68dd6c5ebe7991aa8dee221ca78bc8b93958e92b
Author: FUJITA Tomonori <fujita.tomonori@gmail.com>
Date:   Wed Dec 31 13:57:28 2025 +0900

    rust: device: fix broken intra-doc links
    
    commit a9a42f0754b6c69525612d678b73da790e28b9fd upstream.
    
    The `pci` module is conditional on CONFIG_PCI. When it's disabled, the
    intra-doc link to `pci::Device` causes rustdoc warnings:
    
    warning: unresolved link to `kernel::pci::Device`
       --> rust/kernel/device.rs:163:22
        |
    163 | /// [`pci::Device`]: kernel::pci::Device
        |                      ^^^^^^^^^^^^^^^^^^^ no item named `pci` in module `kernel`
        |
        = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default
    
    Fix this by making the documentation conditional on CONFIG_PCI.
    
    Fixes: d6e26c1ae4a6 ("device: rust: expand documentation for Device")
    Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
    Reviewed-by: Dirk Behme <dirk.behme@de.bosch.com>
    Link: https://patch.msgid.link/20251231045728.1912024-2-fujita.tomonori@gmail.com
    [ Keep the "such as" part indicating a list of examples; fix typos in
      commit message. - Danilo ]
    Signed-off-by: Danilo Krummrich <dakr@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 31f33b856d2324d86bcaef295f4d210477a1c018
Author: Anil Gurumurthy <agurumurthy@marvell.com>
Date:   Wed Dec 10 15:46:03 2025 +0530

    scsi: qla2xxx: Fix bsg_done() causing double free
    
    commit c2c68225b1456f4d0d393b5a8778d51bb0d5b1d0 upstream.
    
    Kernel panic observed on system,
    
    [5353358.825191] BUG: unable to handle page fault for address: ff5f5e897b024000
    [5353358.825194] #PF: supervisor write access in kernel mode
    [5353358.825195] #PF: error_code(0x0002) - not-present page
    [5353358.825196] PGD 100006067 P4D 0
    [5353358.825198] Oops: 0002 [#1] PREEMPT SMP NOPTI
    [5353358.825200] CPU: 5 PID: 2132085 Comm: qlafwupdate.sub Kdump: loaded Tainted: G        W    L    -------  ---  5.14.0-503.34.1.el9_5.x86_64 #1
    [5353358.825203] Hardware name: HPE ProLiant DL360 Gen11/ProLiant DL360 Gen11, BIOS 2.44 01/17/2025
    [5353358.825204] RIP: 0010:memcpy_erms+0x6/0x10
    [5353358.825211] RSP: 0018:ff591da8f4f6b710 EFLAGS: 00010246
    [5353358.825212] RAX: ff5f5e897b024000 RBX: 0000000000007090 RCX: 0000000000001000
    [5353358.825213] RDX: 0000000000001000 RSI: ff591da8f4fed090 RDI: ff5f5e897b024000
    [5353358.825214] RBP: 0000000000010000 R08: ff5f5e897b024000 R09: 0000000000000000
    [5353358.825215] R10: ff46cf8c40517000 R11: 0000000000000001 R12: 0000000000008090
    [5353358.825216] R13: ff591da8f4f6b720 R14: 0000000000001000 R15: 0000000000000000
    [5353358.825218] FS:  00007f1e88d47740(0000) GS:ff46cf935f940000(0000) knlGS:0000000000000000
    [5353358.825219] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [5353358.825220] CR2: ff5f5e897b024000 CR3: 0000000231532004 CR4: 0000000000771ef0
    [5353358.825221] PKRU: 55555554
    [5353358.825222] Call Trace:
    [5353358.825223]  <TASK>
    [5353358.825224]  ? show_trace_log_lvl+0x1c4/0x2df
    [5353358.825229]  ? show_trace_log_lvl+0x1c4/0x2df
    [5353358.825232]  ? sg_copy_buffer+0xc8/0x110
    [5353358.825236]  ? __die_body.cold+0x8/0xd
    [5353358.825238]  ? page_fault_oops+0x134/0x170
    [5353358.825242]  ? kernelmode_fixup_or_oops+0x84/0x110
    [5353358.825244]  ? exc_page_fault+0xa8/0x150
    [5353358.825247]  ? asm_exc_page_fault+0x22/0x30
    [5353358.825252]  ? memcpy_erms+0x6/0x10
    [5353358.825253]  sg_copy_buffer+0xc8/0x110
    [5353358.825259]  qla2x00_process_vendor_specific+0x652/0x1320 [qla2xxx]
    [5353358.825317]  qla24xx_bsg_request+0x1b2/0x2d0 [qla2xxx]
    
    Most routines in qla_bsg.c call bsg_done() only for success cases.
    However a few invoke it for failure case as well leading to a double
    free. Validate before calling bsg_done().
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Anil Gurumurthy <agurumurthy@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
    Link: https://patch.msgid.link/20251210101604.431868-12-njavali@marvell.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04b5bae7c5a2a0d77a245b033864c5afe0cad359
Author: Alexandre Frade <kernel@xanmod.org>
Date:   Tue Feb 17 20:57:56 2026 +0000

    Linux 6.18.12-xanmod1
    
    Signed-off-by: Alexandre Frade <kernel@xanmod.org>

commit 037f15decce6d6b71d4e161b9b4c9ff24c87e37d
Merge: 4f7ecb3fce0a 2784b1b43af3
Author: Alexandre Frade <kernel@xanmod.org>
Date:   Tue Feb 17 20:57:13 2026 +0000

    Merge tag 'v6.18.12' into 6.18
    
    This is the 6.18.12 stable release

commit 2784b1b43af3711a6268a616eb8f41f9788c6e3a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 16 17:10:28 2026 +0100

    Linux 6.18.12
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53a76425e0764421ba93bb9045d2e454667d5687
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 16 16:41:21 2026 +0100

    Revert "driver core: enforce device_lock for driver_match_device()"
    
    This reverts commit 8d76b2488eb3cc0717ab81b60622cff4a5f90f79 which is
    commit dc23806a7c47ec5f1293aba407fb69519f976ee0 upstream.
    
    It causes boot regressions on some systems as all of the "fixes" for
    drivers are not properly backported yet.  Once that is completed, only
    then can this be applied, if really necessary given the potential for
    explosions, perhaps we might want to wait a few -rc releases first...
    
    Cc: Danilo Krummrich <dakr@kernel.org>
    Cc: Rafael J. Wysocki (Intel) <rafael@kernel.org>
    Cc: Danilo Krummrich <dakr@kernel.org>
    Cc: Gui-Dong Han <hanguidong02@gmail.com>
    Cc: Qiu-ji Chen <chenqiuji666@gmail.com>
    Reported-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/7dfd0e63-a725-4fac-b2a0-f2e621d99d1b@sirena.org.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee4fb138af107455c9d6e38cf7087d932796ba8a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Feb 16 10:19:46 2026 +0100

    Linux 6.18.11
    
    Link: https://lore.kernel.org/r/20260213134708.885500854@linuxfoundation.org
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
    Tested-by: Ronald Warsow <rwarsow@gmx.de>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Brett Mastbergen <bmastbergen@ciq.com>
    Tested-by: Luna Jernberg <droidbittin@gmail.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Brett A C Sheffield <bacs@librecast.net>
    Tested-by: Barry K. Nathan <barryn@pobox.com>
    Tested-by: Miguel Ojeda <ojeda@kernel.org>
    Tested-by: Dileep Malepu <dileep.debian@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32f08c3ddd6dda6cbb6c9d715de10f21dccde50f
Author: Danilo Krummrich <dakr@kernel.org>
Date:   Tue Jan 27 21:17:12 2026 +0100

    gpio: omap: do not register driver in probe()
    
    commit 730e5ebff40c852e3ea57b71bf02a4b89c69435f upstream.
    
    Commit 11a78b794496 ("ARM: OMAP: MPUIO wake updates") registers the
    omap_mpuio_driver from omap_mpuio_init(), which is called from
    omap_gpio_probe().
    
    However, it neither makes sense to register drivers from probe()
    callbacks of other drivers, nor does the driver core allow registering
    drivers with a device lock already being held.
    
    The latter was revealed by commit dc23806a7c47 ("driver core: enforce
    device_lock for driver_match_device()") leading to a potential deadlock
    condition described in [1].
    
    Additionally, the omap_mpuio_driver is never unregistered from the
    driver core, even if the module is unloaded.
    
    Hence, register the omap_mpuio_driver from the module initcall and
    unregister it in module_exit().
    
    Link: https://lore.kernel.org/lkml/DFU7CEPUSG9A.1KKGVW4HIPMSH@kernel.org/ [1]
    Fixes: dc23806a7c47 ("driver core: enforce device_lock for driver_match_device()")
    Fixes: 11a78b794496 ("ARM: OMAP: MPUIO wake updates")
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Danilo Krummrich <dakr@kernel.org>
    Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
    Link: https://patch.msgid.link/20260127201725.35883-1-dakr@kernel.org
    Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 116f7bd8160c6b37d1c6939385abf90f6f6ed2f5
Author: Ali Tariq <alitariq45892@gmail.com>
Date:   Thu Dec 25 11:54:29 2025 +0000

    wifi: rtl8xxxu: fix slab-out-of-bounds in rtl8xxxu_sta_add
    
    commit 86c946bcc00f6390ef65e9614ae60a9377e454f8 upstream.
    
    The driver does not set hw->sta_data_size, which causes mac80211 to
    allocate insufficient space for driver private station data in
    __sta_info_alloc(). When rtl8xxxu_sta_add() accesses members of
    struct rtl8xxxu_sta_info through sta->drv_priv, this results in a
    slab-out-of-bounds write.
    
    KASAN report on RISC-V (VisionFive 2) with RTL8192EU adapter:
    
      BUG: KASAN: slab-out-of-bounds in rtl8xxxu_sta_add+0x31c/0x346
      Write of size 8 at addr ffffffd6d3e9ae88 by task kworker/u16:0/12
    
    Set hw->sta_data_size to sizeof(struct rtl8xxxu_sta_info) during
    probe, similar to how hw->vif_data_size is configured. This ensures
    mac80211 allocates sufficient space for the driver's per-station
    private data.
    
    Tested on StarFive VisionFive 2 v1.2A board.
    
    Fixes: eef55f1545c9 ("wifi: rtl8xxxu: support multiple interfaces in {add,remove}_interface()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Ali Tariq <alitariq45892@gmail.com>
    Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/20251225115430.13011-1-alitariq45892@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24a253c3aa6d9a2cde46158ce9782e023bfbf32d
Author: Liu Song <liu.song13@zte.com.cn>
Date:   Thu Jul 10 14:38:45 2025 +0800

    PCI: endpoint: Avoid creating sub-groups asynchronously
    
    commit 7c5c7d06bd1f86d2c3ebe62be903a4ba42db4d2c upstream.
    
    The asynchronous creation of sub-groups by a delayed work could lead to a
    NULL pointer dereference when the driver directory is removed before the
    work completes.
    
    The crash can be easily reproduced with the following commands:
    
      # cd /sys/kernel/config/pci_ep/functions/pci_epf_test
      # for i in {1..20}; do mkdir test && rmdir test; done
    
      BUG: kernel NULL pointer dereference, address: 0000000000000088
      ...
      Call Trace:
       configfs_register_group+0x3d/0x190
       pci_epf_cfs_work+0x41/0x110
       process_one_work+0x18f/0x350
       worker_thread+0x25a/0x3a0
    
    Fix this issue by using configfs_add_default_group() API which does not
    have the deadlock problem as configfs_register_group() and does not require
    the delayed work handler.
    
    Fixes: e85a2d783762 ("PCI: endpoint: Add support in configfs to associate two EPCs with EPF")
    Signed-off-by: Liu Song <liu.song13@zte.com.cn>
    [mani: slightly reworded the description and added stable list]
    Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@kernel.org
    Link: https://patch.msgid.link/20250710143845409gLM6JdlwPhlHG9iX3F6jK@zte.com.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60b75407c172e1f341a8a5097c5cbc97dbbdd893
Author: Jeongjun Park <aha310510@gmail.com>
Date:   Mon Jan 19 17:25:53 2026 +0900

    drm/exynos: vidi: use ctx->lock to protect struct vidi_context member variables related to memory alloc/free
    
    commit 52b330799e2d6f825ae2bb74662ec1b10eb954bb upstream.
    
    Exynos Virtual Display driver performs memory alloc/free operations
    without lock protection, which easily causes concurrency problem.
    
    For example, use-after-free can occur in race scenario like this:
    ```
            CPU0                            CPU1                            CPU2
            ----                            ----                            ----
      vidi_connection_ioctl()
        if (vidi->connection) // true
          drm_edid = drm_edid_alloc(); // alloc drm_edid
          ...
          ctx->raw_edid = drm_edid;
          ...
                                                                    drm_mode_getconnector()
                                                                      drm_helper_probe_single_connector_modes()
                                                                        vidi_get_modes()
                                                                          if (ctx->raw_edid) // true
                                                                            drm_edid_dup(ctx->raw_edid);
                                                                              if (!drm_edid) // false
                                                                              ...
                                    vidi_connection_ioctl()
                                      if (vidi->connection) // false
                                        drm_edid_free(ctx->raw_edid); // free drm_edid
                                        ...
                                                                              drm_edid_alloc(drm_edid->edid)
                                                                                kmemdup(edid); // UAF!!
                                                                                ...
    ```
    
    To prevent these vulns, at least in vidi_context, member variables related
    to memory alloc/free should be protected with ctx->lock.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jeongjun Park <aha310510@gmail.com>
    Signed-off-by: Inki Dae <inki.dae@samsung.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed82e7949f5cac3058f4100f3cd670531d41a266
Author: Darrick J. Wong <djwong@kernel.org>
Date:   Fri Jan 23 09:27:39 2026 -0800

    xfs: fix UAF in xchk_btree_check_block_owner
    
    commit 1c253e11225bc5167217897885b85093e17c2217 upstream.
    
    We cannot dereference bs->cur when trying to determine if bs->cur
    aliases bs->sc->sa.{bno,rmap}_cur after the latter has been freed.
    Fix this by sampling before type before any freeing could happen.
    The correct temporal ordering was broken when we removed xfs_btnum_t.
    
    Cc: r772577952@gmail.com
    Cc: <stable@vger.kernel.org> # v6.9
    Fixes: ec793e690f801d ("xfs: remove xfs_btnum_t")
    Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Tested-by: Jiaming Zhang <r772577952@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d741534302f71c511eb0bb670b92eaa7df4a0aec
Author: Chao Yu <chao@kernel.org>
Date:   Fri Feb 6 06:30:05 2026 +0800

    erofs: fix UAF issue for file-backed mounts w/ directio option
    
    commit 1caf50ce4af096d0280d59a31abdd85703cd995c upstream.
    
    [    9.269940][ T3222] Call trace:
    [    9.269948][ T3222]  ext4_file_read_iter+0xac/0x108
    [    9.269979][ T3222]  vfs_iocb_iter_read+0xac/0x198
    [    9.269993][ T3222]  erofs_fileio_rq_submit+0x12c/0x180
    [    9.270008][ T3222]  erofs_fileio_submit_bio+0x14/0x24
    [    9.270030][ T3222]  z_erofs_runqueue+0x834/0x8ac
    [    9.270054][ T3222]  z_erofs_read_folio+0x120/0x220
    [    9.270083][ T3222]  filemap_read_folio+0x60/0x120
    [    9.270102][ T3222]  filemap_fault+0xcac/0x1060
    [    9.270119][ T3222]  do_pte_missing+0x2d8/0x1554
    [    9.270131][ T3222]  handle_mm_fault+0x5ec/0x70c
    [    9.270142][ T3222]  do_page_fault+0x178/0x88c
    [    9.270167][ T3222]  do_translation_fault+0x38/0x54
    [    9.270183][ T3222]  do_mem_abort+0x54/0xac
    [    9.270208][ T3222]  el0_da+0x44/0x7c
    [    9.270227][ T3222]  el0t_64_sync_handler+0x5c/0xf4
    [    9.270253][ T3222]  el0t_64_sync+0x1bc/0x1c0
    
    EROFS may encounter above panic when enabling file-backed mount w/
    directio mount option, the root cause is it may suffer UAF in below
    race condition:
    
    - z_erofs_read_folio                          wq s_dio_done_wq
     - z_erofs_runqueue
      - erofs_fileio_submit_bio
       - erofs_fileio_rq_submit
        - vfs_iocb_iter_read
         - ext4_file_read_iter
          - ext4_dio_read_iter
           - iomap_dio_rw
           : bio was submitted and return -EIOCBQUEUED
                                                  - dio_aio_complete_work
                                                   - dio_complete
                                                    - dio->iocb->ki_complete (erofs_fileio_ki_complete())
                                                     - kfree(rq)
                                                     : it frees iocb, iocb.ki_filp can be UAF in file_accessed().
           - file_accessed
           : access NULL file point
    
    Introduce a reference count in struct erofs_fileio_rq, and initialize it
    as two, both erofs_fileio_ki_complete() and erofs_fileio_rq_submit() will
    decrease reference count, the last one decreasing the reference count
    to zero will free rq.
    
    Cc: stable@kernel.org
    Fixes: fb176750266a ("erofs: add file-backed mount support")
    Fixes: 6422cde1b0d5 ("erofs: use buffered I/O for file-backed mounts by default")
    Signed-off-by: Chao Yu <chao@kernel.org>
    Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1d6bd6183e723a7b256ff34bbb5b498b5f4f2ec0
Author: Gui-Dong Han <hanguidong02@gmail.com>
Date:   Wed Dec 3 01:44:38 2025 +0800

    bus: fsl-mc: fix use-after-free in driver_override_show()
    
    commit 148891e95014b5dc5878acefa57f1940c281c431 upstream.
    
    The driver_override_show() function reads the driver_override string
    without holding the device_lock. However, driver_override_store() uses
    driver_set_override(), which modifies and frees the string while holding
    the device_lock.
    
    This can result in a concurrent use-after-free if the string is freed
    by the store function while being read by the show function.
    
    Fix this by holding the device_lock around the read operation.
    
    Fixes: 1f86a00c1159 ("bus/fsl-mc: add support for 'driver_override' in the mc-bus")
    Cc: stable@vger.kernel.org
    Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
    Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
    Link: https://lore.kernel.org/r/20251202174438.12658-1-hanguidong02@gmail.com
    Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d14e991279831673729b0f2002905bf3741df55b
Author: Anil Gurumurthy <agurumurthy@marvell.com>
Date:   Wed Dec 10 15:46:02 2025 +0530

    scsi: qla2xxx: Query FW again before proceeding with login
    
    commit 42b2dab4340d39b71334151e10c6d7d9b0040ffa upstream.
    
    Issue occurred during a continuous reboot test of several thousand
    iterations specific to a fabric topo with dual mode target where it
    sends a PLOGI/PRLI and then sends a LOGO. The initiator was also in the
    process of discovery and sent a PLOGI to the switch. It then queried a
    list of ports logged in via mbx 75h and the GPDB response indicated that
    the target was logged in. This caused a mismatch in the states between
    the driver and FW.  Requery the FW for the state and proceed with the
    rest of discovery process.
    
    Fixes: a4239945b8ad ("scsi: qla2xxx: Add switch command to simplify fabric discovery")
    Cc: stable@vger.kernel.org
    Signed-off-by: Anil Gurumurthy <agurumurthy@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
    Link: https://patch.msgid.link/20251210101604.431868-11-njavali@marvell.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f04840512438ac025dea6e357d80a986b28bbe4c
Author: Anil Gurumurthy <agurumurthy@marvell.com>
Date:   Wed Dec 10 15:46:00 2025 +0530

    scsi: qla2xxx: Free sp in error path to fix system crash
    
    commit 7adbd2b7809066c75f0433e5e2a8e114b429f30f upstream.
    
    System crash seen during load/unload test in a loop,
    
    [61110.449331] qla2xxx [0000:27:00.0]-0042:0: Disabled MSI-X.
    [61110.467494] =============================================================================
    [61110.467498] BUG qla2xxx_srbs (Tainted: G           OE    --------  --- ): Objects remaining in qla2xxx_srbs on __kmem_cache_shutdown()
    [61110.467501] -----------------------------------------------------------------------------
    
    [61110.467502] Slab 0x000000000ffc8162 objects=51 used=1 fp=0x00000000e25d3d85 flags=0x57ffffc0010200(slab|head|node=1|zone=2|lastcpupid=0x1fffff)
    [61110.467509] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G           OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1
    [61110.467513] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023
    [61110.467515] Call Trace:
    [61110.467516]  <TASK>
    [61110.467519]  dump_stack_lvl+0x34/0x48
    [61110.467526]  slab_err.cold+0x53/0x67
    [61110.467534]  __kmem_cache_shutdown+0x16e/0x320
    [61110.467540]  kmem_cache_destroy+0x51/0x160
    [61110.467544]  qla2x00_module_exit+0x93/0x99 [qla2xxx]
    [61110.467607]  ? __do_sys_delete_module.constprop.0+0x178/0x280
    [61110.467613]  ? syscall_trace_enter.constprop.0+0x145/0x1d0
    [61110.467616]  ? do_syscall_64+0x5c/0x90
    [61110.467619]  ? exc_page_fault+0x62/0x150
    [61110.467622]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd
    [61110.467626]  </TASK>
    [61110.467627] Disabling lock debugging due to kernel taint
    [61110.467635] Object 0x0000000026f7e6e6 @offset=16000
    [61110.467639] ------------[ cut here ]------------
    [61110.467639] kmem_cache_destroy qla2xxx_srbs: Slab cache still has objects when called from qla2x00_module_exit+0x93/0x99 [qla2xxx]
    [61110.467659] WARNING: CPU: 53 PID: 455206 at mm/slab_common.c:520 kmem_cache_destroy+0x14d/0x160
    [61110.467718] CPU: 53 PID: 455206 Comm: rmmod Kdump: loaded Tainted: G    B      OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1
    [61110.467720] Hardware name: HPE ProLiant DL385 Gen10 Plus v2/ProLiant DL385 Gen10 Plus v2, BIOS A42 08/17/2023
    [61110.467721] RIP: 0010:kmem_cache_destroy+0x14d/0x160
    [61110.467724] Code: 99 7d 07 00 48 89 ef e8 e1 6a 07 00 eb b3 48 8b 55 60 48 8b 4c 24 20 48 c7 c6 70 fc 66 90 48 c7 c7 f8 ef a1 90 e8 e1 ed 7c 00 <0f> 0b eb 93 c3 cc cc cc cc 66 2e 0f 1f 84 00 00 00 00 00 55 48 89
    [61110.467725] RSP: 0018:ffffa304e489fe80 EFLAGS: 00010282
    [61110.467727] RAX: 0000000000000000 RBX: ffffffffc0d9a860 RCX: 0000000000000027
    [61110.467729] RDX: ffff8fd5ff9598a8 RSI: 0000000000000001 RDI: ffff8fd5ff9598a0
    [61110.467730] RBP: ffff8fb6aaf78700 R08: 0000000000000000 R09: 0000000100d863b7
    [61110.467731] R10: ffffa304e489fd20 R11: ffffffff913bef48 R12: 0000000040002000
    [61110.467731] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    [61110.467733] FS:  00007f64c89fb740(0000) GS:ffff8fd5ff940000(0000) knlGS:0000000000000000
    [61110.467734] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [61110.467735] CR2: 00007f0f02bfe000 CR3: 00000020ad6dc005 CR4: 0000000000770ee0
    [61110.467736] PKRU: 55555554
    [61110.467737] Call Trace:
    [61110.467738]  <TASK>
    [61110.467739]  qla2x00_module_exit+0x93/0x99 [qla2xxx]
    [61110.467755]  ? __do_sys_delete_module.constprop.0+0x178/0x280
    
    Free sp in the error path to fix the crash.
    
    Fixes: f352eeb75419 ("scsi: qla2xxx: Add ability to use GPNFT/GNNFT for RSCN handling")
    Cc: stable@vger.kernel.org
    Signed-off-by: Anil Gurumurthy <agurumurthy@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
    Link: https://patch.msgid.link/20251210101604.431868-9-njavali@marvell.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c068ebbaf52820d6bdefb9b405a1e426663c635a
Author: Anil Gurumurthy <agurumurthy@marvell.com>
Date:   Wed Dec 10 15:45:59 2025 +0530

    scsi: qla2xxx: Delay module unload while fabric scan in progress
    
    commit 8890bf450e0b6b283f48ac619fca5ac2f14ddd62 upstream.
    
    System crash seen during load/unload test in a loop.
    
    [105954.384919] RBP: ffff914589838dc0 R08: 0000000000000000 R09: 0000000000000086
    [105954.384920] R10: 000000000000000f R11: ffffa31240904be5 R12: ffff914605f868e0
    [105954.384921] R13: ffff914605f86910 R14: 0000000000008010 R15: 00000000ddb7c000
    [105954.384923] FS:  0000000000000000(0000) GS:ffff9163fec40000(0000) knlGS:0000000000000000
    [105954.384925] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [105954.384926] CR2: 000055d31ce1d6a0 CR3: 0000000119f5e001 CR4: 0000000000770ee0
    [105954.384928] PKRU: 55555554
    [105954.384929] Call Trace:
    [105954.384931]  <IRQ>
    [105954.384934]  qla24xx_sp_unmap+0x1f3/0x2a0 [qla2xxx]
    [105954.384962]  ? qla_async_scan_sp_done+0x114/0x1f0 [qla2xxx]
    [105954.384980]  ? qla24xx_els_ct_entry+0x4de/0x760 [qla2xxx]
    [105954.384999]  ? __wake_up_common+0x80/0x190
    [105954.385004]  ? qla24xx_process_response_queue+0xc2/0xaa0 [qla2xxx]
    [105954.385023]  ? qla24xx_msix_rsp_q+0x44/0xb0 [qla2xxx]
    [105954.385040]  ? __handle_irq_event_percpu+0x3d/0x190
    [105954.385044]  ? handle_irq_event+0x58/0xb0
    [105954.385046]  ? handle_edge_irq+0x93/0x240
    [105954.385050]  ? __common_interrupt+0x41/0xa0
    [105954.385055]  ? common_interrupt+0x3e/0xa0
    [105954.385060]  ? asm_common_interrupt+0x22/0x40
    
    The root cause of this was that there was a free (dma_free_attrs) in the
    interrupt context.  There was a device discovery/fabric scan in
    progress.  A module unload was issued which set the UNLOADING flag.  As
    part of the discovery, after receiving an interrupt a work queue was
    scheduled (which involved a work to be queued).  Since the UNLOADING
    flag is set, the work item was not allocated and the mapped memory had
    to be freed.  The free occurred in interrupt context leading to system
    crash.  Delay the driver unload until the fabric scan is complete to
    avoid the crash.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Closes: https://lore.kernel.org/all/202512090414.07Waorz0-lkp@intel.com/
    Fixes: 783e0dc4f66a ("qla2xxx: Check for device state before unloading the driver.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Anil Gurumurthy <agurumurthy@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
    Link: https://patch.msgid.link/20251210101604.431868-8-njavali@marvell.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae49d33bfc08bfc108b155795c14700d754cf5d2
Author: Shreyas Deodhar <sdeodhar@marvell.com>
Date:   Wed Dec 10 15:45:58 2025 +0530

    scsi: qla2xxx: Allow recovery for tape devices
    
    commit b0335ee4fb94832a4ef68774ca7e7b33b473c7a6 upstream.
    
    Tape device doesn't show up after RSCNs.  To fix this, remove tape
    device specific checks which allows recovery of tape devices.
    
    Fixes: 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target")
    Cc: stable@vger.kernel.org
    Signed-off-by: Shreyas Deodhar <sdeodhar@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
    Link: https://patch.msgid.link/20251210101604.431868-7-njavali@marvell.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1a9585e4c58d1f1662b3ca46110ed4f583082ce5
Author: Anil Gurumurthy <agurumurthy@marvell.com>
Date:   Wed Dec 10 15:46:01 2025 +0530

    scsi: qla2xxx: Validate sp before freeing associated memory
    
    commit b6df15aec8c3441357d4da0eaf4339eb20f5999f upstream.
    
    System crash with the following signature
    [154563.214890] nvme nvme2: NVME-FC{1}: controller connect complete
    [154564.169363] qla2xxx [0000:b0:00.1]-3002:2: nvme: Sched: Set ZIO exchange threshold to 3.
    [154564.169405] qla2xxx [0000:b0:00.1]-ffffff:2: SET ZIO Activity exchange threshold to 5.
    [154565.539974] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 0080 0000.
    [154565.545744] qla2xxx [0000:b0:00.1]-5013:2: RSCN database changed – 0078 00a0 0000.
    [154565.545857] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate).
    [154565.552760] qla2xxx [0000:b0:00.1]-11a2:2: FEC=enabled (data rate).
    [154565.553079] BUG: kernel NULL pointer dereference, address: 00000000000000f8
    [154565.553080] #PF: supervisor read access in kernel mode
    [154565.553082] #PF: error_code(0x0000) - not-present page
    [154565.553084] PGD 80000010488ab067 P4D 80000010488ab067 PUD 104978a067 PMD 0
    [154565.553089] Oops: 0000 1 PREEMPT SMP PTI
    [154565.553092] CPU: 10 PID: 858 Comm: qla2xxx_2_dpc Kdump: loaded Tainted: G           OE     -------  ---  5.14.0-503.11.1.el9_5.x86_64 #1
    [154565.553096] Hardware name: HPE Synergy 660 Gen10/Synergy 660 Gen10 Compute Module, BIOS I43 09/30/2024
    [154565.553097] RIP: 0010:qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx]
    [154565.553141] Code: 00 00 e8 58 a3 ec d4 49 89 e9 ba 12 20 00 00 4c 89 e6 49 c7 c0 00 ee a8 c0 48 c7 c1 66 c0 a9 c0 bf 00 80 00 10 e8 15 69 00 00 <4c> 8b 8d f8 00 00 00 4d 85 c9 74 35 49 8b 84 24 00 19 00 00 48 8b
    [154565.553143] RSP: 0018:ffffb4dbc8aebdd0 EFLAGS: 00010286
    [154565.553145] RAX: 0000000000000000 RBX: ffff8ec2cf0908d0 RCX: 0000000000000002
    [154565.553147] RDX: 0000000000000000 RSI: ffffffffc0a9c896 RDI: ffffb4dbc8aebd47
    [154565.553148] RBP: 0000000000000000 R08: ffffb4dbc8aebd45 R09: 0000000000ffff0a
    [154565.553150] R10: 0000000000000000 R11: 000000000000000f R12: ffff8ec2cf0908d0
    [154565.553151] R13: ffff8ec2cf090900 R14: 0000000000000102 R15: ffff8ec2cf084000
    [154565.553152] FS:  0000000000000000(0000) GS:ffff8ed27f800000(0000) knlGS:0000000000000000
    [154565.553154] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [154565.553155] CR2: 00000000000000f8 CR3: 000000113ae0a005 CR4: 00000000007706f0
    [154565.553157] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [154565.553158] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [154565.553159] PKRU: 55555554
    [154565.553160] Call Trace:
    [154565.553162]  <TASK>
    [154565.553165]  ? show_trace_log_lvl+0x1c4/0x2df
    [154565.553172]  ? show_trace_log_lvl+0x1c4/0x2df
    [154565.553177]  ? qla_fab_async_scan.part.0+0x40b/0x870 [qla2xxx]
    [154565.553215]  ? __die_body.cold+0x8/0xd
    [154565.553218]  ? page_fault_oops+0x134/0x170
    [154565.553223]  ? snprintf+0x49/0x70
    [154565.553229]  ? exc_page_fault+0x62/0x150
    [154565.553238]  ? asm_exc_page_fault+0x22/0x30
    
    Check for sp being non NULL before freeing any associated memory
    
    Fixes: a4239945b8ad ("scsi: qla2xxx: Add switch command to simplify fabric discovery")
    Cc: stable@vger.kernel.org
    Signed-off-by: Anil Gurumurthy <agurumurthy@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
    Link: https://patch.msgid.link/20251210101604.431868-10-njavali@marvell.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 13394550441557115bb74f6de9778c165755a7ab
Author: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Date:   Wed Dec 24 01:24:21 2025 +0200

    wifi: rtw88: Fix alignment fault in rtw_core_enable_beacon()
    
    commit 0177aa828d966117ea30a44f2e1890fdb356118e upstream.
    
    rtw_core_enable_beacon() reads 4 bytes from an address that is not a
    multiple of 4. This results in a crash on some systems.
    
    Do 1 byte reads/writes instead.
    
    Unable to handle kernel paging request at virtual address ffff8000827e0522
    Mem abort info:
      ESR = 0x0000000096000021
      EC = 0x25: DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
      FSC = 0x21: alignment fault
    Data abort info:
      ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000
      CM = 0, WnR = 0, TnD = 0, TagAccess = 0
      GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000005492000
    [ffff8000827e0522] pgd=0000000000000000, p4d=10000001021d9403, pud=10000001021da403, pmd=100000011061c403, pte=00780000f3200f13
    Internal error: Oops: 0000000096000021 [#1]  SMP
    Modules linked in: [...] rtw88_8822ce rtw88_8822c rtw88_pci rtw88_core [...]
    CPU: 0 UID: 0 PID: 73 Comm: kworker/u32:2 Tainted: G        W           6.17.9 #1-NixOS VOLUNTARY
    Tainted: [W]=WARN
    Hardware name: FriendlyElec NanoPC-T6 LTS (DT)
    Workqueue: phy0 rtw_c2h_work [rtw88_core]
    pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : rtw_pci_read32+0x18/0x40 [rtw88_pci]
    lr : rtw_core_enable_beacon+0xe0/0x148 [rtw88_core]
    sp : ffff800080cc3ca0
    x29: ffff800080cc3ca0 x28: ffff0001031fc240 x27: ffff000102100828
    x26: ffffd2cb7c9b4088 x25: ffff0001031fc2c0 x24: ffff000112fdef00
    x23: ffff000112fdef18 x22: ffff000111c29970 x21: 0000000000000001
    x20: 0000000000000001 x19: ffff000111c22040 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
    x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
    x11: 0000000000000000 x10: 0000000000000000 x9 : ffffd2cb6507c090
    x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
    x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
    x2 : 0000000000007f10 x1 : 0000000000000522 x0 : ffff8000827e0522
    Call trace:
     rtw_pci_read32+0x18/0x40 [rtw88_pci] (P)
     rtw_hw_scan_chan_switch+0x124/0x1a8 [rtw88_core]
     rtw_fw_c2h_cmd_handle+0x254/0x290 [rtw88_core]
     rtw_c2h_work+0x50/0x98 [rtw88_core]
     process_one_work+0x178/0x3f8
     worker_thread+0x208/0x418
     kthread+0x120/0x220
     ret_from_fork+0x10/0x20
    Code: d28fe202 8b020000 f9524400 8b214000 (b9400000)
    ---[ end trace 0000000000000000 ]---
    
    Fixes: ad6741b1e044 ("wifi: rtw88: Stop high queue during scan")
    Cc: stable@vger.kernel.org
    Closes: https://github.com/lwfinger/rtw88/issues/418
    Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
    Acked-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
    Link: https://patch.msgid.link/6345300d-8c93-464c-9b05-d0d9af3c97ad@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46c1d56ad321fb024761abd9af61a0cb616cf2f6
Author: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>
Date:   Mon Dec 1 23:23:06 2025 +0100

    hfs: ensure sb->s_fs_info is always cleaned up
    
    commit 05ce49a902be15dc93854cbfc20161205a9ee446 upstream.
    
    When hfs was converted to the new mount api a bug was introduced by
    changing the allocation pattern of sb->s_fs_info. If setup_bdev_super()
    fails after a new superblock has been allocated by sget_fc(), but before
    hfs_fill_super() takes ownership of the filesystem-specific s_fs_info
    data it was leaked.
    
    Fix this by freeing sb->s_fs_info in hfs_kill_super().
    
    Cc: stable@vger.kernel.org
    Fixes: ffcd06b6d13b ("hfs: convert hfs to use the new mount api")
    Reported-by: syzbot+ad45f827c88778ff7df6@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=ad45f827c88778ff7df6
    Tested-by: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Mehdi Ben Hadj Khelifa <mehdi.benhadjkhelifa@gmail.com>
    Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
    Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
    Link: https://lore.kernel.org/r/20251201222843.82310-2-mehdi.benhadjkhelifa@gmail.com
    Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4aa45f841413cca81882602b4042c53502f34cad
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Sat Dec 20 03:04:25 2025 +0900

    nilfs2: Fix potential block overflow that cause system hang
    
    commit ed527ef0c264e4bed6c7b2a158ddf516b17f5f66 upstream.
    
    When a user executes the FITRIM command, an underflow can occur when
    calculating nblocks if end_block is too small. Since nblocks is of
    type sector_t, which is u64, a negative nblocks value will become a
    very large positive integer. This ultimately leads to the block layer
    function __blkdev_issue_discard() taking an excessively long time to
    process the bio chain, and the ns_segctor_sem lock remains held for a
    long period. This prevents other tasks from acquiring the ns_segctor_sem
    lock, resulting in the hang reported by syzbot in [1].
    
    If the ending block is too small, typically if it is smaller than 4KiB
    range, depending on the usage of the segment 0, it may be possible to
    attempt a discard request beyond the device size causing the hang.
    
    Exiting successfully and assign the discarded size (0 in this case)
    to range->len.
    
    Although the start and len values in the user input range are too small,
    a conservative strategy is adopted here to safely ignore them, which is
    equivalent to a no-op; it will not perform any trimming and will not
    throw an error.
    
    [1]
    task:segctord state:D stack:28968 pid:6093 tgid:6093  ppid:2 task_flags:0x200040 flags:0x00080000
    Call Trace:
     rwbase_write_lock+0x3dd/0x750 kernel/locking/rwbase_rt.c:272
     nilfs_transaction_lock+0x253/0x4c0 fs/nilfs2/segment.c:357
     nilfs_segctor_thread_construct fs/nilfs2/segment.c:2569 [inline]
     nilfs_segctor_thread+0x6ec/0xe00 fs/nilfs2/segment.c:2684
    
    [ryusuke: corrected part of the commit message about the consequences]
    
    Fixes: 82e11e857be3 ("nilfs2: add nilfs_sufile_trim_fs to trim clean segs")
    Reported-by: syzbot+7eedce5eb281acd832f0@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=7eedce5eb281acd832f0
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Viacheslav Dubeyko <slava@dubeyko.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52505d7f713bff9b3e2e04a63adcacf1ded62a45
Author: Bibo Mao <maobibo@loongson.cn>
Date:   Tue Jan 13 11:05:55 2026 +0800

    crypto: virtio - Remove duplicated virtqueue_kick in virtio_crypto_skcipher_crypt_req
    
    commit 14f86a1155cca1176abf55987b2fce7f7fcb2455 upstream.
    
    With function virtio_crypto_skcipher_crypt_req(), there is already
    virtqueue_kick() call with spinlock held in function
    __virtio_crypto_skcipher_do_req(). Remove duplicated virtqueue_kick()
    function call here.
    
    Fixes: d79b5d0bbf2e ("crypto: virtio - support crypto engine framework")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bibo Mao <maobibo@loongson.cn>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e69a7b0a71b6561b3b6459f1fded8d589f2e8ac2
Author: Bibo Mao <maobibo@loongson.cn>
Date:   Tue Jan 13 11:05:54 2026 +0800

    crypto: virtio - Add spinlock protection with virtqueue notification
    
    commit b505047ffc8057555900d2d3a005d033e6967382 upstream.
    
    When VM boots with one virtio-crypto PCI device and builtin backend,
    run openssl benchmark command with multiple processes, such as
      openssl speed -evp aes-128-cbc -engine afalg  -seconds 10 -multi 32
    
    openssl processes will hangup and there is error reported like this:
     virtio_crypto virtio0: dataq.0:id 3 is not a head!
    
    It seems that the data virtqueue need protection when it is handled
    for virtio done notification. If the spinlock protection is added
    in virtcrypto_done_task(), openssl benchmark with multiple processes
    works well.
    
    Fixes: fed93fb62e05 ("crypto: virtio - Handle dataq logic with tasklet")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bibo Mao <maobibo@loongson.cn>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ed27b5a1174351148c3adbfc0cd86d54072ba2e
Author: Kees Cook <kees@kernel.org>
Date:   Fri Feb 6 19:49:54 2026 -0800

    crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly
    
    commit 1562b1fb7e17c1b3addb15e125c718b2be7f5512 upstream.
    
    The existing allocation of scatterlists in omap_crypto_copy_sg_lists()
    was allocating an array of scatterlist pointers, not scatterlist objects,
    resulting in a 4x too small allocation.
    
    Use sizeof(*new_sg) to get the correct object size.
    
    Fixes: 74ed87e7e7f7 ("crypto: omap - add base support library for common routines")
    Signed-off-by: Kees Cook <kees@kernel.org>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 62c89e1992c867a3e701a6bd60a168c59a62b159
Author: Thorsten Blum <thorsten.blum@linux.dev>
Date:   Wed Nov 26 10:46:13 2025 +0100

    crypto: octeontx - Fix length check to avoid truncation in ucode_load_store
    
    commit 5565a72b24fa7935a9f30af386e92c8c9dfb23b9 upstream.
    
    OTX_CPT_UCODE_NAME_LENGTH limits the microcode name to 64 bytes. If a
    user writes a string of exactly 64 characters, the original code used
    'strlen(buf) > 64' to check the length, but then strscpy() copies only
    63 characters before adding a NUL terminator, silently truncating the
    copied string.
    
    Fix this off-by-one error by using 'count' directly for the length check
    to ensure long names are rejected early and copied without truncation.
    
    Cc: stable@vger.kernel.org
    Fixes: d9110b0b01ff ("crypto: marvell - add support for OCTEON TX CPT engine")
    Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d75207465eed20bc9b0daa4a0927de9568996067
Author: Thorsten Blum <thorsten.blum@linux.dev>
Date:   Thu Nov 27 15:01:57 2025 +0100

    crypto: iaa - Fix out-of-bounds index in find_empty_iaa_compression_mode
    
    commit 48329301969f6d21b2ef35f678e40f72b59eac94 upstream.
    
    The local variable 'i' is initialized with -EINVAL, but the for loop
    immediately overwrites it and -EINVAL is never returned.
    
    If no empty compression mode can be found, the function would return the
    out-of-bounds index IAA_COMP_MODES_MAX, which would cause an invalid
    array access in add_iaa_compression_mode().
    
    Fix both issues by returning either a valid index or -EINVAL.
    
    Cc: stable@vger.kernel.org
    Fixes: b190447e0fa3 ("crypto: iaa - Add compression mode management along with fixed mode")
    Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
    Acked-by: Kanchana P Sridhar <kanchana.p.sridhar@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 65a0016016e8b115270d97ca44dce635cbd49375
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sat Feb 7 14:13:17 2026 +0100

    ALSA: hda/conexant: Add quirk for HP ZBook Studio G4
    
    commit 1585cf83e98db32463e5d54161b06a5f01fe9976 upstream.
    
    It was reported that we need the same quirk for HP ZBook Studio G4
    (SSID 103c:826b) as other HP models to make the mute-LED working.
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/64d78753-b9ff-4c64-8920-64d8d31cd20c@gmail.com
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=221002
    Link: https://patch.msgid.link/20260207131324.2428030-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be7a9bcee0ca66adb111c37583347e28eb42e506
Author: Zenm Chen <zenmchen@gmail.com>
Date:   Thu Jan 29 10:28:19 2026 +0800

    Bluetooth: btusb: Add USB ID 7392:e611 for Edimax EW-7611UXB
    
    commit 6c0568b7741a346088fd6dfced2d871f7d481d06 upstream.
    
    Add USB ID 7392:e611 for Edimax EW-7611UXB which is RTL8851BU-based
    Wi-Fi + Bluetooth adapter.
    
    The information in /sys/kernel/debug/usb/devices about the Bluetooth
    device is listed as the below:
    
    T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  6 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=7392 ProdID=e611 Rev= 0.00
    S:  Manufacturer=Realtek
    S:  Product=802.11ax WLAN Adapter
    S:  SerialNumber=00e04c000001
    C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
    I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtw89_8851bu_git
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Cc: stable@vger.kernel.org # 6.6.x
    Signed-off-by: Zenm Chen <zenmchen@gmail.com>
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8d76b2488eb3cc0717ab81b60622cff4a5f90f79
Author: Gui-Dong Han <hanguidong02@gmail.com>
Date:   Wed Jan 14 00:28:43 2026 +0800

    driver core: enforce device_lock for driver_match_device()
    
    commit dc23806a7c47ec5f1293aba407fb69519f976ee0 upstream.
    
    Currently, driver_match_device() is called from three sites. One site
    (__device_attach_driver) holds device_lock(dev), but the other two
    (bind_store and __driver_attach) do not. This inconsistency means that
    bus match() callbacks are not guaranteed to be called with the lock
    held.
    
    Fix this by introducing driver_match_device_locked(), which guarantees
    holding the device lock using a scoped guard. Replace the unlocked calls
    in bind_store() and __driver_attach() with this new helper. Also add a
    lock assertion to driver_match_device() to enforce this guarantee.
    
    This consistency also fixes a known race condition. The driver_override
    implementation relies on the device_lock, so the missing lock led to the
    use-after-free (UAF) reported in Bugzilla for buses using this field.
    
    Stress testing the two newly locked paths for 24 hours with
    CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled showed no UAF recurrence
    and no lockdep warnings.
    
    Cc: stable@vger.kernel.org
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
    Suggested-by: Qiu-ji Chen <chenqiuji666@gmail.com>
    Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
    Fixes: 49b420a13ff9 ("driver core: check bus->match without holding device lock")
    Reviewed-by: Danilo Krummrich <dakr@kernel.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
    Link: https://patch.msgid.link/20260113162843.12712-1-hanguidong02@gmail.com
    Signed-off-by: Danilo Krummrich <dakr@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 16c8be3d55441287ddd334e25df4cc376450dec9
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:17:00 2026 +0100

    smb: client: let send_done handle a completion without IB_SEND_SIGNALED
    
    commit cf74fcdc43b322b6188a0750b5ee79e38be6d078 upstream.
    
    With smbdirect_send_batch processing we likely have requests without
    IB_SEND_SIGNALED, which will be destroyed in the final request
    that has IB_SEND_SIGNALED set.
    
    If the connection is broken all requests are signaled
    even without explicit IB_SEND_SIGNALED.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6bf260ace7301a4557a8155f562e13b9e0c808c8
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:59 2026 +0100

    smb: client: let smbd_post_send_negotiate_req() use smbd_post_send()
    
    commit 5b1c6149657af840a02885135c700ab42e6aa322 upstream.
    
    The server has similar logic and it makes sure that
    request->wr is used instead of a stack struct ib_send_wr send_wr.
    
    This makes sure send_done can see request->wr.send_flags
    as the next commit will check for IB_SEND_SIGNALED
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69ce4ae2ab65c01df74355afb5e332ac4223b816
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:58 2026 +0100

    smb: client: fix last send credit problem causing disconnects
    
    commit 93ac432274e1361b4f6cd69e7c5d9b3ac21e13f5 upstream.
    
    When we are about to use the last send credit that was
    granted to us by the peer, we need to wait until
    we are ourself able to grant at least one credit
    to the peer. Otherwise it might not be possible
    for the peer to grant more credits.
    
    The following sections in MS-SMBD are related to this:
    
    3.1.5.1 Sending Upper Layer Messages
    ...
    If Connection.SendCredits is 1 and the CreditsGranted field of the
    message is 0, stop processing.
    ...
    
    3.1.5.9 Managing Credits Prior to Sending
    ...
    If Connection.ReceiveCredits is zero, or if Connection.SendCredits is
    one and the Connection.SendQueue is not empty, the sender MUST allocate
    and post at least one receive of size Connection.MaxReceiveSize and MUST
    increment Connection.ReceiveCredits by the number allocated and posted.
    If no receives are posted, the processing MUST return a value of zero to
    indicate to the caller that no Send message can be currently performed.
    ...
    
    This is a similar logic as we have in the server.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cca0526ef2344cab6944d7f441fc24e152da031b
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:57 2026 +0100

    smb: client: make use of smbdirect_socket.send_io.bcredits
    
    commit 21538121efe6c8c5b51c742fa02cbe820bc48714 upstream.
    
    It turns out that our code will corrupt the stream of
    reassabled data transfer messages when we trigger an
    immendiate (empty) send.
    
    In order to fix this we'll have a single 'batch' credit per
    connection. And code getting that credit is free to use
    as much messages until remaining_length reaches 0, then
    the batch credit it given back and the next logical send can
    happen.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9eff83600edf6957302816d6932389c8d1b6aa76
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:56 2026 +0100

    smb: client: use smbdirect_send_batch processing
    
    commit 2c1ac39ce9cd4112f406775c626eef7f3eb4c481 upstream.
    
    This will allow us to use similar logic as we have in
    the server soon, so that we can share common code later.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d059e5fc4975598bd827ba2447db60141112bed7
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:55 2026 +0100

    smb: client: introduce and use smbd_{alloc, free}_send_io()
    
    commit dc77da0373529d43175984b390106be2d8f03609 upstream.
    
    This is basically a copy of smb_direct_{alloc,free}_sendmsg()
    in the server, with just using ib_dma_unmap_page() in all
    cases, which is the same as ib_dma_unmap_single().
    
    We'll use this logic in common code in future.
    (I basically backported it from my branch that
    as already has everything in common).
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f3e8e2c67cbc1cea7621e74f3290b1731269de6
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:54 2026 +0100

    smb: client: split out smbd_ib_post_send()
    
    commit bf30515caec590316e0d08208e4252eed4c160df upstream.
    
    This is like smb_direct_post_send() in the server
    and will simplify porting the smbdirect_send_batch
    and credit related logic from the server.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8786127068d511de683e57a4f3cfc95a0b75b19c
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:53 2026 +0100

    smb: client: port and use the wait_for_credits logic used by server
    
    commit bb848d205f7ac0141af52a5acb6dd116d9b71177 upstream.
    
    This simplifies the logic and prepares the use of
    smbdirect_send_batch in order to make sure
    all messages in a multi fragment send are grouped
    together.
    
    We'll add the smbdirect_send_batch processin
    in a later patch.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fe0f989beb8b73b51721dc28aaf40e02f8bba55
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:52 2026 +0100

    smb: client: remove pointless sc->send_io.pending handling in smbd_post_send_iter()
    
    commit 8bfe3fd33f36b987c8200b112646732b5f5cd8b3 upstream.
    
    If we reach this the connection is already broken as
    smbd_post_send() already called
    smbd_disconnect_rdma_connection().
    
    This will also simplify further changes.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b08ca3ab6cc510baec1d30594ec7051b8a43c17
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:51 2026 +0100

    smb: client: remove pointless sc->recv_io.credits.count rollback
    
    commit 6858531e5e8d68828eec349989cefce3f45a487f upstream.
    
    We either reach this code path before we call
    new_credits = manage_credits_prior_sending(sc),
    which means new_credits is still 0
    or the connection is already broken as
    smbd_post_send() already called
    smbd_disconnect_rdma_connection().
    
    This will also simplify further changes.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9ec75aba3c8f5177b651bd0b171c51ba01e260b
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:50 2026 +0100

    smb: client: let smbd_post_send() make use of request->wr
    
    commit bf1656e12a9db2add716c7fb57b56967f69599fa upstream.
    
    We don't need a stack variable in addition.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5b69ba9978dd084d8c9f397a8ecc7522d387b68e
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:49 2026 +0100

    smb: client: let recv_done() queue a refill when the peer is low on credits
    
    commit defb3c05fee94b296eebe05aaea16d2664b00252 upstream.
    
    In captures I saw that Windows was granting 191 credits in a batch
    when its peer posted a lot of messages. We are asking for a
    credit target of 255 and 191 is 252*3/4.
    
    So we also use that logic in order to fill the
    recv buffers available to the peer.
    
    Fixes: 02548c477a90 ("smb: client: queue post_recv_credits_work also if the peer raises the credit target")
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f664e6e8a81103cb45c8802a9bc7499e0902c458
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:48 2026 +0100

    smb: client: make use of smbdirect_socket.recv_io.credits.available
    
    commit 9911b1ed187a770a43950bf51f340ad4b7beecba upstream.
    
    The logic off managing recv credits by counting posted recv_io and
    granted credits is racy.
    
    That's because the peer might already consumed a credit,
    but between receiving the incoming recv at the hardware
    and processing the completion in the 'recv_done' functions
    we likely have a window where we grant credits, which
    don't really exist.
    
    So we better have a decicated counter for the
    available credits, which will be incremented
    when we posted new recv buffers and drained when
    we grant the credits to the peer.
    
    Fixes: 5fb9b459b368 ("smb: client: count the number of posted recv_io messages in order to calculated credits")
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 24082642654f3e5149913946e89c00a297a8868f
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:47 2026 +0100

    smb: server: let send_done handle a completion without IB_SEND_SIGNALED
    
    commit 9da82dc73cb03e85d716a2609364572367a5ff47 upstream.
    
    With smbdirect_send_batch processing we likely have requests without
    IB_SEND_SIGNALED, which will be destroyed in the final request
    that has IB_SEND_SIGNALED set.
    
    If the connection is broken all requests are signaled
    even without explicit IB_SEND_SIGNALED.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 85bf0a73831ccca4960f3f315e9c68c72b292342
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:46 2026 +0100

    smb: server: fix last send credit problem causing disconnects
    
    commit 8cf2bbac6281434065f5f3aeab19c9c08ff755a2 upstream.
    
    When we are about to use the last send credit that was
    granted to us by the peer, we need to wait until
    we are ourself able to grant at least one credit
    to the peer. Otherwise it might not be possible
    for the peer to grant more credits.
    
    The following sections in MS-SMBD are related to this:
    
    3.1.5.1 Sending Upper Layer Messages
    ...
    If Connection.SendCredits is 1 and the CreditsGranted field of the
    message is 0, stop processing.
    ...
    
    3.1.5.9 Managing Credits Prior to Sending
    ...
    If Connection.ReceiveCredits is zero, or if Connection.SendCredits is
    one and the Connection.SendQueue is not empty, the sender MUST allocate
    and post at least one receive of size Connection.MaxReceiveSize and MUST
    increment Connection.ReceiveCredits by the number allocated and posted.
    If no receives are posted, the processing MUST return a value of zero to
    indicate to the caller that no Send message can be currently performed.
    ...
    
    This problem was found by running this on Windows 2025
    against ksmbd with required smb signing:
    'frametest.exe -r 4k -t 20 -n 2000' after
    'frametest.exe -w 4k -t 20 -n 2000'.
    
    Link: https://lore.kernel.org/linux-cifs/b58fa352-2386-4145-b42e-9b4b1d484e17@samba.org/
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5ef18a2e66f2f33fdac64437bddfb9fe6389fdc7
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:45 2026 +0100

    smb: server: make use of smbdirect_socket.send_io.bcredits
    
    commit 34abd408c8ba24d7c97bd02ba874d8c714f49db1 upstream.
    
    It turns out that our code will corrupt the stream of
    reassabled data transfer messages when we trigger an
    immendiate (empty) send.
    
    In order to fix this we'll have a single 'batch' credit per
    connection. And code getting that credit is free to use
    as much messages until remaining_length reaches 0, then
    the batch credit it given back and the next logical send can
    happen.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cea7afb097b00fe1fb610b7d5f0538a4a1e5b1c0
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:44 2026 +0100

    smb: server: let recv_done() queue a refill when the peer is low on credits
    
    commit 8106978d400cc88a99fb94927afe8fec7391ca3e upstream.
    
    In captures I saw that Windows was granting 191 credits in a batch
    when its peer posted a lot of messages. We are asking for a
    credit target of 255 and 191 is 252*3/4.
    
    So we also use that logic in order to fill the
    recv buffers available to the peer.
    
    Fixes: a7eef6144c97 ("smb: server: queue post_recv_credits_work in put_recvmsg() and avoid count_avail_recvmsg")
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 66c082e3d4651e8629a393a9e182b01eb50fb0a3
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:43 2026 +0100

    smb: server: make use of smbdirect_socket.recv_io.credits.available
    
    commit 26ad87a2cfb8c1384620d1693a166ed87303046e upstream.
    
    The logic off managing recv credits by counting posted recv_io and
    granted credits is racy.
    
    That's because the peer might already consumed a credit,
    but between receiving the incoming recv at the hardware
    and processing the completion in the 'recv_done' functions
    we likely have a window where we grant credits, which
    don't really exist.
    
    So we better have a decicated counter for the
    available credits, which will be incremented
    when we posted new recv buffers and drained when
    we grant the credits to the peer.
    
    This fixes regression Namjae reported with
    the 6.18 release.
    
    Fixes: 89b021a72663 ("smb: server: manage recv credits by counting posted recv_io and granted credits")
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88cf40f7b5fb45463d444f76028b7250f129b15e
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:42 2026 +0100

    smb: smbdirect: introduce smbdirect_socket.send_io.bcredits.*
    
    commit 8e94268b21c8235d430ce1aa6dc0b15952744b9b upstream.
    
    It turns out that our code will corrupt the stream of
    reassabled data transfer messages when we trigger an
    immendiate (empty) send.
    
    In order to fix this we'll have a single 'batch' credit per
    connection. And code getting that credit is free to use
    as much messages until remaining_length reaches 0, then
    the batch credit it given back and the next logical send can
    happen.
    
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e811e60e1cc79923c4388146eb1fa26a7482731e
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Jan 22 18:16:41 2026 +0100

    smb: smbdirect: introduce smbdirect_socket.recv_io.credits.available
    
    commit 6e3c5052f9686192e178806e017b7377155f4bab upstream.
    
    The logic off managing recv credits by counting posted recv_io and
    granted credits is racy.
    
    That's because the peer might already consumed a credit,
    but between receiving the incoming recv at the hardware
    and processing the completion in the 'recv_done' functions
    we likely have a window where we grant credits, which
    don't really exist.
    
    So we better have a decicated counter for the
    available credits, which will be incremented
    when we posted new recv buffers and drained when
    we grant the credits to the peer.
    
    Fixes: 5fb9b459b368 ("smb: client: count the number of posted recv_io messages in order to calculated credits")
    Fixes: 89b021a72663 ("smb: server: manage recv credits by counting posted recv_io and granted credits")
    Cc: <stable@vger.kernel.org> # 6.18.x
    Cc: Steve French <smfrench@gmail.com>
    Cc: Tom Talpey <tom@talpey.com>
    Cc: Long Li <longli@microsoft.com>
    Cc: Namjae Jeon <linkinjeon@kernel.org>
    Cc: linux-cifs@vger.kernel.org
    Cc: samba-technical@lists.samba.org
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cd25e0d809531a67e9dd53b19012d27d2b13425f
Author: Henrique Carvalho <henrique.carvalho@suse.com>
Date:   Wed Feb 4 20:06:43 2026 -0300

    smb: server: fix leak of active_num_conn in ksmbd_tcp_new_connection()
    
    commit 77ffbcac4e569566d0092d5f22627dfc0896b553 upstream.
    
    On kthread_run() failure in ksmbd_tcp_new_connection(), the transport is
    freed via free_transport(), which does not decrement active_num_conn,
    leaking this counter.
    
    Replace free_transport() with ksmbd_tcp_disconnect().
    
    Fixes: 0d0d4680db22e ("ksmbd: add max connections parameter")
    Cc: stable@vger.kernel.org
    Signed-off-by: Henrique Carvalho <henrique.carvalho@suse.com>
    Acked-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4a8a96a93d08570e0405cfd989a8a07e5b6ff33
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Mon Feb 9 10:43:19 2026 +0900

    ksmbd: add chann_lock to protect ksmbd_chann_list xarray
    
    commit 4f3a06cc57976cafa8c6f716646be6c79a99e485 upstream.
    
    ksmbd_chann_list xarray lacks synchronization, allowing use-after-free in
    multi-channel sessions (between lookup_chann_list() and ksmbd_chann_del).
    
    Adds rw_semaphore chann_lock to struct ksmbd_session and protects
    all xa_load/xa_store/xa_erase accesses.
    
    Cc: stable@vger.kernel.org
    Reported-by: Igor Stepansky <igor.stepansky@orca.security>
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71b5e7c528315ca360a1825a4ad2f8ae48c5dc16
Author: Namjae Jeon <linkinjeon@kernel.org>
Date:   Sat Jan 24 10:55:46 2026 +0900

    ksmbd: fix infinite loop caused by next_smb2_rcv_hdr_off reset in error paths
    
    commit 010eb01ce23b34b50531448b0da391c7f05a72af upstream.
    
    The problem occurs when a signed request fails smb2 signature verification
    check. In __process_request(), if check_sign_req() returns an error,
    set_smb2_rsp_status(work, STATUS_ACCESS_DENIED) is called.
    set_smb2_rsp_status() set work->next_smb2_rcv_hdr_off as zero. By resetting
    next_smb2_rcv_hdr_off to zero, the pointer to the next command in the chain
    is lost. Consequently, is_chained_smb2_message() continues to point to
    the same request header instead of advancing. If the header's NextCommand
    field is non-zero, the function returns true, causing __handle_ksmbd_work()
    to repeatedly process the same failed request in an infinite loop.
    This results in the kernel log being flooded with "bad smb2 signature"
    messages and high CPU usage.
    
    This patch fixes the issue by changing the return value from
    SERVER_HANDLER_CONTINUE to SERVER_HANDLER_ABORT. This ensures that
    the processing loop terminates immediately rather than attempting to
    continue from an invalidated offset.
    
    Reported-by: tianshuo han <hantianshuo233@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4b9edd55987384a1f201d3d07ff71e448d79c1b
Author: Henrique Carvalho <henrique.carvalho@suse.com>
Date:   Tue Jan 27 13:01:28 2026 -0300

    smb: client: split cached_fid bitfields to avoid shared-byte RMW races
    
    commit ec306600d5ba7148c9dbf8f5a8f1f5c1a044a241 upstream.
    
    is_open, has_lease and on_list are stored in the same bitfield byte in
    struct cached_fid but are updated in different code paths that may run
    concurrently. Bitfield assignments generate byte read–modify–write
    operations (e.g. `orb $mask, addr` on x86_64), so updating one flag can
    restore stale values of the others.
    
    A possible interleaving is:
        CPU1: load old byte (has_lease=1, on_list=1)
        CPU2: clear both flags (store 0)
        CPU1: RMW store (old | IS_OPEN) -> reintroduces cleared bits
    
    To avoid this class of races, convert these flags to separate bool
    fields.
    
    Cc: stable@vger.kernel.org
    Fixes: ebe98f1447bbc ("cifs: enable caching of directories for which a lease is held")
    Signed-off-by: Henrique Carvalho <henrique.carvalho@suse.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1658b66fed206b5417cc301d67e888fd67dd130a
Author: Li Chen <me@linux.beauty>
Date:   Mon Feb 2 22:37:54 2026 +0800

    io_uring: allow io-wq workers to exit when unused
    
    commit 91214661489467f8452d34edbf257488d85176e4 upstream.
    
    io_uring keeps a per-task io-wq around, even when the task no longer has
    any io_uring instances.
    
    If the task previously used io_uring for file I/O, this can leave an
    unrelated iou-wrk-* worker thread behind after the last io_uring
    instance is gone.
    
    When the last io_uring ctx is removed from the task context, mark the
    io-wq exit-on-idle so workers can go away. Clear the flag on subsequent
    io_uring usage.
    
    Signed-off-by: Li Chen <me@linux.beauty>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f02693a40e40702cb6201145379e21634dfbe20d
Author: Li Chen <me@linux.beauty>
Date:   Mon Feb 2 22:37:53 2026 +0800

    io_uring/io-wq: add exit-on-idle state
    
    commit 38aa434ab9335ce2d178b7538cdf01d60b2014c3 upstream.
    
    io-wq uses an idle timeout to shrink the pool, but keeps the last worker
    around indefinitely to avoid churn.
    
    For tasks that used io_uring for file I/O and then stop using io_uring,
    this can leave an iou-wrk-* thread behind even after all io_uring
    instances are gone. This is unnecessary overhead and also gets in the
    way of process checkpoint/restore.
    
    Add an exit-on-idle state that makes all io-wq workers exit as soon as
    they become idle, and provide io_wq_set_exit_on_idle() to toggle it.
    
    Signed-off-by: Li Chen <me@linux.beauty>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>