Changelog in Linux kernel 5.15.187

 
ACPICA: Refuse to evaluate a method if arguments are missing [+ + +]
Author: Rafael J. Wysocki <[email protected]>
Date:   Wed Jun 18 14:17:45 2025 +0200

    ACPICA: Refuse to evaluate a method if arguments are missing
    
    [ Upstream commit 6fcab2791543924d438e7fa49276d0998b0a069f ]
    
    As reported in [1], a platform firmware update that increased the number
    of method parameters and forgot to update a least one of its callers,
    caused ACPICA to crash due to use-after-free.
    
    Since this a result of a clear AML issue that arguably cannot be fixed
    up by the interpreter (it cannot produce missing data out of thin air),
    address it by making ACPICA refuse to evaluate a method if the caller
    attempts to pass fewer arguments than expected to it.
    
    Closes: https://github.com/acpica/acpica/issues/1027 [1]
    Reported-by: Peter Williams <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Reviewed-by: Hans de Goede <[email protected]>
    Tested-by: Hans de Goede <[email protected]> # Dell XPS 9640 with BIOS 1.12.0
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
af_unix: Don't set -ECONNRESET for consumed OOB skb. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Wed Jun 18 21:13:57 2025 -0700

    af_unix: Don't set -ECONNRESET for consumed OOB skb.
    
    [ Upstream commit 2a5a4841846b079b5fca5752fe94e59346fbda40 ]
    
    Christian Brauner reported that even after MSG_OOB data is consumed,
    calling close() on the receiver socket causes the peer's recv() to
    return -ECONNRESET:
    
      1. send() and recv() an OOB data.
    
        >>> from socket import *
        >>> s1, s2 = socketpair(AF_UNIX, SOCK_STREAM)
        >>> s1.send(b'x', MSG_OOB)
        1
        >>> s2.recv(1, MSG_OOB)
        b'x'
    
      2. close() for s2 sets ECONNRESET to s1->sk_err even though
         s2 consumed the OOB data
    
        >>> s2.close()
        >>> s1.recv(10, MSG_DONTWAIT)
        ...
        ConnectionResetError: [Errno 104] Connection reset by peer
    
    Even after being consumed, the skb holding the OOB 1-byte data stays in
    the recv queue to mark the OOB boundary and break recv() at that point.
    
    This must be considered while close()ing a socket.
    
    Let's skip the leading consumed OOB skb while checking the -ECONNRESET
    condition in unix_release_sock().
    
    Fixes: 314001f0bf92 ("af_unix: Add OOB support")
    Reported-by: Christian Brauner <[email protected]>
    Closes: https://lore.kernel.org/netdev/20250529-sinkt-abfeuern-e7b08200c6b0@brauner/
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Acked-by: Christian Brauner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ALSA: hda: Add new pci id for AMD GPU display HD audio controller [+ + +]
Author: Vijendar Mukunda <[email protected]>
Date:   Thu May 29 11:08:13 2025 +0530

    ALSA: hda: Add new pci id for AMD GPU display HD audio controller
    
    [ Upstream commit ab72bfce7647522e01a181e3600c3d14ff5c143e ]
    
    Add new pci id for AMD GPU display HD audio controller(device id- 0xab40).
    
    Signed-off-by: Vijendar Mukunda <[email protected]>
    Reviewed-by: Alex Deucher <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: hda: Ignore unsol events for cards being shut down [+ + +]
Author: Cezary Rojewski <[email protected]>
Date:   Fri May 30 16:13:09 2025 +0200

    ALSA: hda: Ignore unsol events for cards being shut down
    
    [ Upstream commit 3f100f524e75586537e337b34d18c8d604b398e7 ]
    
    For the classic snd_hda_intel driver, codec->card and bus->card point to
    the exact same thing. When snd_card_diconnect() fires, bus->shutdown is
    set thanks to azx_dev_disconnect(). card->shutdown is already set when
    that happens but both provide basically the same functionality.
    
    For the DSP snd_soc_avs driver where multiple codecs are located on
    multiple cards, bus->shutdown 'shortcut' is not sufficient. One codec
    card may be unregistered while other codecs are still operational.
    Proper check in form of card->shutdown must be used to verify whether
    the codec's card is being shut down.
    
    Reviewed-by: Amadeusz Sławiński <[email protected]>
    Signed-off-by: Cezary Rojewski <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: sb: Don't allow changing the DMA mode during operations [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Tue Jun 10 08:43:19 2025 +0200

    ALSA: sb: Don't allow changing the DMA mode during operations
    
    [ Upstream commit ed29e073ba93f2d52832804cabdd831d5d357d33 ]
    
    When a PCM stream is already running, one shouldn't change the DMA
    mode via kcontrol, which may screw up the hardware.  Return -EBUSY
    instead.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=218185
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: sb: Force to disable DMAs once when DMA mode is changed [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Tue Jun 10 08:43:20 2025 +0200

    ALSA: sb: Force to disable DMAs once when DMA mode is changed
    
    [ Upstream commit 4c267ae2ef349639b4d9ebf00dd28586a82fdbe6 ]
    
    When the DMA mode is changed on the (still real!) SB AWE32 after
    playing a stream and closing, the previous DMA setup was still
    silently kept, and it can confuse the hardware, resulting in the
    unexpected noises.  As a workaround, enforce the disablement of DMA
    setups when the DMA setup is changed by the kcontrol.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=218185
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Add a quirk for Lenovo Thinkpad Thunderbolt 3 dock [+ + +]
Author: Mario Limonciello <[email protected]>
Date:   Tue May 27 12:26:56 2025 -0500

    ALSA: usb-audio: Add a quirk for Lenovo Thinkpad Thunderbolt 3 dock
    
    [ Upstream commit 4919353c7789b8047e06a9b2b943f775a8f72883 ]
    
    The audio controller in the Lenovo Thinkpad Thunderbolt 3 dock doesn't
    support reading the sampling rate.
    
    Add a quirk for it.
    
    Suggested-by: Takashi Iwai <[email protected]>
    Signed-off-by: Mario Limonciello <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3() [+ + +]
Author: Youngjun Lee <[email protected]>
Date:   Mon Jun 23 20:05:25 2025 +0900

    ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()
    
    [ Upstream commit fb4e2a6e8f28a3c0ad382e363aeb9cd822007b8a ]
    
    In snd_usb_get_audioformat_uac3(), the length value returned from
    snd_usb_ctl_msg() is used directly for memory allocation without
    validation. This length is controlled by the USB device.
    
    The allocated buffer is cast to a uac3_cluster_header_descriptor
    and its fields are accessed without verifying that the buffer
    is large enough. If the device returns a smaller than expected
    length, this leads to an out-of-bounds read.
    
    Add a length check to ensure the buffer is large enough for
    uac3_cluster_header_descriptor.
    
    Signed-off-by: Youngjun Lee <[email protected]>
    Fixes: 9a2fe9b801f5 ("ALSA: usb: initial USB Audio Device Class 3.0 support")
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
amd-xgbe: align CL37 AN sequence as per databook [+ + +]
Author: Raju Rangoju <[email protected]>
Date:   Tue Jul 1 00:56:36 2025 +0530

    amd-xgbe: align CL37 AN sequence as per databook
    
    [ Upstream commit 42fd432fe6d320323215ebdf4de4d0d7e56e6792 ]
    
    Update the Clause 37 Auto-Negotiation implementation to properly align
    with the PCS hardware specifications:
    - Fix incorrect bit settings in Link Status and Link Duplex fields
    - Implement missing sequence steps 2 and 7
    
    These changes ensure CL37 auto-negotiation protocol follows the exact
    sequence patterns as specified in the hardware databook.
    
    Fixes: 1bf40ada6290 ("amd-xgbe: Add support for clause 37 auto-negotiation")
    Signed-off-by: Raju Rangoju <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64: Restrict pagetable teardown to avoid false warning [+ + +]
Author: Dev Jain <[email protected]>
Date:   Tue May 27 13:56:33 2025 +0530

    arm64: Restrict pagetable teardown to avoid false warning
    
    commit 650768c512faba8070bf4cfbb28c95eb5cd203f3 upstream.
    
    Commit 9c006972c3fe ("arm64: mmu: drop pXd_present() checks from
    pXd_free_pYd_table()") removes the pxd_present() checks because the
    caller checks pxd_present(). But, in case of vmap_try_huge_pud(), the
    caller only checks pud_present(); pud_free_pmd_page() recurses on each
    pmd through pmd_free_pte_page(), wherein the pmd may be none. Thus it is
    possible to hit a warning in the latter, since pmd_none => !pmd_table().
    Thus, add a pmd_present() check in pud_free_pmd_page().
    
    This problem was found by code inspection.
    
    Fixes: 9c006972c3fe ("arm64: mmu: drop pXd_present() checks from pXd_free_pYd_table()")
    Cc: [email protected]
    Reported-by: Ryan Roberts <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Signed-off-by: Dev Jain <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    Reviewed-by: Anshuman Khandual <[email protected]>
    Reviewed-by: Ryan Roberts <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ARM: 9354/1: ptrace: Use bitfield helpers [+ + +]
Author: Geert Uytterhoeven <[email protected]>
Date:   Mon Feb 26 12:25:01 2024 +0100

    ARM: 9354/1: ptrace: Use bitfield helpers
    
    commit b36e78b216e632d90138751e4ff80044de303656 upstream.
    
    The isa_mode() macro extracts two fields, and recombines them into a
    single value.
    
    Make this more obvious by using the FIELD_GET() helper, and shifting the
    result into its final resting place.
    
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Reviewed-by: Oleg Nesterov <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ata: pata_cs5536: fix build on 32-bit UML [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Fri Jun 6 11:01:11 2025 +0200

    ata: pata_cs5536: fix build on 32-bit UML
    
    [ Upstream commit fe5b391fc56f77cf3c22a9dd4f0ce20db0e3533f ]
    
    On 32-bit ARCH=um, CONFIG_X86_32 is still defined, so it
    doesn't indicate building on real X86 machines. There's
    no MSR on UML though, so add a check for CONFIG_X86.
    
    Reported-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Johannes Berg <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Niklas Cassel <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
atm: clip: prevent NULL deref in clip_push() [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Jun 20 14:28:44 2025 +0000

    atm: clip: prevent NULL deref in clip_push()
    
    [ Upstream commit b993ea46b3b601915ceaaf3c802adf11e7d6bac6 ]
    
    Blamed commit missed that vcc_destroy_socket() calls
    clip_push() with a NULL skb.
    
    If clip_devs is NULL, clip_push() then crashes when reading
    skb->truesize.
    
    Fixes: 93a2014afbac ("atm: fix a UAF in lec_arp_clear_vccs()")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/T/#u
    Signed-off-by: Eric Dumazet <[email protected]>
    Cc: Cong Wang <[email protected]>
    Cc: Gengming Liu <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister(). [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Tue Jun 24 14:45:00 2025 -0700

    atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().
    
    [ Upstream commit a433791aeaea6e84df709e0b9584b9bbe040cd1c ]
    
    syzbot reported a warning below during atm_dev_register(). [0]
    
    Before creating a new device and procfs/sysfs for it, atm_dev_register()
    looks up a duplicated device by __atm_dev_lookup().  These operations are
    done under atm_dev_mutex.
    
    However, when removing a device in atm_dev_deregister(), it releases the
    mutex just after removing the device from the list that __atm_dev_lookup()
    iterates over.
    
    So, there will be a small race window where the device does not exist on
    the device list but procfs/sysfs are still not removed, triggering the
    splat.
    
    Let's hold the mutex until procfs/sysfs are removed in
    atm_dev_deregister().
    
    [0]:
    proc_dir_entry 'atm/atmtcp:0' already registered
    WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377
    Modules linked in:
    CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
    RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377
    Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48
    RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248
    RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001
    RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140
    R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444
    FS:  00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     proc_create_data+0xbe/0x110 fs/proc/generic.c:585
     atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361
     atm_dev_register+0x46d/0x890 net/atm/resources.c:113
     atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369
     atmtcp_attach drivers/atm/atmtcp.c:403 [inline]
     atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464
     do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
     sock_do_ioctl+0x115/0x280 net/socket.c:1190
     sock_ioctl+0x227/0x6b0 net/socket.c:1311
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:907 [inline]
     __se_sys_ioctl fs/ioctl.c:893 [inline]
     __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f38b3b74459
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459
    RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005
    RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f
    R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac
    R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b
     </TASK>
    
    Fixes: 64bf69ddff76 ("[ATM]: deregistration removes device from atm_devs list immediately")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Tested-by: [email protected]
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
attach_recursive_mnt(): do not lock the covering tree when sliding something under it [+ + +]
Author: Al Viro <[email protected]>
Date:   Sun Jun 22 18:03:29 2025 -0400

    attach_recursive_mnt(): do not lock the covering tree when sliding something under it
    
    [ Upstream commit ce7df19686530920f2f6b636e71ce5eb1d9303ef ]
    
    If we are propagating across the userns boundary, we need to lock the
    mounts added there.  However, in case when something has already
    been mounted there and we end up sliding a new tree under that,
    the stuff that had been there before should not get locked.
    
    IOW, lock_mnt_tree() should be called before we reparent the
    preexisting tree on top of what we are adding.
    
    Fixes: 3bd045cc9c4b ("separate copying and locking mount tree on cross-userns copies")
    Signed-off-by: Al Viro <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bcache: fix NULL pointer in cache_set_flush() [+ + +]
Author: Linggang Zeng <[email protected]>
Date:   Tue May 27 13:15:59 2025 +0800

    bcache: fix NULL pointer in cache_set_flush()
    
    [ Upstream commit 1e46ed947ec658f89f1a910d880cd05e42d3763e ]
    
    1. LINE#1794 - LINE#1887 is some codes about function of
       bch_cache_set_alloc().
    2. LINE#2078 - LINE#2142 is some codes about function of
       register_cache_set().
    3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098.
    
     1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
     1795 {
     ...
     1860         if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) ||
     1861             mempool_init_slab_pool(&c->search, 32, bch_search_cache) ||
     1862             mempool_init_kmalloc_pool(&c->bio_meta, 2,
     1863                                 sizeof(struct bbio) + sizeof(struct bio_vec) *
     1864                                 bucket_pages(c)) ||
     1865             mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) ||
     1866             bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio),
     1867                         BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) ||
     1868             !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) ||
     1869             !(c->moving_gc_wq = alloc_workqueue("bcache_gc",
     1870                                                 WQ_MEM_RECLAIM, 0)) ||
     1871             bch_journal_alloc(c) ||
     1872             bch_btree_cache_alloc(c) ||
     1873             bch_open_buckets_alloc(c) ||
     1874             bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages)))
     1875                 goto err;
                          ^^^^^^^^
     1876
     ...
     1883         return c;
     1884 err:
     1885         bch_cache_set_unregister(c);
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
     1886         return NULL;
     1887 }
     ...
     2078 static const char *register_cache_set(struct cache *ca)
     2079 {
     ...
     2098         c = bch_cache_set_alloc(&ca->sb);
     2099         if (!c)
     2100                 return err;
                          ^^^^^^^^^^
     ...
     2128         ca->set = c;
     2129         ca->set->cache[ca->sb.nr_this_dev] = ca;
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     ...
     2138         return NULL;
     2139 err:
     2140         bch_cache_set_unregister(c);
     2141         return err;
     2142 }
    
    (1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and
        call bch_cache_set_unregister()(LINE#1885).
    (2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.
    (3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the
        value to c->cache[], it means that c->cache[] is NULL.
    
    LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().
    As (1), in LINE#1885 call
    bch_cache_set_unregister()
    ---> bch_cache_set_stop()
         ---> closure_queue()
              -.-> cache_set_flush() (as below LINE#1624)
    
     1624 static void cache_set_flush(struct closure *cl)
     1625 {
     ...
     1654         for_each_cache(ca, c, i)
     1655                 if (ca->alloc_thread)
                              ^^
     1656                         kthread_stop(ca->alloc_thread);
     ...
     1665 }
    
    (4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the
        kernel crash occurred as below:
    [  846.712887] bcache: register_cache() error drbd6: cannot allocate memory
    [  846.713242] bcache: register_bcache() error : failed to register device
    [  846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered
    [  846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8
    [  846.714790] PGD 0 P4D 0
    [  846.715129] Oops: 0000 [#1] SMP PTI
    [  846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1
    [  846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018
    [  846.716451] Workqueue: events cache_set_flush [bcache]
    [  846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache]
    [  846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 00 48 85 ff 74 05 e8 b6 58 a2 e1 0f b7 95 3c f7
    [  846.718026] RSP: 0018:ffffb56dcf85fe70 EFLAGS: 00010202
    [  846.718372] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    [  846.718725] RDX: 0000000000000001 RSI: 0000000040000001 RDI: 0000000000000000
    [  846.719076] RBP: ffffa0ccc0f20df8 R08: ffffa0ce1fedb118 R09: 000073746e657665
    [  846.719428] R10: 8080808080808080 R11: 0000000000000000 R12: ffffa0ce1fee8700
    [  846.719779] R13: ffffa0ccc0f211a8 R14: ffffa0cd1b902840 R15: ffffa0ccc0f20e00
    [  846.720132] FS:  0000000000000000(0000) GS:ffffa0ce1fec0000(0000) knlGS:0000000000000000
    [  846.720726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  846.721073] CR2: 00000000000009f8 CR3: 00000008ba00a005 CR4: 00000000007606e0
    [  846.721426] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  846.721778] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  846.722131] PKRU: 55555554
    [  846.722467] Call Trace:
    [  846.722814]  process_one_work+0x1a7/0x3b0
    [  846.723157]  worker_thread+0x30/0x390
    [  846.723501]  ? create_worker+0x1a0/0x1a0
    [  846.723844]  kthread+0x112/0x130
    [  846.724184]  ? kthread_flush_work_fn+0x10/0x10
    [  846.724535]  ret_from_fork+0x35/0x40
    
    Now, check whether that ca is NULL in LINE#1655 to fix the issue.
    
    Signed-off-by: Linggang Zeng <[email protected]>
    Signed-off-by: Mingzhe Zou <[email protected]>
    Signed-off-by: Coly Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Bluetooth: L2CAP: Fix L2CAP MTU negotiation [+ + +]
Author: Frédéric Danis <[email protected]>
Date:   Thu Jun 12 09:50:34 2025 +0200

    Bluetooth: L2CAP: Fix L2CAP MTU negotiation
    
    commit 042bb9603c44620dce98717a2d23235ca57a00d7 upstream.
    
    OBEX download from iPhone is currently slow due to small packet size
    used to transfer data which doesn't follow the MTU negotiated during
    L2CAP connection, i.e. 672 bytes instead of 32767:
    
      < ACL Data TX: Handle 11 flags 0x00 dlen 12
          L2CAP: Connection Request (0x02) ident 18 len 4
            PSM: 4103 (0x1007)
            Source CID: 72
      > ACL Data RX: Handle 11 flags 0x02 dlen 16
          L2CAP: Connection Response (0x03) ident 18 len 8
            Destination CID: 14608
            Source CID: 72
            Result: Connection successful (0x0000)
            Status: No further information available (0x0000)
      < ACL Data TX: Handle 11 flags 0x00 dlen 27
          L2CAP: Configure Request (0x04) ident 20 len 19
            Destination CID: 14608
            Flags: 0x0000
            Option: Maximum Transmission Unit (0x01) [mandatory]
              MTU: 32767
            Option: Retransmission and Flow Control (0x04) [mandatory]
              Mode: Enhanced Retransmission (0x03)
              TX window size: 63
              Max transmit: 3
              Retransmission timeout: 2000
              Monitor timeout: 12000
              Maximum PDU size: 1009
      > ACL Data RX: Handle 11 flags 0x02 dlen 26
          L2CAP: Configure Request (0x04) ident 72 len 18
            Destination CID: 72
            Flags: 0x0000
            Option: Retransmission and Flow Control (0x04) [mandatory]
              Mode: Enhanced Retransmission (0x03)
              TX window size: 32
              Max transmit: 255
              Retransmission timeout: 0
              Monitor timeout: 0
              Maximum PDU size: 65527
            Option: Frame Check Sequence (0x05) [mandatory]
              FCS: 16-bit FCS (0x01)
      < ACL Data TX: Handle 11 flags 0x00 dlen 29
          L2CAP: Configure Response (0x05) ident 72 len 21
            Source CID: 14608
            Flags: 0x0000
            Result: Success (0x0000)
            Option: Maximum Transmission Unit (0x01) [mandatory]
              MTU: 672
            Option: Retransmission and Flow Control (0x04) [mandatory]
              Mode: Enhanced Retransmission (0x03)
              TX window size: 32
              Max transmit: 255
              Retransmission timeout: 2000
              Monitor timeout: 12000
              Maximum PDU size: 1009
      > ACL Data RX: Handle 11 flags 0x02 dlen 32
          L2CAP: Configure Response (0x05) ident 20 len 24
            Source CID: 72
            Flags: 0x0000
            Result: Success (0x0000)
            Option: Maximum Transmission Unit (0x01) [mandatory]
              MTU: 32767
            Option: Retransmission and Flow Control (0x04) [mandatory]
              Mode: Enhanced Retransmission (0x03)
              TX window size: 63
              Max transmit: 3
              Retransmission timeout: 2000
              Monitor timeout: 12000
              Maximum PDU size: 1009
            Option: Frame Check Sequence (0x05) [mandatory]
              FCS: 16-bit FCS (0x01)
      ...
      > ACL Data RX: Handle 11 flags 0x02 dlen 680
          Channel: 72 len 676 ctrl 0x0202 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8}
          I-frame: Unsegmented TxSeq 1 ReqSeq 2
      < ACL Data TX: Handle 11 flags 0x00 dlen 13
          Channel: 14608 len 9 ctrl 0x0204 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8}
          I-frame: Unsegmented TxSeq 2 ReqSeq 2
      > ACL Data RX: Handle 11 flags 0x02 dlen 680
          Channel: 72 len 676 ctrl 0x0304 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8}
          I-frame: Unsegmented TxSeq 2 ReqSeq 3
    
    The MTUs are negotiated for each direction. In this traces 32767 for
    iPhone->localhost and no MTU for localhost->iPhone, which based on
    '4.4 L2CAP_CONFIGURATION_REQ' (Core specification v5.4, Vol. 3, Part
    A):
    
      The only parameters that should be included in the
      L2CAP_CONFIGURATION_REQ packet are those that require different
      values than the default or previously agreed values.
      ...
      Any missing configuration parameters are assumed to have their
      most recently explicitly or implicitly accepted values.
    
    and '5.1 Maximum transmission unit (MTU)':
    
      If the remote device sends a positive L2CAP_CONFIGURATION_RSP
      packet it should include the actual MTU to be used on this channel
      for traffic flowing into the local device.
      ...
      The default value is 672 octets.
    
    is set by BlueZ to 672 bytes.
    
    It seems that the iPhone used the lowest negotiated value to transfer
    data to the localhost instead of the negotiated one for the incoming
    direction.
    
    This could be fixed by using the MTU negotiated for the other
    direction, if exists, in the L2CAP_CONFIGURATION_RSP.
    This allows to use segmented packets as in the following traces:
    
      < ACL Data TX: Handle 11 flags 0x00 dlen 12
            L2CAP: Connection Request (0x02) ident 22 len 4
              PSM: 4103 (0x1007)
              Source CID: 72
      < ACL Data TX: Handle 11 flags 0x00 dlen 27
            L2CAP: Configure Request (0x04) ident 24 len 19
              Destination CID: 2832
              Flags: 0x0000
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 32767
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Enhanced Retransmission (0x03)
                TX window size: 63
                Max transmit: 3
                Retransmission timeout: 2000
                Monitor timeout: 12000
                Maximum PDU size: 1009
      > ACL Data RX: Handle 11 flags 0x02 dlen 26
            L2CAP: Configure Request (0x04) ident 15 len 18
              Destination CID: 72
              Flags: 0x0000
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Enhanced Retransmission (0x03)
                TX window size: 32
                Max transmit: 255
                Retransmission timeout: 0
                Monitor timeout: 0
                Maximum PDU size: 65527
              Option: Frame Check Sequence (0x05) [mandatory]
                FCS: 16-bit FCS (0x01)
      < ACL Data TX: Handle 11 flags 0x00 dlen 29
            L2CAP: Configure Response (0x05) ident 15 len 21
              Source CID: 2832
              Flags: 0x0000
              Result: Success (0x0000)
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 32767
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Enhanced Retransmission (0x03)
                TX window size: 32
                Max transmit: 255
                Retransmission timeout: 2000
                Monitor timeout: 12000
                Maximum PDU size: 1009
      > ACL Data RX: Handle 11 flags 0x02 dlen 32
            L2CAP: Configure Response (0x05) ident 24 len 24
              Source CID: 72
              Flags: 0x0000
              Result: Success (0x0000)
              Option: Maximum Transmission Unit (0x01) [mandatory]
                MTU: 32767
              Option: Retransmission and Flow Control (0x04) [mandatory]
                Mode: Enhanced Retransmission (0x03)
                TX window size: 63
                Max transmit: 3
                Retransmission timeout: 2000
                Monitor timeout: 12000
                Maximum PDU size: 1009
              Option: Frame Check Sequence (0x05) [mandatory]
                FCS: 16-bit FCS (0x01)
      ...
      > ACL Data RX: Handle 11 flags 0x02 dlen 1009
            Channel: 72 len 1005 ctrl 0x4202 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8}
            I-frame: Start (len 21884) TxSeq 1 ReqSeq 2
      > ACL Data RX: Handle 11 flags 0x02 dlen 1009
            Channel: 72 len 1005 ctrl 0xc204 [PSM 4103 mode Enhanced Retransmission (0x03)] {chan 8}
            I-frame: Continuation TxSeq 2 ReqSeq 2
    
    This has been tested with kernel 5.4 and BlueZ 5.77.
    
    Cc: [email protected]
    Signed-off-by: Frédéric Danis <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
btrfs: don't drop extent_map for free space inode on write error [+ + +]
Author: Josef Bacik <[email protected]>
Date:   Wed Jan 31 14:27:25 2024 -0500

    btrfs: don't drop extent_map for free space inode on write error
    
    commit 5571e41ec6e56e35f34ae9f5b3a335ef510e0ade upstream.
    
    While running the CI for an unrelated change I hit the following panic
    with generic/648 on btrfs_holes_spacecache.
    
    assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
    ------------[ cut here ]------------
    kernel BUG at fs/btrfs/extent_io.c:1385!
    invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G        W          6.8.0-rc2+ #1
    RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
    Call Trace:
     <TASK>
     extent_write_cache_pages+0x2ac/0x8f0
     extent_writepages+0x87/0x110
     do_writepages+0xd5/0x1f0
     filemap_fdatawrite_wbc+0x63/0x90
     __filemap_fdatawrite_range+0x5c/0x80
     btrfs_fdatawrite_range+0x1f/0x50
     btrfs_write_out_cache+0x507/0x560
     btrfs_write_dirty_block_groups+0x32a/0x420
     commit_cowonly_roots+0x21b/0x290
     btrfs_commit_transaction+0x813/0x1360
     btrfs_sync_file+0x51a/0x640
     __x64_sys_fdatasync+0x52/0x90
     do_syscall_64+0x9c/0x190
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    This happens because we fail to write out the free space cache in one
    instance, come back around and attempt to write it again.  However on
    the second pass through we go to call btrfs_get_extent() on the inode to
    get the extent mapping.  Because this is a new block group, and with the
    free space inode we always search the commit root to avoid deadlocking
    with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
    requested range.
    
    This happens because the first time we try to write the space cache out
    we hit an error, and on an error we drop the extent mapping.  This is
    normal for normal files, but the free space cache inode is special.  We
    always expect the extent map to be correct.  Thus the second time
    through we end up with a bogus extent map.
    
    Since we're deprecating this feature, the most straightforward way to
    fix this is to simply skip dropping the extent map range for this failed
    range.
    
    I shortened the test by using error injection to stress the area to make
    it easier to reproduce.  With this patch in place we no longer panic
    with my error injection test.
    
    CC: [email protected] # 4.14+
    Reviewed-by: Filipe Manana <[email protected]>
    Signed-off-by: Josef Bacik <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    [ Larry: backport to 5.15.y. Minor conflict resolved due to missing commit 4c0c8cfc8433
      btrfs: move btrfs_drop_extent_cache() to extent_map.c ]
    Signed-off-by: Larry Bassel <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: fix missing error handling when searching for inode refs during log replay [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Wed Jun 18 16:57:07 2025 +0100

    btrfs: fix missing error handling when searching for inode refs during log replay
    
    [ Upstream commit 6561a40ceced9082f50c374a22d5966cf9fc5f5c ]
    
    During log replay, at __add_inode_ref(), when we are searching for inode
    ref keys we totally ignore if btrfs_search_slot() returns an error. This
    may make a log replay succeed when there was an actual error and leave
    some metadata inconsistency in a subvolume tree. Fix this by checking if
    an error was returned from btrfs_search_slot() and if so, return it to
    the caller.
    
    Fixes: e02119d5a7b4 ("Btrfs: Add a write ahead tree log to optimize synchronous operations")
    Reviewed-by: Johannes Thumshirn <[email protected]>
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: update superblock's device bytes_used when dropping chunk [+ + +]
Author: Mark Harmstone <[email protected]>
Date:   Thu May 29 10:37:44 2025 +0100

    btrfs: update superblock's device bytes_used when dropping chunk
    
    commit ae4477f937569d097ca5dbce92a89ba384b49bc6 upstream.
    
    Each superblock contains a copy of the device item for that device. In a
    transaction which drops a chunk but doesn't create any new ones, we were
    correctly updating the device item in the chunk tree but not copying
    over the new bytes_used value to the superblock.
    
    This can be seen by doing the following:
    
      # dd if=/dev/zero of=test bs=4096 count=2621440
      # mkfs.btrfs test
      # mount test /root/temp
    
      # cd /root/temp
      # for i in {00..10}; do dd if=/dev/zero of=$i bs=4096 count=32768; done
      # sync
      # rm *
      # sync
      # btrfs balance start -dusage=0 .
      # sync
    
      # cd
      # umount /root/temp
      # btrfs check test
    
    For btrfs-check to detect this, you will also need my patch at
    https://github.com/kdave/btrfs-progs/pull/991.
    
    Change btrfs_remove_dev_extents() so that it adds the devices to the
    fs_info->post_commit_list if they're not there already. This causes
    btrfs_commit_device_sizes() to be called, which updates the bytes_used
    value in the superblock.
    
    Fixes: bbbf7243d62d ("btrfs: combine device update operations during transaction commit")
    CC: [email protected] # 5.10+
    Reviewed-by: Qu Wenruo <[email protected]>
    Signed-off-by: Mark Harmstone <[email protected]>
    Reviewed-by: David Sterba <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ceph: fix possible integer overflow in ceph_zero_objects() [+ + +]
Author: Dmitry Kandybka <[email protected]>
Date:   Tue Apr 22 12:32:04 2025 +0300

    ceph: fix possible integer overflow in ceph_zero_objects()
    
    [ Upstream commit 0abd87942e0c93964e93224836944712feba1d91 ]
    
    In 'ceph_zero_objects', promote 'object_size' to 'u64' to avoid possible
    integer overflow.
    
    Compile tested only.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Dmitry Kandybka <[email protected]>
    Reviewed-by: Viacheslav Dubeyko <[email protected]>
    Signed-off-by: Ilya Dryomov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cifs: Fix cifs_query_path_info() for Windows NT servers [+ + +]
Author: Pali Rohár <[email protected]>
Date:   Tue Dec 31 16:06:22 2024 +0100

    cifs: Fix cifs_query_path_info() for Windows NT servers
    
    [ Upstream commit a3e771afbb3bce91c8296828304903e7348003fe ]
    
    For TRANS2 QUERY_PATH_INFO request when the path does not exist, the
    Windows NT SMB server returns error response STATUS_OBJECT_NAME_NOT_FOUND
    or ERRDOS/ERRbadfile without the SMBFLG_RESPONSE flag set. Similarly it
    returns STATUS_DELETE_PENDING when the file is being deleted. And looks
    like that any error response from TRANS2 QUERY_PATH_INFO does not have
    SMBFLG_RESPONSE flag set.
    
    So relax check in check_smb_hdr() for detecting if the packet is response
    for this special case.
    
    This change fixes stat() operation against Windows NT SMB servers and also
    all operations which depends on -ENOENT result from stat like creat() or
    mkdir().
    
    Signed-off-by: Pali Rohár <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
 
clk: ti: am43xx: Add clkctrl data for am43xx ADC1 [+ + +]
Author: Miquel Raynal <[email protected]>
Date:   Fri Oct 15 10:14:19 2021 +0200

    clk: ti: am43xx: Add clkctrl data for am43xx ADC1
    
    [ Upstream commit 59139ada4a7eacd4db378ee40a3d6ffbf1d0d72f ]
    
    Declare ADC1 clkctrl which feeds the magnetic-reader/ADC1 hardware
    module.
    
    Signed-off-by: Miquel Raynal <[email protected]>
    Acked-by: Stephen Boyd <[email protected]>
    Acked-by: Tony Lindgren <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Stable-dep-of: d52b9b7e2f10 ("media: imx-jpeg: Drop the first error frames")
    Signed-off-by: Sasha Levin <[email protected]>

 
coresight: Only check bottom two claim bits [+ + +]
Author: James Clark <[email protected]>
Date:   Tue Mar 25 11:58:47 2025 +0000

    coresight: Only check bottom two claim bits
    
    [ Upstream commit a4e65842e1142aa18ef36113fbd81d614eaefe5a ]
    
    The use of the whole register and == could break the claim mechanism if
    any of the other bits are used in the future. The referenced doc "PSCI -
    ARM DEN 0022D" also says to only read and clear the bottom two bits.
    
    Use FIELD_GET() to extract only the relevant part.
    
    Reviewed-by: Leo Yan <[email protected]>
    Reviewed-by: Yeoreum Yun <[email protected]>
    Signed-off-by: James Clark <[email protected]>
    Signed-off-by: Suzuki K Poulose <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
dm-raid: fix variable in journal device check [+ + +]
Author: Heinz Mauelshagen <[email protected]>
Date:   Tue Jun 10 20:53:30 2025 +0200

    dm-raid: fix variable in journal device check
    
    commit db53805156f1e0aa6d059c0d3f9ac660d4ef3eb4 upstream.
    
    Replace "rdev" with correct loop variable name "r".
    
    Signed-off-by: Heinz Mauelshagen <[email protected]>
    Cc: [email protected]
    Fixes: 63c32ed4afc2 ("dm raid: add raid4/5/6 journaling support")
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dmaengine: xilinx_dma: Set dma_device directions [+ + +]
Author: Thomas Gessler <[email protected]>
Date:   Wed May 7 20:21:01 2025 +0200

    dmaengine: xilinx_dma: Set dma_device directions
    
    [ Upstream commit 7e01511443c30a55a5ae78d3debd46d4d872517e ]
    
    Coalesce the direction bits from the enabled TX and/or RX channels into
    the directions bit mask of dma_device. Without this mask set,
    dma_get_slave_caps() in the DMAEngine fails, which prevents the driver
    from being used with an IIO DMAEngine buffer.
    
    Signed-off-by: Thomas Gessler <[email protected]>
    Reviewed-by: Suraj Gupta <[email protected]>
    Tested-by: Folker Schwesinger <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Vinod Koul <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dpaa2-eth: fix xdp_rxq_info leak [+ + +]
Author: Fushuai Wang <[email protected]>
Date:   Mon Jul 7 16:06:22 2025 -0400

    dpaa2-eth: fix xdp_rxq_info leak
    
    [ Upstream commit 2def09ead4ad5907988b655d1e1454003aaf8297 ]
    
    The driver registered xdp_rxq_info structures via xdp_rxq_info_reg()
    but failed to properly unregister them in error paths and during
    removal.
    
    Fixes: d678be1dc1ec ("dpaa2-eth: add XDP_REDIRECT support")
    Signed-off-by: Fushuai Wang <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Reviewed-by: Ioana Ciornei <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

dpaa2-eth: Update dpni_get_single_step_cfg command [+ + +]
Author: Radu Bulie <[email protected]>
Date:   Fri Feb 18 22:22:00 2022 +0200

    dpaa2-eth: Update dpni_get_single_step_cfg command
    
    [ Upstream commit 9572594ecf027a2b1828e42c26fb55cbd3219708 ]
    
    dpni_get_single_step_cfg is an MC firmware command used for
    retrieving the contents of SINGLE_STEP 1588 register available
    in a DPMAC.
    
    This patch adds a new version of this command that returns as an extra
    argument the physical base address of the aforementioned register.
    The address will be used to directly modify the contents of the
    SINGLE_STEP register instead of invoking the MC command
    dpni_set_single_step_cgf. The former approach introduced huge delays on
    the TX datapath when one step PTP events were transmitted. This led to low
    throughput and high latencies observed in the PTP correction field.
    
    Signed-off-by: Radu Bulie <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 2def09ead4ad ("dpaa2-eth: fix xdp_rxq_info leak")
    Signed-off-by: Sasha Levin <[email protected]>

dpaa2-eth: Update SINGLE_STEP register access [+ + +]
Author: Radu Bulie <[email protected]>
Date:   Fri Feb 18 22:22:01 2022 +0200

    dpaa2-eth: Update SINGLE_STEP register access
    
    [ Upstream commit c4680c978567328a696fd2400bbf58a36cff95d1 ]
    
    DPAA2 MAC supports 1588 one step timestamping.
    If this option is enabled then for each transmitted PTP event packet,
    the 1588 SINGLE_STEP register is accessed to modify the following fields:
    
    -offset of the correction field inside the PTP packet
    -UDP checksum update bit,  in case the PTP event packet has
     UDP encapsulation
    
    These values can change any time, because there may be multiple
    PTP clients connected, that receive various 1588 frame types:
    - L2 only frame
    - UDP / Ipv4
    - UDP / Ipv6
    - other
    
    The current implementation uses dpni_set_single_step_cfg to update the
    SINLGE_STEP register.
    Using an MC command  on the Tx datapath for each transmitted 1588 message
    introduces high delays, leading to low throughput and consequently to a
    small number of supported PTP clients. Besides these, the nanosecond
    correction field from the PTP packet will contain the high delay from the
    driver which together with the originTimestamp will render timestamp
    values that are unacceptable in a GM clock implementation.
    
    This patch updates the Tx datapath for 1588 messages when single step
    timestamp is enabled and provides direct access to SINGLE_STEP register,
    eliminating the  overhead caused by the dpni_set_single_step_cfg
    MC command. MC version >= 10.32 implements this functionality.
    If the MC version does not have support for returning the
    single step register base address, the driver will use
    dpni_set_single_step_cfg command for updates operations.
    
    All the delay introduced by dpni_set_single_step_cfg
    function will be eliminated (if MC version has support for returning the
    base address of the single step register), improving the egress driver
    performance for PTP packets when single step timestamping is enabled.
    
    Before these changes the maximum throughput for 1588 messages with
    single step hardware timestamp enabled was around 2000pps.
    After the updates the throughput increased up to 32.82 Mbps / 46631.02 pps.
    
    Signed-off-by: Radu Bulie <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 2def09ead4ad ("dpaa2-eth: fix xdp_rxq_info leak")
    Signed-off-by: Sasha Levin <[email protected]>

 
Drivers: hv: Rename 'alloced' to 'allocated' [+ + +]
Author: Vitaly Kuznetsov <[email protected]>
Date:   Fri Jan 28 11:34:11 2022 +0100

    Drivers: hv: Rename 'alloced' to 'allocated'
    
    [ Upstream commit de96e8a09889b35dd8d1cb6d19ef2bb123b05be1 ]
    
    'Alloced' is not a real word and only saves us two letters, let's
    use 'allocated' instead.
    
    No functional change intended.
    
    Signed-off-by: Vitaly Kuznetsov <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Stable-dep-of: 0315fef2aff9 ("uio_hv_generic: Align ring size to system page")
    Signed-off-by: Sasha Levin <[email protected]>

Drivers: hv: vmbus: Add utility function for querying ring size [+ + +]
Author: Saurabh Sengar <[email protected]>
Date:   Sat Mar 30 01:51:57 2024 -0700

    Drivers: hv: vmbus: Add utility function for querying ring size
    
    [ Upstream commit e8c4bd6c6e6b7e7b416c42806981c2a81370001e ]
    
    Add a function to query for the preferred ring buffer size of VMBus
    device. This will allow the drivers (eg. UIO) to allocate the most
    optimized ring buffer size for devices.
    
    Signed-off-by: Saurabh Sengar <[email protected]>
    Reviewed-by: Long Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 0315fef2aff9 ("uio_hv_generic: Align ring size to system page")
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/amd/display: Add null pointer check for get_first_active_display() [+ + +]
Author: Wentao Liang <[email protected]>
Date:   Mon May 26 10:37:31 2025 +0800

    drm/amd/display: Add null pointer check for get_first_active_display()
    
    commit c3e9826a22027a21d998d3e64882fa377b613006 upstream.
    
    The function mod_hdcp_hdcp1_enable_encryption() calls the function
    get_first_active_display(), but does not check its return value.
    The return value is a null pointer if the display list is empty.
    This will lead to a null pointer dereference in
    mod_hdcp_hdcp2_enable_encryption().
    
    Add a null pointer check for get_first_active_display() and return
    MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.
    
    Fixes: 2deade5ede56 ("drm/amd/display: Remove hdcp display state with mst fix")
    Signed-off-by: Wentao Liang <[email protected]>
    Reviewed-by: Alex Hung <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    Cc: [email protected] # v5.8
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/amdkfd: Fix race in GWS queue scheduling [+ + +]
Author: Jay Cornwall <[email protected]>
Date:   Wed Jun 11 09:52:14 2025 -0500

    drm/amdkfd: Fix race in GWS queue scheduling
    
    commit cfb05257ae168a0496c7637e1d9e3ab8a25cbffe upstream.
    
    q->gws is not updated atomically with qpd->mapped_gws_queue. If a
    runlist is created between pqm_set_gws and update_queue it will
    contain a queue which uses GWS in a process with no GWS allocated.
    This will result in a scheduler hang.
    
    Use q->properties.is_gws which is changed while holding the DQM lock.
    
    Signed-off-by: Jay Cornwall <[email protected]>
    Reviewed-by: Harish Kasiviswanathan <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit b98370220eb3110e82248e3354e16a489a492cfb)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/bridge: cdns-dsi: Check return value when getting default PHY config [+ + +]
Author: Aradhya Bhatia <[email protected]>
Date:   Sat Mar 29 17:09:15 2025 +0530

    drm/bridge: cdns-dsi: Check return value when getting default PHY config
    
    commit c6a7ef0d4856b9629df390e9935d7fd67fe39f81 upstream.
    
    Check for the return value of the phy_mipi_dphy_get_default_config()
    call, and in case of an error, return back the same.
    
    Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
    Cc: [email protected]
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Tested-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/bridge: cdns-dsi: Fix connecting to next bridge [+ + +]
Author: Aradhya Bhatia <[email protected]>
Date:   Sat Mar 29 17:09:12 2025 +0530

    drm/bridge: cdns-dsi: Fix connecting to next bridge
    
    commit 688eb4d465484bc2a3471a6a6f06f833b58c7867 upstream.
    
    Fix the OF node pointer passed to the of_drm_find_bridge() call to find
    the next bridge in the display chain.
    
    The code to find the next panel (and create its panel-bridge) works
    fine, but to find the next (non-panel) bridge does not.
    
    To find the next bridge in the pipeline, we need to pass "np" - the OF
    node pointer of the next entity in the devicetree chain. Passing
    "of_node" to of_drm_find_bridge (which is what the code does currently)
    will fetch the bridge for the cdns-dsi which is not what's required.
    
    Fix that.
    
    Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
    Cc: [email protected]
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Tested-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/bridge: cdns-dsi: Fix the clock variable for mode_valid() [+ + +]
Author: Aradhya Bhatia <[email protected]>
Date:   Sat Mar 29 17:09:14 2025 +0530

    drm/bridge: cdns-dsi: Fix the clock variable for mode_valid()
    
    commit 132bdcec399be6ae947582249a134b38cf56731c upstream.
    
    The crtc_* mode parameters do not get generated (duplicated in this
    case) from the regular parameters before the mode validation phase
    begins.
    
    The rest of the code conditionally uses the crtc_* parameters only
    during the bridge enable phase, but sticks to the regular parameters
    for mode validation. In this singular instance, however, the driver
    tries to use the crtc_clock parameter even during the mode validation,
    causing the validation to fail.
    
    Allow the D-Phy config checks to use mode->clock instead of
    mode->crtc_clock during mode_valid checks, like everywhere else in the
    driver.
    
    Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
    Cc: [email protected]
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Reviewed-by: Dmitry Baryshkov <[email protected]>
    Tested-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready [+ + +]
Author: Aradhya Bhatia <[email protected]>
Date:   Sat Mar 29 17:09:16 2025 +0530

    drm/bridge: cdns-dsi: Wait for Clk and Data Lanes to be ready
    
    commit 47c03e6660e96cbba0239125b1d4a9db3c724b1d upstream.
    
    Once the DSI Link and DSI Phy are initialized, the code needs to wait
    for Clk and Data Lanes to be ready, before continuing configuration.
    This is in accordance with the DSI Start-up procedure, found in the
    Technical Reference Manual of Texas Instrument's J721E SoC[0] which
    houses this DSI TX controller.
    
    If the previous bridge (or crtc/encoder) are configured pre-maturely,
    the input signal FIFO gets corrupt. This introduces a color-shift on the
    display.
    
    Allow the driver to wait for the clk and data lanes to get ready during
    DSI enable.
    
    [0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM
         TRM Link: http://www.ti.com/lit/pdf/spruil1
    
    Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver")
    Cc: [email protected]
    Tested-by: Dominik Haller <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Tested-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Signed-off-by: Aradhya Bhatia <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Dmitry Baryshkov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/exynos: fimd: Guard display clock control with runtime PM calls [+ + +]
Author: Marek Szyprowski <[email protected]>
Date:   Wed Jun 18 14:06:26 2025 +0200

    drm/exynos: fimd: Guard display clock control with runtime PM calls
    
    [ Upstream commit 5d91394f236167ac624b823820faf4aa928b889e ]
    
    Commit c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable
    and post-disable") changed the call sequence to the CRTC enable/disable
    and bridge pre_enable/post_disable methods, so those bridge methods are
    now called when CRTC is not yet enabled.
    
    This causes a lockup observed on Samsung Peach-Pit/Pi Chromebooks. The
    source of this lockup is a call to fimd_dp_clock_enable() function, when
    FIMD device is not yet runtime resumed. It worked before the mentioned
    commit only because the CRTC implemented by the FIMD driver was always
    enabled what guaranteed the FIMD device to be runtime resumed.
    
    This patch adds runtime PM guards to the fimd_dp_clock_enable() function
    to enable its proper operation also when the CRTC implemented by FIMD is
    not yet enabled.
    
    Fixes: 196e059a8a6a ("drm/exynos: convert clock_enable crtc callback to pipeline clock")
    Signed-off-by: Marek Szyprowski <[email protected]>
    Reviewed-by: Tomi Valkeinen <[email protected]>
    Signed-off-by: Inki Dae <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/gt: Fix timeline left held on VMA alloc error [+ + +]
Author: Janusz Krzysztofik <[email protected]>
Date:   Wed Jun 11 12:42:13 2025 +0200

    drm/i915/gt: Fix timeline left held on VMA alloc error
    
    [ Upstream commit a5aa7bc1fca78c7fa127d9e33aa94a0c9066c1d6 ]
    
    The following error has been reported sporadically by CI when a test
    unbinds the i915 driver on a ring submission platform:
    
    <4> [239.330153] ------------[ cut here ]------------
    <4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count)
    <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]
    ...
    <4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]
    ...
    <4> [239.330942] Call Trace:
    <4> [239.330944]  <TASK>
    <4> [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]
    <4> [239.331202]  i915_driver_release+0x86/0xa0 [i915]
    <4> [239.331482]  devm_drm_dev_init_release+0x61/0x90
    <4> [239.331494]  devm_action_release+0x15/0x30
    <4> [239.331504]  release_nodes+0x3d/0x120
    <4> [239.331517]  devres_release_all+0x96/0xd0
    <4> [239.331533]  device_unbind_cleanup+0x12/0x80
    <4> [239.331543]  device_release_driver_internal+0x23a/0x280
    <4> [239.331550]  ? bus_find_device+0xa5/0xe0
    <4> [239.331563]  device_driver_detach+0x14/0x20
    ...
    <4> [357.719679] ---[ end trace 0000000000000000 ]---
    
    If the test also unloads the i915 module then that's followed with:
    
    <3> [357.787478] =============================================================================
    <3> [357.788006] BUG i915_vma (Tainted: G     U  W        N ): Objects remaining on __kmem_cache_shutdown()
    <3> [357.788031] -----------------------------------------------------------------------------
    <3> [357.788204] Object 0xffff888109e7f480 @offset=29824
    <3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244
    <4> [357.788994]  i915_vma_instance+0xee/0xc10 [i915]
    <4> [357.789290]  init_status_page+0x7b/0x420 [i915]
    <4> [357.789532]  intel_engines_init+0x1d8/0x980 [i915]
    <4> [357.789772]  intel_gt_init+0x175/0x450 [i915]
    <4> [357.790014]  i915_gem_init+0x113/0x340 [i915]
    <4> [357.790281]  i915_driver_probe+0x847/0xed0 [i915]
    <4> [357.790504]  i915_pci_probe+0xe6/0x220 [i915]
    ...
    
    Closer analysis of CI results history has revealed a dependency of the
    error on a few IGT tests, namely:
    - igt@api_intel_allocator@fork-simple-stress-signal,
    - igt@api_intel_allocator@two-level-inception-interruptible,
    - igt@gem_linear_blits@interruptible,
    - igt@prime_mmap_coherency@ioctl-errors,
    which invisibly trigger the issue, then exhibited with first driver unbind
    attempt.
    
    All of the above tests perform actions which are actively interrupted with
    signals.  Further debugging has allowed to narrow that scope down to
    DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring
    submission, in particular.
    
    If successful then that function, or its execlists or GuC submission
    equivalent, is supposed to be called only once per GEM context engine,
    followed by raise of a flag that prevents the function from being called
    again.  The function is expected to unwind its internal errors itself, so
    it may be safely called once more after it returns an error.
    
    In case of ring submission, the function first gets a reference to the
    engine's legacy timeline and then allocates a VMA.  If the VMA allocation
    fails, e.g. when i915_vma_instance() called from inside is interrupted
    with a signal, then ring_context_alloc() fails, leaving the timeline held
    referenced.  On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the
    timeline is got, and only that last one is put on successful completion.
    As a consequence, the legacy timeline, with its underlying engine status
    page's VMA object, is still held and not released on driver unbind.
    
    Get the legacy timeline only after successful allocation of the context
    engine's VMA.
    
    v2: Add a note on other submission methods (Krzysztof Karas):
        Both execlists and GuC submission use lrc_alloc() which seems free
        from a similar issue.
    
    Fixes: 75d0a7f31eec ("drm/i915: Lift timeline into intel_context")
    Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061
    Cc: Chris Wilson <[email protected]>
    Cc: Matthew Auld <[email protected]>
    Cc: Krzysztof Karas <[email protected]>
    Reviewed-by: Sebastian Brzezinka <[email protected]>
    Reviewed-by: Krzysztof Niemiec <[email protected]>
    Signed-off-by: Janusz Krzysztofik <[email protected]>
    Reviewed-by: Nitin Gote <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    (cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/selftests: Change mock_request() to return error pointers [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Wed Jun 25 10:21:58 2025 -0500

    drm/i915/selftests: Change mock_request() to return error pointers
    
    [ Upstream commit caa7c7a76b78ce41d347003f84975125383e6b59 ]
    
    There was an error pointer vs NULL bug in __igt_breadcrumbs_smoketest().
    The __mock_request_alloc() function implements the
    smoketest->request_alloc() function pointer.  It was supposed to return
    error pointers, but it propogates the NULL return from mock_request()
    so in the event of a failure, it would lead to a NULL pointer
    dereference.
    
    To fix this, change the mock_request() function to return error pointers
    and update all the callers to expect that.
    
    Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context interrupt tracking")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Rodrigo Vivi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rodrigo Vivi <[email protected]>
    (cherry picked from commit 778fa8ad5f0f23397d045c7ebca048ce8def1c43)
    Signed-off-by: Joonas Lahtinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/msm: Fix a fence leak in submit error path [+ + +]
Author: Rob Clark <[email protected]>
Date:   Wed May 14 09:33:32 2025 -0700

    drm/msm: Fix a fence leak in submit error path
    
    [ Upstream commit 5d319f75ccf7f0927425a7545aa1a22b3eedc189 ]
    
    In error paths, we could unref the submit without calling
    drm_sched_entity_push_job(), so msm_job_free() will never get
    called.  Since drm_sched_job_cleanup() will NULL out the
    s_fence, we can use that to detect this case.
    
    Signed-off-by: Rob Clark <[email protected]>
    Patchwork: https://patchwork.freedesktop.org/patch/653584/
    Signed-off-by: Rob Clark <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/tegra: Assign plane type before registration [+ + +]
Author: Thierry Reding <[email protected]>
Date:   Mon Apr 21 11:13:05 2025 -0500

    drm/tegra: Assign plane type before registration
    
    commit 9ff4fdf4f44b69237c0afc1d3a8dac916ce66f3e upstream.
    
    Changes to a plane's type after it has been registered aren't propagated
    to userspace automatically. This could possibly be achieved by updating
    the property, but since we can already determine which type this should
    be before the registration, passing in the right type from the start is
    a much better solution.
    
    Suggested-by: Aaron Kling <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Cc: [email protected]
    Fixes: 473079549f27 ("drm/tegra: dc: Add Tegra186 support")
    Signed-off-by: Aaron Kling <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

drm/tegra: Fix a possible null pointer dereference [+ + +]
Author: Qiu-ji Chen <[email protected]>
Date:   Wed Nov 6 17:59:06 2024 +0800

    drm/tegra: Fix a possible null pointer dereference
    
    commit 780351a5f61416ed2ba1199cc57e4a076fca644d upstream.
    
    In tegra_crtc_reset(), new memory is allocated with kzalloc(), but
    no check is performed. Before calling __drm_atomic_helper_crtc_reset,
    state should be checked to prevent possible null pointer dereference.
    
    Fixes: b7e0b04ae450 ("drm/tegra: Convert to using __drm_atomic_helper_crtc_reset() for reset.")
    Cc: [email protected]
    Signed-off-by: Qiu-ji Chen <[email protected]>
    Signed-off-by: Thierry Reding <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/udl: Unregister device before cleaning up on disconnect [+ + +]
Author: Thomas Zimmermann <[email protected]>
Date:   Mon Mar 3 15:52:56 2025 +0100

    drm/udl: Unregister device before cleaning up on disconnect
    
    commit ff9cb6d2035c586ea7c8f1754d4409eec7a2d26d upstream.
    
    Disconnecting a DisplayLink device results in the following kernel
    error messages
    
    [   93.041748] [drm:udl_urb_completion [udl]] *ERROR* udl_urb_completion - nonzero write bulk status received: -115
    [   93.055299] [drm:udl_submit_urb [udl]] *ERROR* usb_submit_urb error fffffffe
    [   93.065363] [drm:udl_urb_completion [udl]] *ERROR* udl_urb_completion - nonzero write bulk status received: -115
    [   93.078207] [drm:udl_submit_urb [udl]] *ERROR* usb_submit_urb error fffffffe
    
    coming from KMS poll helpers. Shutting down poll helpers runs them
    one final time when the USB device is already gone.
    
    Run drm_dev_unplug() first in udl's USB disconnect handler. Udl's
    polling code already handles disconnects gracefully if the device has
    been marked as unplugged.
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Fixes: b1a981bd5576 ("drm/udl: drop drm_driver.release hook")
    Cc: [email protected]
    Cc: <[email protected]> # v5.8+
    Reviewed-by: Patrik Jakobsson <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/v3d: Disable interrupts before resetting the GPU [+ + +]
Author: Maíra Canal <[email protected]>
Date:   Sat Jun 28 19:42:42 2025 -0300

    drm/v3d: Disable interrupts before resetting the GPU
    
    [ Upstream commit 226862f50a7a88e4e4de9abbf36c64d19acd6fd0 ]
    
    Currently, an interrupt can be triggered during a GPU reset, which can
    lead to GPU hangs and NULL pointer dereference in an interrupt context
    as shown in the following trace:
    
     [  314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0
     [  314.043822] Mem abort info:
     [  314.046606]   ESR = 0x0000000096000005
     [  314.050347]   EC = 0x25: DABT (current EL), IL = 32 bits
     [  314.055651]   SET = 0, FnV = 0
     [  314.058695]   EA = 0, S1PTW = 0
     [  314.061826]   FSC = 0x05: level 1 translation fault
     [  314.066694] Data abort info:
     [  314.069564]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
     [  314.075039]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
     [  314.080080]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
     [  314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000
     [  314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
     [  314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
     [  314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight
     [  314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1  Debian 1:6.12.25-1+rpt1
     [  314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
     [  314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     [  314.152165] pc : v3d_irq+0xec/0x2e0 [v3d]
     [  314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d]
     [  314.160198] sp : ffffffc080003ea0
     [  314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000
     [  314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0
     [  314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000
     [  314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000
     [  314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000
     [  314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001
     [  314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874
     [  314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180
     [  314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb
     [  314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
     [  314.234807] Call trace:
     [  314.237243]  v3d_irq+0xec/0x2e0 [v3d]
     [  314.240906]  __handle_irq_event_percpu+0x58/0x218
     [  314.245609]  handle_irq_event+0x54/0xb8
     [  314.249439]  handle_fasteoi_irq+0xac/0x240
     [  314.253527]  handle_irq_desc+0x48/0x68
     [  314.257269]  generic_handle_domain_irq+0x24/0x38
     [  314.261879]  gic_handle_irq+0x48/0xd8
     [  314.265533]  call_on_irq_stack+0x24/0x58
     [  314.269448]  do_interrupt_handler+0x88/0x98
     [  314.273624]  el1_interrupt+0x34/0x68
     [  314.277193]  el1h_64_irq_handler+0x18/0x28
     [  314.281281]  el1h_64_irq+0x64/0x68
     [  314.284673]  default_idle_call+0x3c/0x168
     [  314.288675]  do_idle+0x1fc/0x230
     [  314.291895]  cpu_startup_entry+0x3c/0x50
     [  314.295810]  rest_init+0xe4/0xf0
     [  314.299030]  start_kernel+0x5e8/0x790
     [  314.302684]  __primary_switched+0x80/0x90
     [  314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017)
     [  314.312775] ---[ end trace 0000000000000000 ]---
     [  314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt
     [  314.324249] SMP: stopping secondary CPUs
     [  314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000
     [  314.334076] PHYS_OFFSET: 0x0
     [  314.336946] CPU features: 0x08,00002013,c0200000,0200421b
     [  314.342337] Memory Limit: none
     [  314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
    
    Before resetting the GPU, it's necessary to disable all interrupts and
    deal with any interrupt handler still in-flight. Otherwise, the GPU might
    reset with jobs still running, or yet, an interrupt could be handled
    during the reset.
    
    Cc: [email protected]
    Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+")
    Reviewed-by: Juan A. Suarez <[email protected]>
    Reviewed-by: Iago Toral Quiroga <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Maíra Canal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive [+ + +]
Author: Yao Zi <[email protected]>
Date:   Mon Jun 23 09:34:45 2025 +0000

    dt-bindings: serial: 8250: Make clocks and clock-frequency exclusive
    
    commit 09812134071b3941fb81def30b61ed36d3a5dfb5 upstream.
    
    The 8250 binding before converting to json-schema states,
    
      - clock-frequency : the input clock frequency for the UART
            or
      - clocks phandle to refer to the clk used as per Documentation/devicetree
    
    for clock-related properties, where "or" indicates these properties
    shouldn't exist at the same time.
    
    Additionally, the behavior of Linux's driver is strange when both clocks
    and clock-frequency are specified: it ignores clocks and obtains the
    frequency from clock-frequency, left the specified clocks unclaimed. It
    may even be disabled, which is undesired most of the time.
    
    But "anyOf" doesn't prevent these two properties from coexisting, as it
    considers the object valid as long as there's at LEAST one match.
    
    Let's switch to "oneOf" and disallows the other property if one exists,
    precisely matching the original binding and avoiding future confusion on
    the driver's behavior.
    
    Fixes: e69f5dc623f9 ("dt-bindings: serial: Convert 8250 to json-schema")
    Cc: stable <[email protected]>
    Signed-off-by: Yao Zi <[email protected]>
    Reviewed-by: Conor Dooley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
dummycon: Trigger redraw when switching consoles with deferred takeover [+ + +]
Author: Thomas Zimmermann <[email protected]>
Date:   Tue May 20 09:14:00 2025 +0200

    dummycon: Trigger redraw when switching consoles with deferred takeover
    
    [ Upstream commit 03bcbbb3995ba5df43af9aba45334e35f2dfe27b ]
    
    Signal vt subsystem to redraw console when switching to dummycon
    with deferred takeover enabled. Makes the console switch to fbcon
    and displays the available output.
    
    With deferred takeover enabled, dummycon acts as the placeholder
    until the first output to the console happens. At that point, fbcon
    takes over. If the output happens while dummycon is not active, it
    cannot inform fbcon. This is the case if the vt subsystem runs in
    graphics mode.
    
    A typical graphical boot starts plymouth, a display manager and a
    compositor; all while leaving out dummycon. Switching to a text-mode
    console leaves the console with dummycon even if a getty terminal
    has been started.
    
    Returning true from dummycon's con_switch helper signals the vt
    subsystem to redraw the screen. If there's output available dummycon's
    con_putc{s} helpers trigger deferred takeover of fbcon, which sets a
    display mode and displays the output. If no output is available,
    dummycon remains active.
    
    v2:
    - make the comment slightly more verbose (Javier)
    
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Reported-by: Andrei Borzenkov <[email protected]>
    Closes: https://bugzilla.suse.com/show_bug.cgi?id=1242191
    Tested-by: Andrei Borzenkov <[email protected]>
    Acked-by: Javier Martinez Canillas <[email protected]>
    Fixes: 83d83bebf401 ("console/fbcon: Add support for deferred console takeover")
    Cc: Hans de Goede <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: <[email protected]> # v4.19+
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
enic: fix incorrect MTU comparison in enic_change_mtu() [+ + +]
Author: Alok Tiwari <[email protected]>
Date:   Sat Jun 28 07:56:05 2025 -0700

    enic: fix incorrect MTU comparison in enic_change_mtu()
    
    [ Upstream commit aaf2b2480375099c022a82023e1cd772bf1c6a5d ]
    
    The comparison in enic_change_mtu() incorrectly used the current
    netdev->mtu instead of the new new_mtu value when warning about
    an MTU exceeding the port MTU. This could suppress valid warnings
    or issue incorrect ones.
    
    Fix the condition and log to properly reflect the new_mtu.
    
    Fixes: ab123fe071c9 ("enic: handle mtu change for vf properly")
    Signed-off-by: Alok Tiwari <[email protected]>
    Acked-by: John Daley <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ethernet: atl1: Add missing DMA mapping error checks and count errors [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Wed Jun 25 16:16:24 2025 +0200

    ethernet: atl1: Add missing DMA mapping error checks and count errors
    
    [ Upstream commit d72411d20905180cdc452c553be17481b24463d2 ]
    
    The `dma_map_XXX()` functions can fail and must be checked using
    `dma_mapping_error()`.  This patch adds proper error handling for all
    DMA mapping calls.
    
    In `atl1_alloc_rx_buffers()`, if DMA mapping fails, the buffer is
    deallocated and marked accordingly.
    
    In `atl1_tx_map()`, previously mapped buffers are unmapped and the
    packet is dropped on failure.
    
    If `atl1_xmit_frame()` drops the packet, increment the tx_error counter.
    
    Fixes: f3cc28c79760 ("Add Attansic L1 ethernet driver.")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
f2fs: don't over-report free space or inodes in statvfs [+ + +]
Author: Chao Yu <[email protected]>
Date:   Tue May 13 19:25:38 2025 +0800

    f2fs: don't over-report free space or inodes in statvfs
    
    [ Upstream commit a9201960623287927bf5776de3f70fb2fbde7e02 ]
    
    This fixes an analogus bug that was fixed in modern filesystems:
    a) xfs in commit 4b8d867ca6e2 ("xfs: don't over-report free space or
    inodes in statvfs")
    b) ext4 in commit f87d3af74193 ("ext4: don't over-report free space
    or inodes in statvfs")
    where statfs can report misleading / incorrect information where
    project quota is enabled, and the free space is less than the
    remaining quota.
    
    This commit will resolve a test failure in generic/762 which tests
    for this bug.
    
    generic/762       - output mismatch (see /share/git/fstests/results//generic/762.out.bad)
    #    --- tests/generic/762.out   2025-04-15 10:21:53.371067071 +0800
    #    +++ /share/git/fstests/results//generic/762.out.bad 2025-05-13 16:13:37.000000000 +0800
    #    @@ -6,8 +6,10 @@
    #     root blocks2 is in range
    #     dir blocks2 is in range
    #     root bavail2 is in range
    #    -dir bavail2 is in range
    #    +dir bavail2 has value of 1539066
    #    +dir bavail2 is NOT in range 304734.87 .. 310891.13
    #     root blocks3 is in range
    #    ...
    #    (Run 'diff -u /share/git/fstests/tests/generic/762.out /share/git/fstests/results//generic/762.out.bad'  to see the entire diff)
    
    HINT: You _MAY_ be missing kernel fix:
          XXXXXXXXXXXXXX xfs: don't over-report free space or inodes in statvfs
    
    Cc: [email protected]
    Fixes: ddc34e328d06 ("f2fs: introduce f2fs_statfs_project")
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fbcon: delete a few unneeded forward decl [+ + +]
Author: Simona Vetter <[email protected]>
Date:   Tue Apr 5 23:03:19 2022 +0200

    fbcon: delete a few unneeded forward decl
    
    [ Upstream commit 9ad7acdad1d91545b99bf9fda3de4b86cf48b272 ]
    
    I didn't bother with any code movement to fix the others, these just
    got a bit in the way.
    
    v2: Rebase on top of Helge's reverts.
    
    Acked-by: Thomas Zimmermann <[email protected]>
    Acked-by: Sam Ravnborg <[email protected]> (v1)
    Reviewed-by: Geert Uytterhoeven <[email protected]> (v1)
    Signed-off-by: Daniel Vetter <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Du Cheng <[email protected]>
    Cc: Tetsuo Handa <[email protected]>
    Cc: Claudio Suarez <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Stable-dep-of: 03bcbbb3995b ("dummycon: Trigger redraw when switching consoles with deferred takeover")
    Signed-off-by: Sasha Levin <[email protected]>

 
fs/jfs: consolidate sanity checking in dbMount [+ + +]
Author: Dave Kleikamp <[email protected]>
Date:   Thu Feb 20 10:31:19 2025 -0600

    fs/jfs: consolidate sanity checking in dbMount
    
    [ Upstream commit 0d250b1c52484d489e31df2cf9118b7c4bd49d31 ]
    
    Sanity checks have been added to dbMount as individual if clauses with
    identical error handling. Move these all into one clause.
    
    Signed-off-by: Dave Kleikamp <[email protected]>
    Stable-dep-of: 37bfb464ddca ("jfs: validate AG parameters in dbMount() to prevent crashes")
    Signed-off-by: Sasha Levin <[email protected]>

 
HID: wacom: fix kobject reference count leak [+ + +]
Author: Qasim Ijaz <[email protected]>
Date:   Fri Jun 6 19:49:59 2025 +0100

    HID: wacom: fix kobject reference count leak
    
    commit 85a720f4337f0ddf1603c8b75a8f1ffbbe022ef9 upstream.
    
    When sysfs_create_files() fails in wacom_initialize_remotes() the error
    is returned and the cleanup action will not have been registered yet.
    
    As a result the kobject???s refcount is never dropped, so the
    kobject can never be freed leading to a reference leak.
    
    Fix this by calling kobject_put() before returning.
    
    Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated")
    Acked-by: Ping Cheng <[email protected]>
    Cc: [email protected]
    Signed-off-by: Qasim Ijaz <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: wacom: fix memory leak on kobject creation failure [+ + +]
Author: Qasim Ijaz <[email protected]>
Date:   Fri Jun 6 19:49:57 2025 +0100

    HID: wacom: fix memory leak on kobject creation failure
    
    commit 5ae416c5b1e2e816aee7b3fc8347adf70afabb4c upstream.
    
    During wacom_initialize_remotes() a fifo buffer is allocated
    with kfifo_alloc() and later a cleanup action is registered
    during devm_add_action_or_reset() to clean it up.
    
    However if the code fails to create a kobject and register it
    with sysfs the code simply returns -ENOMEM before the cleanup
    action is registered leading to a memory leak.
    
    Fix this by ensuring the fifo is freed when the kobject creation
    and registration process fails.
    
    Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated")
    Reviewed-by: Ping Cheng <[email protected]>
    Cc: [email protected]
    Signed-off-by: Qasim Ijaz <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: wacom: fix memory leak on sysfs attribute creation failure [+ + +]
Author: Qasim Ijaz <[email protected]>
Date:   Fri Jun 6 19:49:58 2025 +0100

    HID: wacom: fix memory leak on sysfs attribute creation failure
    
    commit 1a19ae437ca5d5c7d9ec2678946fb339b1c706bf upstream.
    
    When sysfs_create_files() fails during wacom_initialize_remotes() the
    fifo buffer is not freed leading to a memory leak.
    
    Fix this by calling kfifo_free() before returning.
    
    Fixes: 83e6b40e2de6 ("HID: wacom: EKR: have the wacom resources dynamically allocated")
    Reviewed-by: Ping Cheng <[email protected]>
    Cc: [email protected]
    Signed-off-by: Qasim Ijaz <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
hwmon: (pmbus/max34440) Fix support for max34451 [+ + +]
Author: Alexis Czezar Torreno <[email protected]>
Date:   Mon Apr 7 11:47:24 2025 +0800

    hwmon: (pmbus/max34440) Fix support for max34451
    
    [ Upstream commit 19932f844f3f51646f762f3eac4744ec3a405064 ]
    
    The max344** family has an issue with some PMBUS address being switched.
    This includes max34451 however version MAX34451-NA6 and later has this
    issue fixed and this commit supports that update.
    
    Signed-off-by: Alexis Czezar Torreno <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
i2c/designware: Fix an initialization issue [+ + +]
Author: Michael J. Ruhl <[email protected]>
Date:   Fri Jun 27 10:35:11 2025 -0400

    i2c/designware: Fix an initialization issue
    
    commit 3d30048958e0d43425f6d4e76565e6249fa71050 upstream.
    
    The i2c_dw_xfer_init() function requires msgs and msg_write_idx from the
    dev context to be initialized.
    
    amd_i2c_dw_xfer_quirk() inits msgs and msgs_num, but not msg_write_idx.
    
    This could allow an out of bounds access (of msgs).
    
    Initialize msg_write_idx before calling i2c_dw_xfer_init().
    
    Reviewed-by: Andy Shevchenko <[email protected]>
    Fixes: 17631e8ca2d3 ("i2c: designware: Add driver support for AMD NAVI GPU")
    Cc: <[email protected]> # v5.13+
    Signed-off-by: Michael J. Ruhl <[email protected]>
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i2c: robotfuzz-osif: disable zero-length read messages [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Thu May 22 08:42:35 2025 +0200

    i2c: robotfuzz-osif: disable zero-length read messages
    
    commit 56ad91c1aa9c18064348edf69308080b03c9dc48 upstream.
    
    This driver passes the length of an i2c_msg directly to
    usb_control_msg(). If the message is now a read and of length 0, it
    violates the USB protocol and a warning will be printed. Enable the
    I2C_AQ_NO_ZERO_LEN_READ quirk for this adapter thus forbidding 0-length
    read messages altogether.
    
    Fixes: 83e53a8f120f ("i2c: Add bus driver for for OSIF USB i2c device.")
    Signed-off-by: Wolfram Sang <[email protected]>
    Cc: <[email protected]> # v3.14+
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i2c: tiny-usb: disable zero-length read messages [+ + +]
Author: Wolfram Sang <[email protected]>
Date:   Thu May 22 08:43:49 2025 +0200

    i2c: tiny-usb: disable zero-length read messages
    
    commit cbdb25ccf7566eee0c2b945e35cb98baf9ed0aa6 upstream.
    
    This driver passes the length of an i2c_msg directly to
    usb_control_msg(). If the message is now a read and of length 0, it
    violates the USB protocol and a warning will be printed. Enable the
    I2C_AQ_NO_ZERO_LEN_READ quirk for this adapter thus forbidding 0-length
    read messages altogether.
    
    Fixes: e8c76eed2ecd ("i2c: New i2c-tiny-usb bus driver")
    Signed-off-by: Wolfram Sang <[email protected]>
    Cc: <[email protected]> # v2.6.22+
    Signed-off-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
igc: disable L1.2 PCI-E link substate to avoid performance issue [+ + +]
Author: Vitaly Lifshits <[email protected]>
Date:   Wed Jun 11 15:52:54 2025 +0300

    igc: disable L1.2 PCI-E link substate to avoid performance issue
    
    [ Upstream commit 0325143b59c6c6d79987afc57d2456e7a20d13b7 ]
    
    I226 devices advertise support for the PCI-E link L1.2 substate. However,
    due to a hardware limitation, the exit latency from this low-power state
    is longer than the packet buffer can tolerate under high traffic
    conditions. This can lead to packet loss and degraded performance.
    
    To mitigate this, disable the L1.2 substate. The increased power draw
    between L1.1 and L1.2 is insignificant.
    
    Fixes: 43546211738e ("igc: Add new device ID's")
    Link: https://lore.kernel.org/intel-wired-lan/[email protected]
    Signed-off-by: Vitaly Lifshits <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Tested-by: Mor Bar-Gabay <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
iio: pressure: zpa2326: Use aligned_s64 for the timestamp [+ + +]
Author: Jonathan Cameron <[email protected]>
Date:   Sun Apr 13 11:34:41 2025 +0100

    iio: pressure: zpa2326: Use aligned_s64 for the timestamp
    
    [ Upstream commit 886a446b76afddfad307488e95e87f23a08ffd51 ]
    
    On x86_32 s64 fields are only 32-bit aligned.  Hence force the alignment of
    the field and padding in the structure by using aligned_s64 instead.
    
    Reviewed-by: David Lechner <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
jfs: validate AG parameters in dbMount() to prevent crashes [+ + +]
Author: Vasiliy Kovalev <[email protected]>
Date:   Mon Mar 10 11:56:02 2025 +0300

    jfs: validate AG parameters in dbMount() to prevent crashes
    
    [ Upstream commit 37bfb464ddca87f203071b5bd562cd91ddc0b40a ]
    
    Validate db_agheight, db_agwidth, and db_agstart in dbMount to catch
    corrupted metadata early and avoid undefined behavior in dbAllocAG.
    Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE:
    
    - agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift
      (L2LPERCTL - 2*agheight) >= 0.
    - agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight))
      ensures agperlev >= 1.
      - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5).
      - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG;
        2^(10 - 2*agheight) prevents division to 0.
    - agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within
      stree (size 1365).
      - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8).
    
    UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9
    shift exponent -335544310 is negative
    CPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0
    Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:94 [inline]
     dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
     ubsan_epilogue lib/ubsan.c:231 [inline]
     __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468
     dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400
     dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613
     jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105
     jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:906 [inline]
     __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892
     do_syscall_x64 arch/x86/entry/common.c:52 [inline]
     do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Cc: [email protected]
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=fe8264911355151c487f
    Signed-off-by: Vasiliy Kovalev <[email protected]>
    Signed-off-by: Dave Kleikamp <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension [+ + +]
Author: Namjae Jeon <[email protected]>
Date:   Tue May 27 11:23:01 2025 +0900

    ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension
    
    [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ]
    
    If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename
    to contain special characters.
    
    Reported-by: Philipp Kerling <[email protected]>
    Signed-off-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KVM: SVM: Advertise TSA CPUID bits to guests [+ + +]
Author: Borislav Petkov (AMD) <[email protected]>
Date:   Wed Sep 11 11:00:50 2024 +0200

    KVM: SVM: Advertise TSA CPUID bits to guests
    
    Commit 31272abd5974b38ba312e9cf2ec2f09f9dd7dcba upstream.
    
    Synthesize the TSA CPUID feature bits for guests. Set TSA_{SQ,L1}_NO on
    unaffected machines.
    
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: add support for CPUID leaf 0x80000021 [+ + +]
Author: Paolo Bonzini <[email protected]>
Date:   Thu Oct 28 13:26:38 2021 -0400

    KVM: x86: add support for CPUID leaf 0x80000021
    
    Commit 58b3d12c0a860cda34ed9d2378078ea5134e6812 upstream.
    
    CPUID leaf 0x80000021 defines some features (or lack of bugs) of AMD
    processors.  Expose the ones that make sense via KVM_GET_SUPPORTED_CPUID.
    
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
leds: multicolor: Fix intensity setting while SW blinking [+ + +]
Author: Sven Schwermer <[email protected]>
Date:   Fri Apr 4 20:40:36 2025 +0200

    leds: multicolor: Fix intensity setting while SW blinking
    
    [ Upstream commit e35ca991a777ef513040cbb36bc8245a031a2633 ]
    
    When writing to the multi_intensity file, don't unconditionally call
    led_set_brightness. By only doing this if blinking is inactive we
    prevent blinking from stopping if the blinking is in its off phase while
    the file is written.
    
    Instead, if blinking is active, the changed intensity values are applied
    upon the next blink. This is consistent with changing the brightness on
    monochrome LEDs with active blinking.
    
    Suggested-by: Jacek Anaszewski <[email protected]>
    Acked-by: Jacek Anaszewski <[email protected]>
    Acked-by: Pavel Machek <[email protected]>
    Reviewed-by: Tobias Deiminger <[email protected]>
    Tested-by: Sven Schuchmann <[email protected]>
    Signed-off-by: Sven Schwermer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
lib: test_objagg: Set error message in check_expect_hints_stats() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Mon Jun 30 14:36:40 2025 -0500

    lib: test_objagg: Set error message in check_expect_hints_stats()
    
    [ Upstream commit e6ed134a4ef592fe1fd0cafac9683813b3c8f3e8 ]
    
    Smatch complains that the error message isn't set in the caller:
    
        lib/test_objagg.c:923 test_hints_case2()
        error: uninitialized symbol 'errmsg'.
    
    This static checker warning only showed up after a recent refactoring
    but the bug dates back to when the code was originally added.  This
    likely doesn't affect anything in real life.
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/r/[email protected]/
    Fixes: 0a020d416d0a ("lib: introduce initial implementation of object aggregation manager")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Ido Schimmel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
libbpf: Fix null pointer dereference in btf_dump__free on allocation failure [+ + +]
Author: Yuan Chen <[email protected]>
Date:   Wed Jun 18 09:19:33 2025 +0800

    libbpf: Fix null pointer dereference in btf_dump__free on allocation failure
    
    [ Upstream commit aa485e8789d56a4573f7c8d000a182b749eaa64d ]
    
    When btf_dump__new() fails to allocate memory for the internal hashmap
    (btf_dump->type_names), it returns an error code. However, the cleanup
    function btf_dump__free() does not check if btf_dump->type_names is NULL
    before attempting to free it. This leads to a null pointer dereference
    when btf_dump__free() is called on a btf_dump object.
    
    Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion")
    Signed-off-by: Yuan Chen <[email protected]>
    Signed-off-by: Andrii Nakryiko <[email protected]>
    Link: https://lore.kernel.org/bpf/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 5.15.187 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Jul 10 15:57:51 2025 +0200

    Linux 5.15.187
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Shuah Khan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Linux: Logitech C-270 even more broken [+ + +]
Author: Oliver Neukum <[email protected]>
Date:   Thu Jun 5 14:28:45 2025 +0200

    Logitech C-270 even more broken
    
    commit cee4392a57e14a799fbdee193bc4c0de65b29521 upstream.
    
    Some varieties of this device don't work with
    RESET_RESUME alone.
    
    Signed-off-by: Oliver Neukum <[email protected]>
    Cc: stable <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mailbox: Not protect module_put with spin_lock_irqsave [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Apr 11 21:14:10 2025 +0800

    mailbox: Not protect module_put with spin_lock_irqsave
    
    [ Upstream commit dddbd233e67e792bb0a3f9694a4707e6be29b2c6 ]
    
    &chan->lock is not supposed to protect 'chan->mbox'.
    And in __mbox_bind_client, try_module_get is also not protected
    by &chan->lock. So move module_put out of the lock protected
    region.
    
    Signed-off-by: Peng Fan <[email protected]>
    Signed-off-by: Jassi Brar <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
md/md-bitmap: fix dm-raid max_write_behind setting [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Sat May 24 14:13:10 2025 +0800

    md/md-bitmap: fix dm-raid max_write_behind setting
    
    [ Upstream commit 2afe17794cfed5f80295b1b9facd66e6f65e5002 ]
    
    It's supposed to be COUNTER_MAX / 2, not COUNTER_MAX.
    
    Link: https://lore.kernel.org/linux-raid/[email protected]
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Hannes Reinecke <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
media: davinci: vpif: Fix memory leak in probe error path [+ + +]
Author: Dmitry Nikiforov <[email protected]>
Date:   Wed Apr 16 23:51:19 2025 +0300

    media: davinci: vpif: Fix memory leak in probe error path
    
    [ Upstream commit 024bf40edf1155e7a587f0ec46294049777d9b02 ]
    
    If an error occurs during the initialization of `pdev_display`,
    the allocated platform device `pdev_capture` is not released properly,
    leading to a memory leak.
    
    Adjust error path handling to fix the leak.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 43acb728bbc4 ("media: davinci: vpif: fix use-after-free on driver unbind")
    Cc: [email protected]
    Signed-off-by: Dmitry Nikiforov <[email protected]>
    Reviewed-by: Johan Hovold <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: imx-jpeg: Drop the first error frames [+ + +]
Author: Ming Qian <[email protected]>
Date:   Mon Apr 21 15:06:12 2025 +0800

    media: imx-jpeg: Drop the first error frames
    
    [ Upstream commit d52b9b7e2f10d22a49468128540533e8d76910cd ]
    
    When an output buffer contains error frame header,
    v4l2_jpeg_parse_header() will return error, then driver will mark this
    buffer and a capture buffer done with error flag in device_run().
    
    But if the error occurs in the first frames, before setup the capture
    queue, there is no chance to schedule device_run(), and there may be no
    capture to mark error.
    
    So we need to drop this buffer with error flag, and make the decoding
    can continue.
    
    Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder")
    Cc: [email protected]
    Signed-off-by: Ming Qian <[email protected]>
    Reviewed-by: Nicolas Dufresne <[email protected]>
    Signed-off-by: Nicolas Dufresne <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: omap3isp: use sgtable-based scatterlist wrappers [+ + +]
Author: Marek Szyprowski <[email protected]>
Date:   Wed May 7 18:09:13 2025 +0200

    media: omap3isp: use sgtable-based scatterlist wrappers
    
    [ Upstream commit 3de572fe2189a4a0bd80295e1f478401e739498e ]
    
    Use common wrappers operating directly on the struct sg_table objects to
    fix incorrect use of scatterlists sync calls. dma_sync_sg_for_*()
    functions have to be called with the number of elements originally passed
    to dma_map_sg_*() function, not the one returned in sgtable's nents.
    
    Fixes: d33186d0be18 ("[media] omap3isp: ccdc: Use the DMA API for LSC")
    Fixes: 0e24e90f2ca7 ("[media] omap3isp: stat: Use the DMA API")
    CC: [email protected]
    Signed-off-by: Marek Szyprowski <[email protected]>
    Reviewed-by: Laurent Pinchart <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: uvcvideo: Rollback non processed entities on error [+ + +]
Author: Ricardo Ribalda <[email protected]>
Date:   Mon Feb 24 10:34:55 2025 +0000

    media: uvcvideo: Rollback non processed entities on error
    
    commit a70705d3c020d0d5c3ab6a5cc93e011ac35e7d48 upstream.
    
    If we fail to commit an entity, we need to restore the
    UVC_CTRL_DATA_BACKUP for the other uncommitted entities. Otherwise the
    control cache and the device would be out of sync.
    
    Cc: [email protected]
    Fixes: b4012002f3a3 ("[media] uvcvideo: Add support for control events")
    Reported-by: Hans de Goede <[email protected]>
    Closes: https://lore.kernel.org/linux-media/[email protected]/
    Signed-off-by: Ricardo Ribalda <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Ricardo Ribalda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mfd: max14577: Fix wakeup source leaks on device unbind [+ + +]
Author: Krzysztof Kozlowski <[email protected]>
Date:   Sun Apr 6 21:50:11 2025 +0200

    mfd: max14577: Fix wakeup source leaks on device unbind
    
    [ Upstream commit d905d06e64b0eb3da43af6186c132f5282197998 ]
    
    Device can be unbound, so driver must also release memory for the wakeup
    source.
    
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mmc: core: sd: Apply BROKEN_SD_DISCARD quirk earlier [+ + +]
Author: Avri Altman <[email protected]>
Date:   Mon May 26 14:44:45 2025 +0300

    mmc: core: sd: Apply BROKEN_SD_DISCARD quirk earlier
    
    [ Upstream commit 009c3a4bc41e855fd76f92727f9fbae4e5917d7f ]
    
    Move the BROKEN_SD_DISCARD quirk for certain SanDisk SD cards from the
    `mmc_blk_fixups[]` to `mmc_sd_fixups[]`. This ensures the quirk is
    applied earlier in the device initialization process, aligning with the
    reasoning in [1]. Applying the quirk sooner prevents the kernel from
    incorrectly enabling discard support on affected cards during initial
    setup.
    
    [1] https://lore.kernel.org/all/[email protected]
    
    Fixes: 07d2872bf4c8 ("mmc: core: Add SD card quirk for broken discard")
    Signed-off-by: Avri Altman <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mmc: sdhci: Add a helper function for dump register in dynamic debug mode [+ + +]
Author: Victor Shih <[email protected]>
Date:   Fri Jun 6 19:01:20 2025 +0800

    mmc: sdhci: Add a helper function for dump register in dynamic debug mode
    
    commit 2881ba9af073faa8ee7408a8d1e0575e50eb3f6c upstream.
    
    Add a helper function for dump register in dynamic debug mode.
    
    Signed-off-by: Victor Shih <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mtd: spinand: fix memory leak of ECC engine conf [+ + +]
Author: Pablo Martin-Gomez <[email protected]>
Date:   Wed Jun 18 13:35:16 2025 +0200

    mtd: spinand: fix memory leak of ECC engine conf
    
    [ Upstream commit 6463cbe08b0cbf9bba8763306764f5fd643023e1 ]
    
    Memory allocated for the ECC engine conf is not released during spinand
    cleanup. Below kmemleak trace is seen for this memory leak:
    
    unreferenced object 0xffffff80064f00e0 (size 8):
      comm "swapper/0", pid 1, jiffies 4294937458
      hex dump (first 8 bytes):
        00 00 00 00 00 00 00 00                          ........
      backtrace (crc 0):
        kmemleak_alloc+0x30/0x40
        __kmalloc_cache_noprof+0x208/0x3c0
        spinand_ondie_ecc_init_ctx+0x114/0x200
        nand_ecc_init_ctx+0x70/0xa8
        nanddev_ecc_engine_init+0xec/0x27c
        spinand_probe+0xa2c/0x1620
        spi_mem_probe+0x130/0x21c
        spi_probe+0xf0/0x170
        really_probe+0x17c/0x6e8
        __driver_probe_device+0x17c/0x21c
        driver_probe_device+0x58/0x180
        __device_attach_driver+0x15c/0x1f8
        bus_for_each_drv+0xec/0x150
        __device_attach+0x188/0x24c
        device_initial_probe+0x10/0x20
        bus_probe_device+0x11c/0x160
    
    Fix the leak by calling nanddev_ecc_engine_cleanup() inside
    spinand_cleanup().
    
    Signed-off-by: Pablo Martin-Gomez <[email protected]>
    Signed-off-by: Miquel Raynal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mtk-sd: Fix a pagefault in dma_unmap_sg() for not prepared data [+ + +]
Author: Masami Hiramatsu (Google) <[email protected]>
Date:   Thu Jun 5 10:07:38 2025 +0900

    mtk-sd: Fix a pagefault in dma_unmap_sg() for not prepared data
    
    commit 539d80575b810c7a5987c7ac8915e3bc99c03695 upstream.
    
    When swiotlb buffer is full, the dma_map_sg() returns 0 to
    msdc_prepare_data(), but it does not check it and sets the
    MSDC_PREPARE_FLAG.
    
    swiotlb_tbl_map_single() /* prints "swiotlb buffer is full" */
      <-swiotlb_map()
        <-dma_direct_map_page()
          <-dma_direct_map_sg()
            <-__dma_map_sg_attrs()
              <-dma_map_sg_attrs()
                <-dma_map_sg()  /* returns 0 (pages mapped) */
                  <-msdc_prepare_data()
    
    Then, the msdc_unprepare_data() checks MSDC_PREPARE_FLAG and calls
    dma_unmap_sg() with unmapped pages. It causes a page fault.
    
    To fix this problem, Do not set MSDC_PREPARE_FLAG if dma_map_sg()
    fails because this is not prepared.
    
    Fixes: 208489032bdd ("mmc: mediatek: Add Mediatek MMC driver")
    Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
    Tested-by: Sergey Senozhatsky <[email protected]>
    Reviewed-by: AngeloGioacchino Del Regno <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/174908565814.4056588.769599127120955383.stgit@mhiramat.tok.corp.google.com
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mtk-sd: Prevent memory corruption from DMA map failure [+ + +]
Author: Masami Hiramatsu (Google) <[email protected]>
Date:   Thu Jun 12 20:26:10 2025 +0900

    mtk-sd: Prevent memory corruption from DMA map failure
    
    commit f5de469990f19569627ea0dd56536ff5a13beaa3 upstream.
    
    If msdc_prepare_data() fails to map the DMA region, the request is
    not prepared for data receiving, but msdc_start_data() proceeds
    the DMA with previous setting.
    Since this will lead a memory corruption, we have to stop the
    request operation soon after the msdc_prepare_data() fails to
    prepare it.
    
    Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
    Fixes: 208489032bdd ("mmc: mediatek: Add Mediatek MMC driver")
    Cc: [email protected]
    Link: https://lore.kernel.org/r/174972756982.3337526.6755001617701603082.stgit@mhiramat.tok.corp.google.com
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mtk-sd: reset host->mrq on prepare_data() error [+ + +]
Author: Sergey Senozhatsky <[email protected]>
Date:   Wed Jun 25 14:20:37 2025 +0900

    mtk-sd: reset host->mrq on prepare_data() error
    
    commit ec54c0a20709ed6e56f40a8d59eee725c31a916b upstream.
    
    Do not leave host with dangling ->mrq pointer if we hit
    the msdc_prepare_data() error out path.
    
    Signed-off-by: Sergey Senozhatsky <[email protected]>
    Reviewed-by: Masami Hiramatsu (Google) <[email protected]>
    Fixes: f5de469990f1 ("mtk-sd: Prevent memory corruption from DMA map failure")
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net/sched: Always pass notifications when child class becomes empty [+ + +]
Author: Lion Ackermann <[email protected]>
Date:   Mon Jun 30 15:27:30 2025 +0200

    net/sched: Always pass notifications when child class becomes empty
    
    [ Upstream commit 103406b38c600fec1fe375a77b27d87e314aea09 ]
    
    Certain classful qdiscs may invoke their classes' dequeue handler on an
    enqueue operation. This may unexpectedly empty the child qdisc and thus
    make an in-flight class passive via qlen_notify(). Most qdiscs do not
    expect such behaviour at this point in time and may re-activate the
    class eventually anyways which will lead to a use-after-free.
    
    The referenced fix commit attempted to fix this behavior for the HFSC
    case by moving the backlog accounting around, though this turned out to
    be incomplete since the parent's parent may run into the issue too.
    The following reproducer demonstrates this use-after-free:
    
        tc qdisc add dev lo root handle 1: drr
        tc filter add dev lo parent 1: basic classid 1:1
        tc class add dev lo parent 1: classid 1:1 drr
        tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
        tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
        tc qdisc add dev lo parent 2:1 handle 3: netem
        tc qdisc add dev lo parent 3:1 handle 4: blackhole
    
        echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
        tc class delete dev lo classid 1:1
        echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
    
    Since backlog accounting issues leading to a use-after-frees on stale
    class pointers is a recurring pattern at this point, this patch takes
    a different approach. Instead of trying to fix the accounting, the patch
    ensures that qdisc_tree_reduce_backlog always calls qlen_notify when
    the child qdisc is empty. This solves the problem because deletion of
    qdiscs always involves a call to qdisc_reset() and / or
    qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing
    the following qdisc_tree_reduce_backlog() to report to the parent. Note
    that this may call qlen_notify on passive classes multiple times. This
    is not a problem after the recent patch series that made all the
    classful qdiscs qlen_notify() handlers idempotent.
    
    Fixes: 3f981138109f ("sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()")
    Signed-off-by: Lion Ackermann <[email protected]>
    Reviewed-by: Jamal Hadi Salim <[email protected]>
    Acked-by: Cong Wang <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: dpaa2-eth: rearrange variable in dpaa2_eth_get_ethtool_stats [+ + +]
Author: Ioana Ciornei <[email protected]>
Date:   Tue Oct 18 17:18:51 2022 +0300

    net: dpaa2-eth: rearrange variable in dpaa2_eth_get_ethtool_stats
    
    [ Upstream commit 3313206827678f6f036eca601a51f6c4524b559a ]
    
    Rearrange the variables in the dpaa2_eth_get_ethtool_stats() function so
    that we adhere to the reverse Christmas tree rule.
    Also, in the next patch we are adding more variables and I didn't know
    where to place them with the current ordering.
    
    Signed-off-by: Ioana Ciornei <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: 2def09ead4ad ("dpaa2-eth: fix xdp_rxq_info leak")
    Signed-off-by: Sasha Levin <[email protected]>

net: enetc: Correct endianness handling in _enetc_rd_reg64 [+ + +]
Author: Simon Horman <[email protected]>
Date:   Tue Jun 24 17:35:12 2025 +0100

    net: enetc: Correct endianness handling in _enetc_rd_reg64
    
    [ Upstream commit 7b515f35a911fdc31fbde6531828dcd6ae9803d3 ]
    
    enetc_hw.h provides two versions of _enetc_rd_reg64.
    One which simply calls ioread64() when available.
    And another that composes the 64-bit result from ioread32() calls.
    
    In the second case the code appears to assume that each ioread32() call
    returns a little-endian value. However both the shift and logical or
    used to compose the return value would not work correctly on big endian
    systems if this were the case. Moreover, this is inconsistent with the
    first case where the return value of ioread64() is assumed to be in host
    byte order.
    
    It appears that the correct approach is for both versions to treat the
    return value of ioread*() functions as being in host byte order. And
    this patch corrects the ioread32()-based version to do so.
    
    This is a bug but would only manifest on big endian systems
    that make use of the ioread32-based implementation of _enetc_rd_reg64.
    While all in-tree users of this driver are little endian and
    make use of the ioread64-based implementation of _enetc_rd_reg64.
    Thus, no in-tree user of this driver is affected by this bug.
    
    Flagged by Sparse.
    Compile tested only.
    
    Fixes: 16eb4c85c964 ("enetc: Add ethtool statistics")
    Closes: https://lore.kernel.org/all/AM9PR04MB850500D3FC24FE23DEFCEA158879A@AM9PR04MB8505.eurprd04.prod.outlook.com/
    Signed-off-by: Simon Horman <[email protected]>
    Reviewed-by: Wei Fang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: selftests: fix TCP packet checksum [+ + +]
Author: Jakub Kicinski <[email protected]>
Date:   Tue Jun 24 11:32:58 2025 -0700

    net: selftests: fix TCP packet checksum
    
    [ Upstream commit 8d89661a36dd3bb8c9902cff36dc0c144dce3faf ]
    
    The length in the pseudo header should be the length of the L3 payload
    AKA the L4 header+payload. The selftest code builds the packet from
    the lower layers up, so all the headers are pushed already when it
    constructs L4. We need to subtract the lower layer headers from skb->len.
    
    Fixes: 3e1e58d64c3d ("net: add generic selftest support")
    Signed-off-by: Jakub Kicinski <[email protected]>
    Reviewed-by: Gerhard Engleder <[email protected]>
    Reported-by: Oleksij Rempel <[email protected]>
    Tested-by: Oleksij Rempel <[email protected]>
    Reviewed-by: Oleksij Rempel <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Thu Jun 12 14:52:50 2025 -0700

    nfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.
    
    [ Upstream commit e8d6f3ab59468e230f3253efe5cb63efa35289f7 ]
    
    syzbot reported a warning below [1] following a fault injection in
    nfs_fs_proc_net_init(). [0]
    
    When nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed.
    
    Later, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning
    is logged as the directory is not empty.
    
    Let's handle the error of nfs_fs_proc_net_init() properly.
    
    [0]:
    FAULT_INJECTION: forcing a failure.
    name failslab, interval 1, probability 0, space 0, times 0
    CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
    Call Trace:
     <TASK>
      dump_stack_lvl (lib/dump_stack.c:123)
     should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174)
     should_failslab (mm/failslab.c:46)
     kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204)
     __proc_create (fs/proc/generic.c:427)
     proc_create_reg (fs/proc/generic.c:554)
     proc_create_net_data (fs/proc/proc_net.c:120)
     nfs_fs_proc_net_init (fs/nfs/client.c:1409)
     nfs_net_init (fs/nfs/inode.c:2600)
     ops_init (net/core/net_namespace.c:138)
     setup_net (net/core/net_namespace.c:443)
     copy_net_ns (net/core/net_namespace.c:576)
     create_new_namespaces (kernel/nsproxy.c:110)
     unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4))
     ksys_unshare (kernel/fork.c:3123)
     __x64_sys_unshare (kernel/fork.c:3190)
     do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
     </TASK>
    
    [1]:
    remove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs'
     WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727
    Modules linked in:
    CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
     RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727
    Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00
    RSP: 0018:ffffc90003637b08 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8
    RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001
    RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00
    R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000
    FS:  0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
      sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76
      ops_exit_list net/core/net_namespace.c:200 [inline]
      ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253
      setup_net+0x2e1/0x510 net/core/net_namespace.c:457
      copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574
      create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110
      unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218
      ksys_unshare+0x45b/0xa40 kernel/fork.c:3121
      __do_sys_unshare kernel/fork.c:3192 [inline]
      __se_sys_unshare kernel/fork.c:3190 [inline]
      __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190
      do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
      do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7fa1a6b8e929
    Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fff3a090368 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
    RAX: ffffffffffffffda RBX: 00007fa1a6db5fa0 RCX: 00007fa1a6b8e929
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000080
    RBP: 00007fa1a6c10b39 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fa1a6db5fa0 R14: 00007fa1a6db5fa0 R15: 0000000000000001
     </TASK>
    
    Fixes: d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs in net namespaces")
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=a4cc4ac22daa4a71b87c
    Tested-by: [email protected]
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.2: fix listxattr to return selinux security label [+ + +]
Author: Olga Kornievskaia <[email protected]>
Date:   Fri Apr 25 14:09:21 2025 -0400

    NFSv4.2: fix listxattr to return selinux security label
    
    [ Upstream commit 243fea134633ba3d64aceb4c16129c59541ea2c6 ]
    
    Currently, when NFS is queried for all the labels present on the
    file via a command example "getfattr -d -m . /mnt/testfile", it
    does not return the security label. Yet when asked specifically for
    the label (getfattr -n security.selinux) it will be returned.
    Include the security label when all attributes are queried.
    
    Signed-off-by: Olga Kornievskaia <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4/flexfiles: Fix handling of NFS level errors in I/O [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Thu Jun 19 15:16:11 2025 -0400

    NFSv4/flexfiles: Fix handling of NFS level errors in I/O
    
    [ Upstream commit 38074de35b015df5623f524d6f2b49a0cd395c40 ]
    
    Allow the flexfiles error handling to recognise NFS level errors (as
    opposed to RPC level errors) and handle them separately. The main
    motivator is the NFSERR_PERM errors that get returned if the NFS client
    connects to the data server through a port number that is lower than
    1024. In that case, the client should disconnect and retry a READ on a
    different data server, or it should retry a WRITE after reconnecting.
    
    Reviewed-by: Tigran Mkrtchyan <[email protected]>
    Fixes: d67ae825a59d ("pnfs/flexfiles: Add the FlexFile Layout Driver")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN [+ + +]
Author: Benjamin Coddington <[email protected]>
Date:   Thu Jun 19 11:02:21 2025 -0400

    NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN
    
    [ Upstream commit c01776287414ca43412d1319d2877cbad65444ac ]
    
    We found a few different systems hung up in writeback waiting on the same
    page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in
    pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count
    was zero.
    
    It seems most likely that this is another race between the waiter and waker
    similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task").
    Fix it up by applying the advised barrier.
    
    Fixes: 880265c77ac4 ("pNFS: Avoid a live lock condition in pnfs_update_layout()")
    Signed-off-by: Benjamin Coddington <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4: Always set NLINK even if the server doesn't support it [+ + +]
Author: Han Young <[email protected]>
Date:   Sun May 4 20:57:04 2025 +0800

    NFSv4: Always set NLINK even if the server doesn't support it
    
    [ Upstream commit 3a3065352f73381d3a1aa0ccab44aec3a5a9b365 ]
    
    fattr4_numlinks is a recommended attribute, so the client should emulate
    it even if the server doesn't support it. In decode_attr_nlink function
    in nfs4xdr.c, nlink is initialized to 1. However, this default value
    isn't set to the inode due to the check in nfs_fhget.
    
    So if the server doesn't support numlinks, inode's nlink will be zero,
    the mount will fail with error "Stale file handle". Set the nlink to 1
    if the server doesn't support it.
    
    Signed-off-by: Han Young <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nui: Fix dma_mapping_error() check [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Mon Jun 30 10:36:43 2025 +0200

    nui: Fix dma_mapping_error() check
    
    [ Upstream commit 561aa0e22b70a5e7246b73d62a824b3aef3fc375 ]
    
    dma_map_XXX() functions return values DMA_MAPPING_ERROR as error values
    which is often ~0.  The error value should be tested with
    dma_mapping_error().
    
    This patch creates a new function in niu_ops to test if the mapping
    failed.  The test is fixed in niu_rbr_add_page(), added in
    niu_start_xmit() and the successfully mapped pages are unmaped upon error.
    
    Fixes: ec2deec1f352 ("niu: Fix to check for dma mapping errors.")
    Signed-off-by: Thomas Fourier <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ovl: Check for NULL d_inode() in ovl_dentry_upper() [+ + +]
Author: Kees Cook <[email protected]>
Date:   Mon Apr 21 16:15:19 2025 -0700

    ovl: Check for NULL d_inode() in ovl_dentry_upper()
    
    [ Upstream commit 8a39f1c870e9d6fbac5638f3a42a6a6363829c49 ]
    
    In ovl_path_type() and ovl_is_metacopy_dentry() GCC notices that it is
    possible for OVL_E() to return NULL (which implies that d_inode(dentry)
    may be NULL). This would result in out of bounds reads via container_of(),
    seen with GCC 15's -Warray-bounds -fdiagnostics-details. For example:
    
    In file included from arch/x86/include/generated/asm/rwonce.h:1,
                     from include/linux/compiler.h:339,
                     from include/linux/export.h:5,
                     from include/linux/linkage.h:7,
                     from include/linux/fs.h:5,
                     from fs/overlayfs/util.c:7:
    In function 'ovl_upperdentry_dereference',
        inlined from 'ovl_dentry_upper' at ../fs/overlayfs/util.c:305:9,
        inlined from 'ovl_path_type' at ../fs/overlayfs/util.c:216:6:
    include/asm-generic/rwonce.h:44:26: error: array subscript 0 is outside array bounds of 'struct inode[7486503276667837]' [-Werror=array-bounds=]
       44 | #define __READ_ONCE(x)  (*(const volatile __unqual_scalar_typeof(x) *)&(x))
          |                         ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    include/asm-generic/rwonce.h:50:9: note: in expansion of macro '__READ_ONCE'
       50 |         __READ_ONCE(x);                                                 \
          |         ^~~~~~~~~~~
    fs/overlayfs/ovl_entry.h:195:16: note: in expansion of macro 'READ_ONCE'
      195 |         return READ_ONCE(oi->__upperdentry);
          |                ^~~~~~~~~
      'ovl_path_type': event 1
      185 |         return inode ? OVL_I(inode)->oe : NULL;
      'ovl_path_type': event 2
    
    Avoid this by allowing ovl_dentry_upper() to return NULL if d_inode() is
    NULL, as that means the problematic dereferencing can never be reached.
    Note that this fixes the over-eager compiler warning in an effort to
    being able to enable -Warray-bounds globally. There is no known
    behavioral bug here.
    
    Suggested-by: Amir Goldstein <[email protected]>
    Signed-off-by: Kees Cook <[email protected]>
    Signed-off-by: Miklos Szeredi <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
PCI: hv: Do not set PCI_COMMAND_MEMORY to reduce VM boot time [+ + +]
Author: Dexuan Cui <[email protected]>
Date:   Mon May 2 00:42:55 2022 -0700

    PCI: hv: Do not set PCI_COMMAND_MEMORY to reduce VM boot time
    
    commit 23e118a48acf7be223e57d98e98da8ac5a4071ac upstream.
    
    Currently when the pci-hyperv driver finishes probing and initializing the
    PCI device, it sets the PCI_COMMAND_MEMORY bit; later when the PCI device
    is registered to the core PCI subsystem, the core PCI driver's BAR detection
    and initialization code toggles the bit multiple times, and each toggling of
    the bit causes the hypervisor to unmap/map the virtual BARs from/to the
    physical BARs, which can be slow if the BAR sizes are huge, e.g., a Linux VM
    with 14 GPU devices has to spend more than 3 minutes on BAR detection and
    initialization, causing a long boot time.
    
    Reduce the boot time by not setting the PCI_COMMAND_MEMORY bit when we
    register the PCI device (there is no need to have it set in the first place).
    The bit stays off till the PCI device driver calls pci_enable_device().
    With this change, the boot time of such a 14-GPU VM is reduced by almost
    3 minutes.
    
    Link: https://lore.kernel.org/lkml/[email protected]/
    Tested-by: Boqun Feng (Microsoft) <[email protected]>
    Signed-off-by: Dexuan Cui <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Acked-by: Lorenzo Pieralisi <[email protected]>
    Cc: Jake Oshins <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
platform/mellanox: mlxbf-tmfifo: fix vring_desc.len assignment [+ + +]
Author: David Thompson <[email protected]>
Date:   Fri Jun 13 21:46:08 2025 +0000

    platform/mellanox: mlxbf-tmfifo: fix vring_desc.len assignment
    
    [ Upstream commit 109f4d29dade8ae5b4ac6325af9d1bc24b4230f8 ]
    
    Fix warnings reported by sparse, related to incorrect type:
    drivers/platform/mellanox/mlxbf-tmfifo.c:284:38: warning: incorrect type in assignment (different base types)
    drivers/platform/mellanox/mlxbf-tmfifo.c:284:38:    expected restricted __virtio32 [usertype] len
    drivers/platform/mellanox/mlxbf-tmfifo.c:284:38:    got unsigned long
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Fixes: 78034cbece79 ("platform/mellanox: mlxbf-tmfifo: Drop the Rx packet if no more descriptors")
    Signed-off-by: David Thompson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
platform/x86: dell-wmi-sysman: Fix class device unregistration [+ + +]
Author: Kurt Borja <[email protected]>
Date:   Mon Jul 7 15:14:51 2025 -0400

    platform/x86: dell-wmi-sysman: Fix class device unregistration
    
    [ Upstream commit 314e5ad4782d08858b3abc325c0487bd2abc23a1 ]
    
    Devices under the firmware_attributes_class do not have unique a dev_t.
    Therefore, device_unregister() should be used instead of
    device_destroy(), since the latter may match any device with a given
    dev_t.
    
    Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
    Signed-off-by: Kurt Borja <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks [+ + +]
Author: Kurt Borja <[email protected]>
Date:   Mon Jun 30 00:43:12 2025 -0300

    platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks
    
    [ Upstream commit eb617dd25ca176f3fee24f873f0fd60010773d67 ]
    
    After retrieving WMI data blocks in sysfs callbacks, check for the
    validity of them before dereferencing their content.
    
    Reported-by: Jan Graczyk <[email protected]>
    Closes: https://lore.kernel.org/r/CAHk-=wgMiSKXf7SvQrfEnxVtmT=QVQPjJdNjfm3aXS7wc=rzTw@mail.gmail.com/
    Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
    Suggested-by: Linus Torvalds <[email protected]>
    Reviewed-by: Armin Wolf <[email protected]>
    Signed-off-by: Kurt Borja <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

platform/x86: ideapad-laptop: use usleep_range() for EC polling [+ + +]
Author: Rong Zhang <[email protected]>
Date:   Mon May 26 04:18:07 2025 +0800

    platform/x86: ideapad-laptop: use usleep_range() for EC polling
    
    [ Upstream commit 5808c34216954cd832bd4b8bc52dfa287049122b ]
    
    It was reported that ideapad-laptop sometimes causes some recent (since
    2024) Lenovo ThinkBook models shut down when:
     - suspending/resuming
     - closing/opening the lid
     - (dis)connecting a charger
     - reading/writing some sysfs properties, e.g., fan_mode, touchpad
     - pressing down some Fn keys, e.g., Brightness Up/Down (Fn+F5/F6)
     - (seldom) loading the kmod
    
    The issue has existed since the launch day of such models, and there
    have been some out-of-tree workarounds (see Link:) for the issue. One
    disables some functionalities, while another one simply shortens
    IDEAPAD_EC_TIMEOUT. The disabled functionalities have read_ec_data() in
    their call chains, which calls schedule() between each poll.
    
    It turns out that these models suffer from the indeterminacy of
    schedule() because of their low tolerance for being polled too
    frequently. Sometimes schedule() returns too soon due to the lack of
    ready tasks, causing the margin between two polls to be too short.
    In this case, the command is somehow aborted, and too many subsequent
    polls (they poll for "nothing!") may eventually break the state machine
    in the EC, resulting in a hard shutdown. This explains why shortening
    IDEAPAD_EC_TIMEOUT works around the issue - it reduces the total number
    of polls sent to the EC.
    
    Even when it doesn't lead to a shutdown, frequent polls may also disturb
    the ongoing operation and notably delay (+ 10-20ms) the availability of
    EC response. This phenomenon is unlikely to be exclusive to the models
    mentioned above, so dropping the schedule() manner should also slightly
    improve the responsiveness of various models.
    
    Fix these issues by migrating to usleep_range(150, 300). The interval is
    chosen to add some margin to the minimal 50us and considering EC
    responses are usually available after 150-2500us based on my test. It
    should be enough to fix these issues on all models subject to the EC bug
    without introducing latency on other models.
    
    Tested on ThinkBook 14 G7+ ASP and solved both issues. No regression was
    introduced in the test on a model without the EC bug (ThinkBook X IMH,
    thanks Eric).
    
    Link: https://github.com/ty2/ideapad-laptop-tb2024g6plus/commit/6c5db18c9e8109873c2c90a7d2d7f552148f7ad4
    Link: https://github.com/ferstar/ideapad-laptop-tb/commit/42d1e68e5009529d31bd23f978f636f79c023e80
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218771
    Fixes: 6a09f21dd1e2 ("ideapad: add ACPI helpers")
    Cc: [email protected]
    Tested-by: Felix Yan <[email protected]>
    Tested-by: Eric Long <[email protected]>
    Tested-by: Jianfei Zhang <[email protected]>
    Tested-by: Mingcong Bai <[email protected]>
    Tested-by: Minh Le <[email protected]>
    Tested-by: Sicheng Zhu <[email protected]>
    Signed-off-by: Rong Zhang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

platform/x86: think-lmi: Create ksets consecutively [+ + +]
Author: Kurt Borja <[email protected]>
Date:   Mon Jun 30 14:31:19 2025 -0300

    platform/x86: think-lmi: Create ksets consecutively
    
    commit 8dab34ca77293b409c3223636dde915a22656748 upstream.
    
    Avoid entering tlmi_release_attr() in error paths if both ksets are not
    yet created.
    
    This is accomplished by initializing them side by side.
    
    Reviewed-by: Mark Pearson <[email protected]>
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Cc: [email protected]
    Signed-off-by: Kurt Borja <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

platform/x86: think-lmi: Fix class device unregistration [+ + +]
Author: Kurt Borja <[email protected]>
Date:   Wed Jun 25 22:17:36 2025 -0300

    platform/x86: think-lmi: Fix class device unregistration
    
    [ Upstream commit 5ff1fbb3059730700b4823f43999fc1315984632 ]
    
    Devices under the firmware_attributes_class do not have unique a dev_t.
    Therefore, device_unregister() should be used instead of
    device_destroy(), since the latter may match any device with a given
    dev_t.
    
    Fixes: a40cd7ef22fb ("platform/x86: think-lmi: Add WMI interface support on Lenovo platforms")
    Signed-off-by: Kurt Borja <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Ilpo Järvinen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
powerpc: Fix struct termio related ioctl macros [+ + +]
Author: Madhavan Srinivasan <[email protected]>
Date:   Sat May 17 19:52:37 2025 +0530

    powerpc: Fix struct termio related ioctl macros
    
    [ Upstream commit ab107276607af90b13a5994997e19b7b9731e251 ]
    
    Since termio interface is now obsolete, include/uapi/asm/ioctls.h
    has some constant macros referring to "struct termio", this caused
    build failure at userspace.
    
    In file included from /usr/include/asm/ioctl.h:12,
                     from /usr/include/asm/ioctls.h:5,
                     from tst-ioctls.c:3:
    tst-ioctls.c: In function 'get_TCGETA':
    tst-ioctls.c:12:10: error: invalid application of 'sizeof' to incomplete type 'struct termio'
       12 |   return TCGETA;
          |          ^~~~~~
    
    Even though termios.h provides "struct termio", trying to juggle definitions around to
    make it compile could introduce regressions. So better to open code it.
    
    Reported-by: Tulio Magno <[email protected]>
    Suggested-by: Nicholas Piggin <[email protected]>
    Tested-by: Justin M. Forbes <[email protected]>
    Reviewed-by: Michael Ellerman <[email protected]>
    Closes: https://lore.kernel.org/linuxppc-dev/[email protected]/
    Signed-off-by: Madhavan Srinivasan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
rcu: Return early if callback is not specified [+ + +]
Author: Uladzislau Rezki (Sony) <[email protected]>
Date:   Tue Jun 10 19:34:48 2025 +0200

    rcu: Return early if callback is not specified
    
    [ Upstream commit 33b6a1f155d627f5bd80c7485c598ce45428f74f ]
    
    Currently the call_rcu() API does not check whether a callback
    pointer is NULL. If NULL is passed, rcu_core() will try to invoke
    it, resulting in NULL pointer dereference and a kernel crash.
    
    To prevent this and improve debuggability, this patch adds a check
    for NULL and emits a kernel stack trace to help identify a faulty
    caller.
    
    Signed-off-by: Uladzislau Rezki (Sony) <[email protected]>
    Reviewed-by: Joel Fernandes <[email protected]>
    Signed-off-by: Joel Fernandes <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
RDMA/mlx5: Fix CC counters query for MPV [+ + +]
Author: Patrisious Haddad <[email protected]>
Date:   Mon Jun 16 12:14:53 2025 +0300

    RDMA/mlx5: Fix CC counters query for MPV
    
    [ Upstream commit acd245b1e33fc4b9d0f2e3372021d632f7ee0652 ]
    
    In case, CC counters are querying for the second port use the correct
    core device for the query instead of always using the master core device.
    
    Fixes: aac4492ef23a ("IB/mlx5: Update counter implementation for dual port RoCE")
    Signed-off-by: Patrisious Haddad <[email protected]>
    Reviewed-by: Michael Guralnik <[email protected]>
    Link: https://patch.msgid.link/9cace74dcf106116118bebfa9146d40d4166c6b0.1750064969.git.leon@kernel.org
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insert [+ + +]
Author: Mark Zhang <[email protected]>
Date:   Tue Jun 17 11:13:55 2025 +0300

    RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insert
    
    [ Upstream commit 8edab8a72d67742f87e9dc2e2b0cdfddda5dc29a ]
    
    The obj_event may be loaded immediately after inserted, then if the
    list_head is not initialized then we may get a poisonous pointer.  This
    fixes the crash below:
    
     mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced)
     mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056
     mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0
     mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps
     IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready
     Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
     Mem abort info:
       ESR = 0x96000006
       EC = 0x25: DABT (current EL), IL = 32 bits
       SET = 0, FnV = 0
       EA = 0, S1PTW = 0
     Data abort info:
       ISV = 0, ISS = 0x00000006
       CM = 0, WnR = 0
     user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000
     [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000
     Internal error: Oops: 96000006 [#1] SMP
     Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E)
      [last unloaded: mst_pci]
     CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G           OE K   5.10.134-13.1.an8.aarch64 #1
     Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023
     pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--)
     pc : dispatch_event_fd+0x68/0x300 [mlx5_ib]
     lr : devx_event_notifier+0xcc/0x228 [mlx5_ib]
     sp : ffff80001005bcf0
     x29: ffff80001005bcf0 x28: 0000000000000001
     x27: ffff244e0740a1d8 x26: ffff244e0740a1d0
     x25: ffffda56beff5ae0 x24: ffffda56bf911618
     x23: ffff244e0596a480 x22: ffff244e0596a480
     x21: ffff244d8312ad90 x20: ffff244e0596a480
     x19: fffffffffffffff0 x18: 0000000000000000
     x17: 0000000000000000 x16: ffffda56be66d620
     x15: 0000000000000000 x14: 0000000000000000
     x13: 0000000000000000 x12: 0000000000000000
     x11: 0000000000000040 x10: ffffda56bfcafb50
     x9 : ffffda5655c25f2c x8 : 0000000000000010
     x7 : 0000000000000000 x6 : ffff24545a2e24b8
     x5 : 0000000000000003 x4 : ffff80001005bd28
     x3 : 0000000000000000 x2 : 0000000000000000
     x1 : ffff244e0596a480 x0 : ffff244d8312ad90
     Call trace:
      dispatch_event_fd+0x68/0x300 [mlx5_ib]
      devx_event_notifier+0xcc/0x228 [mlx5_ib]
      atomic_notifier_call_chain+0x58/0x80
      mlx5_eq_async_int+0x148/0x2b0 [mlx5_core]
      atomic_notifier_call_chain+0x58/0x80
      irq_int_handler+0x20/0x30 [mlx5_core]
      __handle_irq_event_percpu+0x60/0x220
      handle_irq_event_percpu+0x3c/0x90
      handle_irq_event+0x58/0x158
      handle_fasteoi_irq+0xfc/0x188
      generic_handle_irq+0x34/0x48
      ...
    
    Fixes: 759738537142 ("IB/mlx5: Enable subscription for device events over DEVX")
    Link: https://patch.msgid.link/r/3ce7f20e0d1a03dc7de6e57494ec4b8eaf1f05c2.1750147949.git.leon@kernel.org
    Signed-off-by: Mark Zhang <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
regulator: gpio: Add input_supply support in gpio_regulator_config [+ + +]
Author: Jerome Neanne <[email protected]>
Date:   Thu Sep 29 15:25:25 2022 +0200

    regulator: gpio: Add input_supply support in gpio_regulator_config
    
    [ Upstream commit adfdfcbdbd32b356323a3db6d3a683270051a7e6 ]
    
    This is simillar as fixed-regulator.
    Used to extract regulator parent from the device tree.
    
    Without that property used, the parent regulator can be shut down (if not an always on).
    Thus leading to inappropriate behavior:
    On am62-SP-SK this fix is required to avoid tps65219 ldo1 (SDMMC rail) to be shut down after boot completion.
    
    Signed-off-by: Jerome Neanne <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Stable-dep-of: c9764fd88bc7 ("regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods")
    Signed-off-by: Sasha Levin <[email protected]>

regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods [+ + +]
Author: Manivannan Sadhasivam <[email protected]>
Date:   Thu Jul 3 16:05:49 2025 +0530

    regulator: gpio: Fix the out-of-bounds access to drvdata::gpiods
    
    [ Upstream commit c9764fd88bc744592b0604ccb6b6fc1a5f76b4e3 ]
    
    drvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. But
    the memory is allocated for only one pointer. This will lead to
    out-of-bounds access later in the code if 'config::ngpios' is > 1. So
    fix the code to allocate enough memory to hold 'config::ngpios' of GPIO
    descriptors.
    
    While at it, also move the check for memory allocation failure to be below
    the allocation to make it more readable.
    
    Cc: [email protected] # 5.0
    Fixes: d6cd33ad7102 ("regulator: gpio: Convert to use descriptors")
    Signed-off-by: Manivannan Sadhasivam <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Revert "ipv6: save dontfrag in cork" [+ + +]
Author: Brett A C Sheffield (Librecast) <[email protected]>
Date:   Wed Jul 2 13:38:50 2025 +0200

    Revert "ipv6: save dontfrag in cork"
    
    This reverts commit 2b572c40981138349c04b3f69220ac878a36c561 which is
    commit a18dfa9925b9ef6107ea3aa5814ca3c704d34a8a upstream.
    
    A regression was introduced when backporting this to the stable kernels
    without applying previous commits in this series.
    
    When sending IPv6 UDP packets larger than MTU, EMSGSIZE was returned
    instead of fragmenting the packets as expected.
    
    As there is no compelling reason for this commit to be present in the
    stable kernels it should be reverted.
    
    Signed-off-by: Brett A C Sheffield <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Revert "mmc: sdhci: Disable SD card clock before changing parameters" [+ + +]
Author: Ulf Hansson <[email protected]>
Date:   Tue Jun 24 13:09:32 2025 +0200

    Revert "mmc: sdhci: Disable SD card clock before changing parameters"
    
    commit dcc3bcfc5b50c625b475dcc25d167b6b947a6637 upstream.
    
    It has turned out the trying to strictly conform to the SDHCI specification
    is causing problems. Let's revert and start over.
    
    This reverts commit fb3bbc46c94f261b6156ee863c1b06c84cf157dc.
    
    Cc: Erick Shepherd <[email protected]>
    Cc: [email protected]
    Fixes: fb3bbc46c94f ("mmc: sdhci: Disable SD card clock before changing parameters")
    Suggested-by: Adrian Hunter <[email protected]>
    Reported-by: Jonathan Liu <[email protected]>
    Reported-by: Salvatore Bonaccorso <[email protected]>
    Closes: https://bugs.debian.org/1108065
    Acked-by: Adrian Hunter <[email protected]>
    Signed-off-by: Ulf Hansson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
rose: fix dangling neighbour pointers in rose_rt_device_down() [+ + +]
Author: Kohei Enju <[email protected]>
Date:   Sun Jun 29 12:06:31 2025 +0900

    rose: fix dangling neighbour pointers in rose_rt_device_down()
    
    [ Upstream commit 34a500caf48c47d5171f4aa1f237da39b07c6157 ]
    
    There are two bugs in rose_rt_device_down() that can cause
    use-after-free:
    
    1. The loop bound `t->count` is modified within the loop, which can
       cause the loop to terminate early and miss some entries.
    
    2. When removing an entry from the neighbour array, the subsequent entries
       are moved up to fill the gap, but the loop index `i` is still
       incremented, causing the next entry to be skipped.
    
    For example, if a node has three neighbours (A, A, B) with count=3 and A
    is being removed, the second A is not checked.
    
        i=0: (A, A, B) -> (A, B) with count=2
              ^ checked
        i=1: (A, B)    -> (A, B) with count=2
                 ^ checked (B, not A!)
        i=2: (doesn't occur because i < count is false)
    
    This leaves the second A in the array with count=2, but the rose_neigh
    structure has been freed. Code that accesses these entries assumes that
    the first `count` entries are valid pointers, causing a use-after-free
    when it accesses the dangling pointer.
    
    Fix both issues by iterating over the array in reverse order with a fixed
    loop bound. This ensures that all entries are examined and that the removal
    of an entry doesn't affect subsequent iterations.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=e04e2c007ba2c80476cb
    Tested-by: [email protected]
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Kohei Enju <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
rtc: cmos: use spin_lock_irqsave in cmos_interrupt [+ + +]
Author: Mateusz Jończyk <[email protected]>
Date:   Sat Jun 7 23:06:08 2025 +0200

    rtc: cmos: use spin_lock_irqsave in cmos_interrupt
    
    commit 00a39d8652ff9088de07a6fe6e9e1893452fe0dd upstream.
    
    cmos_interrupt() can be called in a non-interrupt context, such as in
    an ACPI event handler (which runs in an interrupt thread). Therefore,
    usage of spin_lock(&rtc_lock) is insecure. Use spin_lock_irqsave() /
    spin_unlock_irqrestore() instead.
    
    Before a misguided
    commit 6950d046eb6e ("rtc: cmos: Replace spin_lock_irqsave with spin_lock in hard IRQ")
    the cmos_interrupt() function used spin_lock_irqsave(). That commit
    changed it to spin_lock() and broke locking, which was partially fixed in
    commit 13be2efc390a ("rtc: cmos: Disable irq around direct invocation of cmos_interrupt()")
    
    That second commit did not take account of the ACPI fixed event handler
    pathway, however. It introduced local_irq_disable() workarounds in
    cmos_check_wkalrm(), which can cause problems on PREEMPT_RT kernels
    and are now unnecessary.
    
    Add an explicit comment so that this change will not be reverted by
    mistake.
    
    Cc: [email protected]
    Fixes: 6950d046eb6e ("rtc: cmos: Replace spin_lock_irqsave with spin_lock in hard IRQ")
    Signed-off-by: Mateusz Jończyk <[email protected]>
    Reviewed-by: Sebastian Andrzej Siewior <[email protected]>
    Tested-by: Chris Bainbridge <[email protected]>
    Reported-by: Chris Bainbridge <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexandre Belloni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
s390/entry: Fix last breaking event handling in case of stack corruption [+ + +]
Author: Heiko Carstens <[email protected]>
Date:   Thu Apr 24 17:07:01 2025 +0200

    s390/entry: Fix last breaking event handling in case of stack corruption
    
    commit ae952eea6f4a7e2193f8721a5366049946e012e7 upstream.
    
    In case of stack corruption stack_invalid() is called and the expectation
    is that register r10 contains the last breaking event address. This
    dependency is quite subtle and broke a couple of years ago without that
    anybody noticed.
    
    Fix this by getting rid of the dependency and read the last breaking event
    address from lowcore.
    
    Fixes: 56e62a737028 ("s390: convert to generic entry")
    Acked-by: Ilya Leoshkevich <[email protected]>
    Reviewed-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
s390/pkey: Prevent overflow in size calculation for memdup_user() [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Wed Jun 11 22:20:10 2025 +0300

    s390/pkey: Prevent overflow in size calculation for memdup_user()
    
    commit 7360ee47599af91a1d5f4e74d635d9408a54e489 upstream.
    
    Number of apqn target list entries contained in 'nr_apqns' variable is
    determined by userspace via an ioctl call so the result of the product in
    calculation of size passed to memdup_user() may overflow.
    
    In this case the actual size of the allocated area and the value
    describing it won't be in sync leading to various types of unpredictable
    behaviour later.
    
    Use a proper memdup_array_user() helper which returns an error if an
    overflow is detected. Note that it is different from when nr_apqns is
    initially zero - that case is considered valid and should be handled in
    subsequent pkey_handler implementations.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: f2bbc96e7cfa ("s390/pkey: add CCA AES cipher key support")
    Cc: [email protected]
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Reviewed-by: Holger Dengler <[email protected]>
    Reviewed-by: Heiko Carstens <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
s390: Add '-std=gnu11' to decompressor and purgatory CFLAGS [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Wed Jan 22 19:54:27 2025 -0700

    s390: Add '-std=gnu11' to decompressor and purgatory CFLAGS
    
    commit 3b8b80e993766dc96d1a1c01c62f5d15fafc79b9 upstream.
    
    GCC changed the default C standard dialect from gnu17 to gnu23,
    which should not have impacted the kernel because it explicitly requests
    the gnu11 standard in the main Makefile. However, there are certain
    places in the s390 code that use their own CFLAGS without a '-std='
    value, which break with this dialect change because of the kernel's own
    definitions of bool, false, and true conflicting with the C23 reserved
    keywords.
    
      include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant
         11 |         false   = 0,
            |         ^~~~~
      include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards
      include/linux/types.h:35:33: error: 'bool' cannot be defined via 'typedef'
         35 | typedef _Bool                   bool;
            |                                 ^~~~
      include/linux/types.h:35:33: note: 'bool' is a keyword with '-std=c23' onwards
    
    Add '-std=gnu11' to the decompressor and purgatory CFLAGS to eliminate
    these errors and make the C standard version of these areas match the
    rest of the kernel.
    
    Cc: [email protected]
    Signed-off-by: Nathan Chancellor <[email protected]>
    Tested-by: Heiko Carstens <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
scsi: qla2xxx: Fix DMA mapping test in qla24xx_get_port_database() [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Tue Jun 17 18:11:11 2025 +0200

    scsi: qla2xxx: Fix DMA mapping test in qla24xx_get_port_database()
    
    [ Upstream commit c3b214719a87735d4f67333a8ef3c0e31a34837c ]
    
    dma_map_XXX() functions return as error values DMA_MAPPING_ERROR which is
    often ~0.  The error value should be tested with dma_mapping_error() like
    it was done in qla26xx_dport_diagnostics().
    
    Fixes: 818c7f87a177 ("scsi: qla2xxx: Add changes in preparation for vendor extended FDMI/RDP")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: qla4xxx: Fix missing DMA mapping error in qla4xxx_alloc_pdu() [+ + +]
Author: Thomas Fourier <[email protected]>
Date:   Wed Jun 18 09:17:37 2025 +0200

    scsi: qla4xxx: Fix missing DMA mapping error in qla4xxx_alloc_pdu()
    
    [ Upstream commit 00f452a1b084efbe8dcb60a29860527944a002a1 ]
    
    dma_map_XXX() can fail and should be tested for errors with
    dma_mapping_error().
    
    Fixes: b3a271a94d00 ("[SCSI] qla4xxx: support iscsiadm session mgmt")
    Signed-off-by: Thomas Fourier <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port() [+ + +]
Author: Maurizio Lombardi <[email protected]>
Date:   Thu Jun 12 12:15:56 2025 +0200

    scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()
    
    [ Upstream commit d8ab68bdb294b09a761e967dad374f2965e1913f ]
    
    The function core_scsi3_decode_spec_i_port(), in its error code path,
    unconditionally calls core_scsi3_lunacl_undepend_item() passing the
    dest_se_deve pointer, which may be NULL.
    
    This can lead to a NULL pointer dereference if dest_se_deve remains
    unset.
    
    SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg
    Unable to handle kernel paging request at virtual address dfff800000000012
    Call trace:
      core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P)
      core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod]
      core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod]
      target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod]
    
    Fix this by adding a NULL check before calling
    core_scsi3_lunacl_undepend_item()
    
    Signed-off-by: Maurizio Lombardi <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Mike Christie <[email protected]>
    Reviewed-by: John Meneghini <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

scsi: ufs: core: Fix spelling of a sysfs attribute name [+ + +]
Author: Bart Van Assche <[email protected]>
Date:   Tue Jun 24 11:16:44 2025 -0700

    scsi: ufs: core: Fix spelling of a sysfs attribute name
    
    [ Upstream commit 021f243627ead17eb6500170256d3d9be787dad8 ]
    
    Change "resourse" into "resource" in the name of a sysfs attribute.
    
    Fixes: d829fc8a1058 ("scsi: ufs: sysfs: unit descriptor")
    Signed-off-by: Bart Van Assche <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Reviewed-by: Avri Altman <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
spi: spi-fsl-dspi: Clear completion counter before initiating transfer [+ + +]
Author: James Clark <[email protected]>
Date:   Fri Jun 27 11:21:37 2025 +0100

    spi: spi-fsl-dspi: Clear completion counter before initiating transfer
    
    [ Upstream commit fa60c094c19b97e103d653f528f8d9c178b6a5f5 ]
    
    In target mode, extra interrupts can be received between the end of a
    transfer and halting the module if the host continues sending more data.
    If the interrupt from this occurs after the reinit_completion() then the
    completion counter is left at a non-zero value. The next unrelated
    transfer initiated by userspace will then complete immediately without
    waiting for the interrupt or writing to the RX buffer.
    
    Fix it by resetting the counter before the transfer so that lingering
    values are cleared. This is done after clearing the FIFOs and the
    status register but before the transfer is initiated, so no interrupts
    should be received at this point resulting in other race conditions.
    
    Fixes: 4f5ee75ea171 ("spi: spi-fsl-dspi: Replace interruptible wait queue with a simple completion")
    Signed-off-by: James Clark <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
staging: rtl8723bs: Avoid memset() in aes_cipher() and aes_decipher() [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Mon Jun 9 14:13:14 2025 -0700

    staging: rtl8723bs: Avoid memset() in aes_cipher() and aes_decipher()
    
    commit a55bc4ffc06d8c965a7d6f0a01ed0ed41380df28 upstream.
    
    After commit 6f110a5e4f99 ("Disable SLUB_TINY for build testing"), which
    causes CONFIG_KASAN to be enabled in allmodconfig again, arm64
    allmodconfig builds with older versions of clang (15 through 17) show an
    instance of -Wframe-larger-than (which breaks the build with
    CONFIG_WERROR=y):
    
      drivers/staging/rtl8723bs/core/rtw_security.c:1287:5: error: stack frame size (2208) exceeds limit (2048) in 'rtw_aes_decrypt' [-Werror,-Wframe-larger-than]
       1287 | u32 rtw_aes_decrypt(struct adapter *padapter, u8 *precvframe)
            |     ^
    
    This comes from aes_decipher() being inlined in rtw_aes_decrypt().
    Running the same build with CONFIG_FRAME_WARN=128 shows aes_cipher()
    also uses a decent amount of stack, just under the limit of 2048:
    
      drivers/staging/rtl8723bs/core/rtw_security.c:864:19: warning: stack frame size (1952) exceeds limit (128) in 'aes_cipher' [-Wframe-larger-than]
        864 | static signed int aes_cipher(u8 *key, uint      hdrlen,
            |                   ^
    
    -Rpass-analysis=stack-frame-layout only shows one large structure on the
    stack, which is the ctx variable inlined from aes128k128d(). A good
    number of the other variables come from the additional checks of
    fortified string routines, which are present in memset(), which both
    aes_cipher() and aes_decipher() use to initialize some temporary
    buffers. In this case, since the size is known at compile time, these
    additional checks should not result in any code generation changes but
    allmodconfig has several sanitizers enabled, which may make it harder
    for the compiler to eliminate the compile time checks and the variables
    that come about from them.
    
    The memset() calls are just initializing these buffers to zero, so use
    '= {}' instead, which is used all over the kernel and does the exact
    same thing as memset() without the fortify checks, which drops the stack
    usage of these functions by a few hundred kilobytes.
    
      drivers/staging/rtl8723bs/core/rtw_security.c:864:19: warning: stack frame size (1584) exceeds limit (128) in 'aes_cipher' [-Wframe-larger-than]
        864 | static signed int aes_cipher(u8 *key, uint      hdrlen,
            |                   ^
      drivers/staging/rtl8723bs/core/rtw_security.c:1271:5: warning: stack frame size (1456) exceeds limit (128) in 'rtw_aes_decrypt' [-Wframe-larger-than]
       1271 | u32 rtw_aes_decrypt(struct adapter *padapter, u8 *precvframe)
            |     ^
    
    Cc: [email protected]
    Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
    Signed-off-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Dan Carpenter <[email protected]>
    Link: https://lore.kernel.org/r/20250609-rtl8723bs-fix-clang-arm64-wflt-v1-1-e2accba43def@kernel.org
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tty/vt: consolemap: rename and document struct uni_pagedir [+ + +]
Author: Jiri Slaby <[email protected]>
Date:   Tue Jun 7 12:49:12 2022 +0200

    tty/vt: consolemap: rename and document struct uni_pagedir
    
    [ Upstream commit 4173f018aae16b6496d292c234b858241f85254f ]
    
    struct uni_pagedir contains 32 unicode page directories, so the name of
    the structure is a bit misleading. Rename the structure to uni_pagedict,
    so it looks like this:
    struct uni_pagedict
      -> 32 page dirs
         -> 32 rows
           -> 64 glyphs
    
    Signed-off-by: Jiri Slaby <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 03bcbbb3995b ("dummycon: Trigger redraw when switching consoles with deferred takeover")
    Signed-off-by: Sasha Levin <[email protected]>

 
tty: serial: uartlite: register uart driver in init [+ + +]
Author: Jakub Lewalski <[email protected]>
Date:   Mon Mar 31 18:06:19 2025 +0200

    tty: serial: uartlite: register uart driver in init
    
    [ Upstream commit 6bd697b5fc39fd24e2aa418c7b7d14469f550a93 ]
    
    When two instances of uart devices are probing, a concurrency race can
    occur. If one thread calls uart_register_driver function, which first
    allocates and assigns memory to 'uart_state' member of uart_driver
    structure, the other instance can bypass uart driver registration and
    call ulite_assign. This calls uart_add_one_port, which expects the uart
    driver to be fully initialized. This leads to a kernel panic due to a
    null pointer dereference:
    
    [    8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8
    [    8.156982] #PF: supervisor write access in kernel mode
    [    8.156984] #PF: error_code(0x0002) - not-present page
    [    8.156986] PGD 0 P4D 0
    ...
    [    8.180668] RIP: 0010:mutex_lock+0x19/0x30
    [    8.188624] Call Trace:
    [    8.188629]  ? __die_body.cold+0x1a/0x1f
    [    8.195260]  ? page_fault_oops+0x15c/0x290
    [    8.209183]  ? __irq_resolve_mapping+0x47/0x80
    [    8.209187]  ? exc_page_fault+0x64/0x140
    [    8.209190]  ? asm_exc_page_fault+0x22/0x30
    [    8.209196]  ? mutex_lock+0x19/0x30
    [    8.223116]  uart_add_one_port+0x60/0x440
    [    8.223122]  ? proc_tty_register_driver+0x43/0x50
    [    8.223126]  ? tty_register_driver+0x1ca/0x1e0
    [    8.246250]  ulite_probe+0x357/0x4b0 [uartlite]
    
    To prevent it, move uart driver registration in to init function. This
    will ensure that uart_driver is always registered when probe function
    is called.
    
    Signed-off-by: Jakub Lewalski <[email protected]>
    Signed-off-by: Elodie Decerle <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

tty: vt: make consw::con_switch() return a bool [+ + +]
Author: Jiri Slaby (SUSE) <[email protected]>
Date:   Mon Jan 22 12:03:44 2024 +0100

    tty: vt: make consw::con_switch() return a bool
    
    [ Upstream commit 8d5cc8eed738e3202379722295c626cba0849785 ]
    
    The non-zero (true) return value from consw::con_switch() means a redraw
    is needed. So make this return type a bool explicitly instead of int.
    The latter might imply that -Eerrors are expected. They are not.
    
    And document the hook.
    
    Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Tested-by: Helge Deller <[email protected]> # parisc STI console
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 03bcbbb3995b ("dummycon: Trigger redraw when switching consoles with deferred takeover")
    Signed-off-by: Sasha Levin <[email protected]>

tty: vt: make init parameter of consw::con_init() a bool [+ + +]
Author: Jiri Slaby (SUSE) <[email protected]>
Date:   Mon Jan 22 12:03:34 2024 +0100

    tty: vt: make init parameter of consw::con_init() a bool
    
    [ Upstream commit dae3e6b6180f1a2394b984c596d39ed2c57d25fe ]
    
    The 'init' parameter of consw::con_init() is true for the first call of
    the hook on a particular console. So make the parameter a bool.
    
    And document the hook.
    
    Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]>
    Reviewed-by: Geert Uytterhoeven <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Tested-by: Helge Deller <[email protected]> # parisc STI console
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 03bcbbb3995b ("dummycon: Trigger redraw when switching consoles with deferred takeover")
    Signed-off-by: Sasha Levin <[email protected]>

tty: vt: sanitize arguments of consw::con_clear() [+ + +]
Author: Jiri Slaby (SUSE) <[email protected]>
Date:   Mon Jan 22 12:03:35 2024 +0100

    tty: vt: sanitize arguments of consw::con_clear()
    
    [ Upstream commit 559f01a0ee6d924c6fec3eaf6a5b078b15e71070 ]
    
    In consw::con_clear():
    * Height is always 1, so drop it.
    * Offsets and width are always unsigned values, so re-type them as such.
    
    This needs a new __fbcon_clear() in the fbcon code to still handle
    height which might not be 1 when called internally.
    
    Note that tests for negative count/width are left in place -- they are
    taken care of in the next patches.
    
    And document the hook.
    
    Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: Daniel Vetter <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Tested-by: Helge Deller <[email protected]> # parisc STI console
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 03bcbbb3995b ("dummycon: Trigger redraw when switching consoles with deferred takeover")
    Signed-off-by: Sasha Levin <[email protected]>

 
uio_hv_generic: Align ring size to system page [+ + +]
Author: Long Li <[email protected]>
Date:   Mon May 5 17:56:35 2025 -0700

    uio_hv_generic: Align ring size to system page
    
    [ Upstream commit 0315fef2aff9f251ddef8a4b53db9187429c3553 ]
    
    Following the ring header, the ring data should align to system page
    boundary. Adjust the size if necessary.
    
    Cc: [email protected]
    Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus")
    Signed-off-by: Long Li <[email protected]>
    Reviewed-by: Michael Kelley <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Wei Liu <[email protected]>
    Message-ID: <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

uio_hv_generic: Query the ringbuffer size for device [+ + +]
Author: Saurabh Sengar <[email protected]>
Date:   Sat Mar 30 01:51:58 2024 -0700

    uio_hv_generic: Query the ringbuffer size for device
    
    [ Upstream commit e566ed5b64177a0c07b677568f623ed31d23406d ]
    
    Query the ring buffer size from pre defined table per device
    and use that value for allocating the ring buffer for that
    device. Keep the size as current default which is 2 MB if
    the device doesn't have any preferred ring size.
    
    Signed-off-by: Saurabh Sengar <[email protected]>
    Reviewed-by: Long Li <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Stable-dep-of: 0315fef2aff9 ("uio_hv_generic: Align ring size to system page")
    Signed-off-by: Sasha Levin <[email protected]>

 
um: Add cmpxchg8b_emu and checksum functions to asm-prototypes.h [+ + +]
Author: Sami Tolvanen <[email protected]>
Date:   Wed Mar 26 19:05:00 2025 +0000

    um: Add cmpxchg8b_emu and checksum functions to asm-prototypes.h
    
    [ Upstream commit 674d03f6bd6b0f8327f1a4920ff5893557facfbd ]
    
    With CONFIG_GENDWARFKSYMS, um builds fail due to missing prototypes
    in asm/asm-prototypes.h. Add declarations for cmpxchg8b_emu and the
    exported checksum functions, including csum_partial_copy_generic as
    it's also exported.
    
    Cc: Masahiro Yamada <[email protected]>
    Cc: [email protected]
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Sami Tolvanen <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

um: ubd: Add missing error check in start_io_thread() [+ + +]
Author: Tiwei Bie <[email protected]>
Date:   Fri Jun 6 20:44:25 2025 +0800

    um: ubd: Add missing error check in start_io_thread()
    
    [ Upstream commit c55c7a85e02a7bfee20a3ffebdff7cbeb41613ef ]
    
    The subsequent call to os_set_fd_block() overwrites the previous
    return value. OR the two return values together to fix it.
    
    Fixes: f88f0bdfc32f ("um: UBD Improvements")
    Signed-off-by: Tiwei Bie <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
usb: Add checks for snprintf() calls in usb_alloc_dev() [+ + +]
Author: Andy Shevchenko <[email protected]>
Date:   Fri Mar 21 18:49:49 2025 +0200

    usb: Add checks for snprintf() calls in usb_alloc_dev()
    
    [ Upstream commit 82fe5107fa3d21d6c3fba091c9dbc50495588630 ]
    
    When creating a device path in the driver the snprintf() takes
    up to 16 characters long argument along with the additional up to
    12 characters for the signed integer (as it can't see the actual limits)
    and tries to pack this into 16 bytes array. GCC complains about that
    when build with `make W=1`:
    
      drivers/usb/core/usb.c:705:25: note: ‘snprintf’ output between 3 and 28 bytes into a destination of size 16
    
    Since everything works until now, let's just check for the potential
    buffer overflow and bail out. It is most likely a never happen situation,
    but at least it makes GCC happy.
    
    Signed-off-by: Andy Shevchenko <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: cdc-wdm: avoid setting WDM_READ for ZLP-s [+ + +]
Author: Robert Hodaszi <[email protected]>
Date:   Thu Apr 3 16:40:04 2025 +0200

    usb: cdc-wdm: avoid setting WDM_READ for ZLP-s
    
    [ Upstream commit 387602d8a75574fafb451b7a8215e78dfd67ee63 ]
    
    Don't set WDM_READ flag in wdm_in_callback() for ZLP-s, otherwise when
    userspace tries to poll for available data, it might - incorrectly -
    believe there is something available, and when it tries to non-blocking
    read it, it might get stuck in the read loop.
    
    For example this is what glib does for non-blocking read (briefly):
    
      1. poll()
      2. if poll returns with non-zero, starts a read data loop:
        a. loop on poll() (EINTR disabled)
        b. if revents was set, reads data
          I. if read returns with EINTR or EAGAIN, goto 2.a.
          II. otherwise return with data
    
    So if ZLP sets WDM_READ (#1), we expect data, and try to read it (#2).
    But as that was a ZLP, and we are doing non-blocking read, wdm_read()
    returns with EAGAIN (#2.b.I), so loop again, and try to read again
    (#2.a.).
    
    With glib, we might stuck in this loop forever, as EINTR is disabled
    (#2.a).
    
    Signed-off-by: Robert Hodaszi <[email protected]>
    Acked-by: Oliver Neukum <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: cdnsp: do not disable slot for disabled slot [+ + +]
Author: Peter Chen <[email protected]>
Date:   Thu Jun 19 09:34:13 2025 +0800

    usb: cdnsp: do not disable slot for disabled slot
    
    commit 7e2c421ef88e9da9c39e01496b7f5b0b354b42bc upstream.
    
    It doesn't need to do it, and the related command event returns
    'Slot Not Enabled Error' status.
    
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    Cc: stable <[email protected]>
    Suggested-by: Hongliang Yang <[email protected]>
    Reviewed-by: Fugang Duan <[email protected]>
    Signed-off-by: Peter Chen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: common: usb-conn-gpio: use a unique name for usb connector device [+ + +]
Author: Chance Yang <[email protected]>
Date:   Fri Apr 11 16:33:26 2025 +0800

    usb: common: usb-conn-gpio: use a unique name for usb connector device
    
    [ Upstream commit d4e5b10c55627e2f3fc9e5b337a28b4e2f02a55e ]
    
    The current implementation of the usb-conn-gpio driver uses a fixed
    "usb-charger" name for all USB connector devices. This causes conflicts
    in the power supply subsystem when multiple USB connectors are present,
    as duplicate names are not allowed.
    
    Use IDA to manage unique IDs for naming usb connectors (e.g.,
    usb-charger-0, usb-charger-1).
    
    Signed-off-by: Chance Yang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: dwc2: also exit clock_gating when stopping udc while suspended [+ + +]
Author: Michael Grzeschik <[email protected]>
Date:   Thu Apr 17 19:40:17 2025 +0200

    usb: dwc2: also exit clock_gating when stopping udc while suspended
    
    [ Upstream commit af076a41f8a28faf9ceb9dd2d88aef2c202ef39a ]
    
    It is possible that the gadget will be disabled, while the udc is
    suspended. When enabling the udc in that case, the clock gating
    will not be enabled again. Leaving the phy unclocked. Even when the
    udc is not enabled, connecting this powered but not clocked phy leads
    to enumeration errors on the host side.
    
    To ensure that the clock gating will be in an valid state, we ensure
    that the clock gating will be enabled before stopping the udc.
    
    Signed-off-by: Michael Grzeschik <[email protected]>
    Acked-by: Minas Harutyunyan <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: potential integer overflow in usbg_make_tpg() [+ + +]
Author: Chen Yufeng <[email protected]>
Date:   Tue Apr 15 14:58:57 2025 +0800

    usb: potential integer overflow in usbg_make_tpg()
    
    [ Upstream commit 153874010354d050f62f8ae25cbb960c17633dc5 ]
    
    The variable tpgt in usbg_make_tpg() is defined as unsigned long and is
    assigned to tpgt->tport_tpgt, which is defined as u16. This may cause an
    integer overflow when tpgt is greater than USHRT_MAX (65535). I
    haven't tried to trigger it myself, but it is possible to trigger it
    by calling usbg_make_tpg() with a large value for tpgt.
    
    I modified the type of tpgt to match tpgt->tport_tpgt and adjusted the
    relevant code accordingly.
    
    This patch is similar to commit 59c816c1f24d ("vhost/scsi: potential
    memory corruption").
    
    Signed-off-by: Chen Yufeng <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

usb: typec: altmodes/displayport: do not index invalid pin_assignments [+ + +]
Author: RD Babiera <[email protected]>
Date:   Wed Jun 18 22:49:42 2025 +0000

    usb: typec: altmodes/displayport: do not index invalid pin_assignments
    
    commit af4db5a35a4ef7a68046883bfd12468007db38f1 upstream.
    
    A poorly implemented DisplayPort Alt Mode port partner can indicate
    that its pin assignment capabilities are greater than the maximum
    value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show
    will cause a BRK exception due to an out of bounds array access.
    
    Prevent for loop in pin_assignment_show from accessing
    invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX
    value in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop
    condition.
    
    Fixes: 0e3bb7d6894d ("usb: typec: Add driver for DisplayPort alternate mode")
    Cc: stable <[email protected]>
    Signed-off-by: RD Babiera <[email protected]>
    Reviewed-by: Badhri Jagan Sridharan <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: displayport: Fix potential deadlock [+ + +]
Author: Andrei Kuchynski <[email protected]>
Date:   Tue Jun 24 13:32:46 2025 +0000

    usb: typec: displayport: Fix potential deadlock
    
    commit 099cf1fbb8afc3771f408109f62bdec66f85160e upstream.
    
    The deadlock can occur due to a recursive lock acquisition of
    `cros_typec_altmode_data::mutex`.
    The call chain is as follows:
    1. cros_typec_altmode_work() acquires the mutex
    2. typec_altmode_vdm() -> dp_altmode_vdm() ->
    3. typec_altmode_exit() -> cros_typec_altmode_exit()
    4. cros_typec_altmode_exit() attempts to acquire the mutex again
    
    To prevent this, defer the `typec_altmode_exit()` call by scheduling
    it rather than calling it directly from within the mutex-protected
    context.
    
    Cc: stable <[email protected]>
    Fixes: b4b38ffb38c9 ("usb: typec: displayport: Receive DP Status Update NAK request exit dp altmode")
    Signed-off-by: Andrei Kuchynski <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

usb: typec: displayport: Receive DP Status Update NAK request exit dp altmode [+ + +]
Author: Jos Wang <[email protected]>
Date:   Sun Feb 9 15:19:26 2025 +0800

    usb: typec: displayport: Receive DP Status Update NAK request exit dp altmode
    
    [ Upstream commit b4b38ffb38c91afd4dc387608db26f6fc34ed40b ]
    
    Although some Type-C DRD devices that do not support the DP Sink
    function (such as Huawei Mate 40Pro), the Source Port initiates
    Enter Mode CMD, but the device responds to Enter Mode ACK, the
    Source port then initiates DP Status Update CMD, and the device
    responds to DP Status Update NAK.
    
    As PD2.0 spec ("6.4.4.3.4 Enter Mode Command"),A DR_Swap Message
    Shall Not be sent during Modal Operation between the Port Partners.
    At this time, the source port initiates DR_Swap message through the
    "echo device > /sys/class/typec/port0/data_role" command to switch
    the data role from host to device. The device will initiate a Hard
    Reset for recovery, resulting in the failure of data role swap.
    
    Therefore, when DP Status Update NAK is received, Exit Mode CMD is
    initiated to exit the currently entered DP altmode.
    
    Signed-off-by: Jos Wang <[email protected]>
    Reviewed-by: Heikki Krogerus <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vgacon: remove unneeded forward declarations [+ + +]
Author: Jiri Slaby (SUSE) <[email protected]>
Date:   Wed Jul 12 10:59:37 2023 +0200

    vgacon: remove unneeded forward declarations
    
    [ Upstream commit 6ceed69cde8fe4a78fe50d62d7a88a5c1eed4709 ]
    
    Most of the forward declarations in vgacon are not needed. Drop them.
    
    Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Helge Deller <[email protected]>
    Stable-dep-of: 03bcbbb3995b ("dummycon: Trigger redraw when switching consoles with deferred takeover")
    Signed-off-by: Sasha Levin <[email protected]>

vgacon: switch vgacon_scrolldelta() and vgacon_restore_screen() [+ + +]
Author: Jiri Slaby (SUSE) <[email protected]>
Date:   Wed Jul 12 10:59:36 2023 +0200

    vgacon: switch vgacon_scrolldelta() and vgacon_restore_screen()
    
    [ Upstream commit 03b89a08484a88fb9e0604cab2b3eb0c2f265c74 ]
    
    Switch vgacon_scrolldelta() and vgacon_restore_screen() positions, so
    that the former is not needed to be forward-declared.
    
    Signed-off-by: "Jiri Slaby (SUSE)" <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Signed-off-by: Helge Deller <[email protected]>
    Stable-dep-of: 03bcbbb3995b ("dummycon: Trigger redraw when switching consoles with deferred takeover")
    Signed-off-by: Sasha Levin <[email protected]>

 
vsock/uapi: fix linux/vm_sockets.h userspace compilation errors [+ + +]
Author: Stefano Garzarella <[email protected]>
Date:   Mon Jun 23 12:00:53 2025 +0200

    vsock/uapi: fix linux/vm_sockets.h userspace compilation errors
    
    [ Upstream commit 22bbc1dcd0d6785fb390c41f0dd5b5e218d23bdd ]
    
    If a userspace application just include <linux/vm_sockets.h> will fail
    to build with the following errors:
    
        /usr/include/linux/vm_sockets.h:182:39: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr’
          182 |         unsigned char svm_zero[sizeof(struct sockaddr) -
              |                                       ^~~~~~
        /usr/include/linux/vm_sockets.h:183:39: error: ‘sa_family_t’ undeclared here (not in a function)
          183 |                                sizeof(sa_family_t) -
              |
    
    Include <sys/socket.h> for userspace (guarded by ifndef __KERNEL__)
    where `struct sockaddr` and `sa_family_t` are defined.
    We already do something similar in <linux/mptcp.h> and <linux/if.h>.
    
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Reported-by: Daan De Meyer <[email protected]>
    Signed-off-by: Stefano Garzarella <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vsock/vmci: Clear the vmci transport packet properly when initializing it [+ + +]
Author: HarshaVardhana S A <[email protected]>
Date:   Tue Jul 1 14:22:54 2025 +0200

    vsock/vmci: Clear the vmci transport packet properly when initializing it
    
    commit 223e2288f4b8c262a864e2c03964ffac91744cd5 upstream.
    
    In vmci_transport_packet_init memset the vmci_transport_packet before
    populating the fields to avoid any uninitialised data being left in the
    structure.
    
    Cc: Bryan Tan <[email protected]>
    Cc: Vishnu Dasa <[email protected]>
    Cc: Broadcom internal kernel review list
    Cc: Stefano Garzarella <[email protected]>
    Cc: "David S. Miller" <[email protected]>
    Cc: Eric Dumazet <[email protected]>
    Cc: Jakub Kicinski <[email protected]>
    Cc: Paolo Abeni <[email protected]>
    Cc: Simon Horman <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: stable <[email protected]>
    Signed-off-by: HarshaVardhana S A <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Fixes: d021c344051a ("VSOCK: Introduce VM Sockets")
    Acked-by: Stefano Garzarella <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
wifi: ath6kl: remove WARN on bad firmware input [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Tue Jun 17 11:45:29 2025 +0200

    wifi: ath6kl: remove WARN on bad firmware input
    
    [ Upstream commit e7417421d89358da071fd2930f91e67c7128fbff ]
    
    If the firmware gives bad input, that's nothing to do with
    the driver's stack at this point etc., so the WARN_ON()
    doesn't add any value. Additionally, this is one of the
    top syzbot reports now. Just print a message, and as an
    added bonus, print the sizes too.
    
    Reported-by: [email protected]
    Tested-by: [email protected]
    Acked-by: Jeff Johnson <[email protected]>
    Link: https://patch.msgid.link/20250617114529.031a677a348e.I58bf1eb4ac16a82c546725ff010f3f0d2b0cca49@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: drop invalid source address OCB frames [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Mon Jun 16 17:18:38 2025 +0200

    wifi: mac80211: drop invalid source address OCB frames
    
    [ Upstream commit d1b1a5eb27c4948e8811cf4dbb05aaf3eb10700c ]
    
    In OCB, don't accept frames from invalid source addresses
    (and in particular don't try to create stations for them),
    drop the frames instead.
    
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/r/[email protected]/
    Signed-off-by: Johannes Berg <[email protected]>
    Tested-by: [email protected]
    Link: https://patch.msgid.link/20250616171838.7433379cab5d.I47444d63c72a0bd58d2e2b67bb99e1fea37eec6f@changeid
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

wifi: mac80211: fix beacon interval calculation overflow [+ + +]
Author: Lachlan Hodges <[email protected]>
Date:   Sat Jun 21 22:32:09 2025 +1000

    wifi: mac80211: fix beacon interval calculation overflow
    
    [ Upstream commit 7a3750ff0f2e8fee338a9c168f429f6c37f0e820 ]
    
    As we are converting from TU to usecs, a beacon interval of
    100*1024 usecs will lead to integer wrapping. To fix change
    to use a u32.
    
    Fixes: 057d5f4ba1e4 ("mac80211: sync dtim_count to TSF")
    Signed-off-by: Lachlan Hodges <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
x86/bugs: Add a Transient Scheduler Attacks mitigation [+ + +]
Author: Borislav Petkov (AMD) <[email protected]>
Date:   Wed Sep 11 10:53:08 2024 +0200

    x86/bugs: Add a Transient Scheduler Attacks mitigation
    
    commit d8010d4ba43e9f790925375a7de100604a5e2dba upstream.
    
    Add the required features detection glue to bugs.c et all in order to
    support the TSA mitigation.
    
    Co-developed-by: Kim Phillips <[email protected]>
    Signed-off-by: Kim Phillips <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Pawan Gupta <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

x86/bugs: Rename MDS machinery to something more generic [+ + +]
Author: Borislav Petkov (AMD) <[email protected]>
Date:   Wed Sep 11 05:13:46 2024 +0200

    x86/bugs: Rename MDS machinery to something more generic
    
    Commit f9af88a3d384c8b55beb5dc5483e5da0135fadbd upstream.
    
    It will be used by other x86 mitigations.
    
    No functional changes.
    
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Pawan Gupta <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/process: Move the buffer clearing before MONITOR [+ + +]
Author: Borislav Petkov (AMD) <[email protected]>
Date:   Mon Apr 14 15:33:19 2025 +0200

    x86/process: Move the buffer clearing before MONITOR
    
    Commit 8e786a85c0a3c0fffae6244733fb576eeabd9dec upstream.
    
    Move the VERW clearing before the MONITOR so that VERW doesn't disarm it
    and the machine never enters C1.
    
    Original idea by Kim Phillips <[email protected]>.
    
    Suggested-by: Andrew Cooper <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
xhci: dbc: Flush queued requests before stopping dbc [+ + +]
Author: Mathias Nyman <[email protected]>
Date:   Fri Jun 27 17:41:22 2025 +0300

    xhci: dbc: Flush queued requests before stopping dbc
    
    commit efe3e3ae5a66cb38ef29c909e951b4039044bae9 upstream.
    
    Flush dbc requests when dbc is stopped and transfer rings are freed.
    Failure to flush them lead to leaking memory and dbc completing odd
    requests after resuming from suspend, leading to error messages such as:
    
    [   95.344392] xhci_hcd 0000:00:0d.0: no matched request
    
    Cc: stable <[email protected]>
    Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
    Signed-off-by: Mathias Nyman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

xhci: dbctty: disable ECHO flag by default [+ + +]
Author: Łukasz Bartosik <[email protected]>
Date:   Fri Jun 27 17:41:21 2025 +0300

    xhci: dbctty: disable ECHO flag by default
    
    commit 2b857d69a5e116150639a0c6c39c86cc329939ee upstream.
    
    When /dev/ttyDBC0 device is created then by default ECHO flag
    is set for the terminal device. However if data arrives from
    a peer before application using /dev/ttyDBC0 applies its set
    of terminal flags then the arriving data will be echoed which
    might not be desired behavior.
    
    Fixes: 4521f1613940 ("xhci: dbctty: split dbc tty driver registration and unregistration functions.")
    Cc: stable <[email protected]>
    Signed-off-by: Łukasz Bartosik <[email protected]>
    Signed-off-by: Mathias Nyman <[email protected]>
    Link: https://lore.kernel.org/stable/20250610111802.18742-1-ukaszb%40chromium.org
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>