Changelog in Linux kernel 5.15.166

 
afs: fix __afs_break_callback() / afs_drop_open_mmap() race [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Sep 29 20:24:34 2023 -0400

    afs: fix __afs_break_callback() / afs_drop_open_mmap() race
    
    [ Upstream commit 275655d3207b9e65d1561bf21c06a622d9ec1d43 ]
    
    In __afs_break_callback() we might check ->cb_nr_mmap and if it's non-zero
    do queue_work(&vnode->cb_work).  In afs_drop_open_mmap() we decrement
    ->cb_nr_mmap and do flush_work(&vnode->cb_work) if it reaches zero.
    
    The trouble is, there's nothing to prevent __afs_break_callback() from
    seeing ->cb_nr_mmap before the decrement and do queue_work() after both
    the decrement and flush_work().  If that happens, we might be in trouble -
    vnode might get freed before the queued work runs.
    
    __afs_break_callback() is always done under ->cb_lock, so let's make
    sure that ->cb_nr_mmap can change from non-zero to zero while holding
    ->cb_lock (the spinlock component of it - it's a seqlock and we don't
    need to mess with the counter).
    
    Acked-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: hda/realtek: Fix noise from speakers on Lenovo IdeaPad 3 15IAU7 [+ + +]
Author: Parsa Poorshikhian <parsa.poorsh@gmail.com>
Date:   Sat Aug 10 18:39:06 2024 +0330

    ALSA: hda/realtek: Fix noise from speakers on Lenovo IdeaPad 3 15IAU7
    
    [ Upstream commit ef9718b3d54e822de294351251f3a574f8a082ce ]
    
    Fix noise from speakers connected to AUX port when no sound is playing.
    The problem occurs because the `alc_shutup_pins` function includes
    a 0x10ec0257 vendor ID, which causes noise on Lenovo IdeaPad 3 15IAU7 with
    Realtek ALC257 codec when no sound is playing.
    Removing this vendor ID from the function fixes the bug.
    
    Fixes: 70794b9563fe ("ALSA: hda/realtek: Add more codec ID to no shutup pins list")
    Signed-off-by: Parsa Poorshikhian <parsa.poorsh@gmail.com>
    Link: https://patch.msgid.link/20240810150939.330693-1-parsa.poorsh@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: timer: Relax start tick time check for slave timer elements [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sat Aug 10 10:48:32 2024 +0200

    ALSA: timer: Relax start tick time check for slave timer elements
    
    commit ccbfcac05866ebe6eb3bc6d07b51d4ed4fcde436 upstream.
    
    The recent addition of a sanity check for a too low start tick time
    seems breaking some applications that uses aloop with a certain slave
    timer setup.  They may have the initial resolution 0, hence it's
    treated as if it were a too low value.
    
    Relax and skip the check for the slave timer instance for addressing
    the regression.
    
    Fixes: 4a63bd179fa8 ("ALSA: timer: Set lower bound of start tick time")
    Cc: <stable@vger.kernel.org>
    Link: https://github.com/raspberrypi/linux/issues/6294
    Link: https://patch.msgid.link/20240810084833.10939-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Add delay quirk for VIVO USB-C-XE710 HEADSET [+ + +]
Author: Lianqin Hu <hulianqin@vivo.com>
Date:   Sun Aug 11 08:30:11 2024 +0000

    ALSA: usb-audio: Add delay quirk for VIVO USB-C-XE710 HEADSET
    
    commit 004eb8ba776ccd3e296ea6f78f7ae7985b12824e upstream.
    
    Audio control requests that sets sampling frequency sometimes fail on
    this card. Adding delay between control messages eliminates that problem.
    
    Signed-off-by: Lianqin Hu <hulianqin@vivo.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/TYUPR06MB6217FF67076AF3E49E12C877D2842@TYUPR06MB6217.apcprd06.prod.outlook.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Support Yamaha P-125 quirk entry [+ + +]
Author: Juan José Arboleda <soyjuanarbol@gmail.com>
Date:   Tue Aug 13 11:10:53 2024 -0500

    ALSA: usb-audio: Support Yamaha P-125 quirk entry
    
    commit c286f204ce6ba7b48e3dcba53eda7df8eaa64dd9 upstream.
    
    This patch adds a USB quirk for the Yamaha P-125 digital piano.
    
    Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://patch.msgid.link/20240813161053.70256-1-soyjuanarbol@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
apparmor: fix policy_unpack_test on big endian systems [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Aug 8 08:50:03 2024 -0700

    apparmor: fix policy_unpack_test on big endian systems
    
    [ Upstream commit 98c0cc48e27e9d269a3e4db2acd72b486c88ec77 ]
    
    policy_unpack_test fails on big endian systems because data byte order
    is expected to be little endian but is generated in host byte order.
    This results in test failures such as:
    
     # policy_unpack_test_unpack_array_with_null_name: EXPECTATION FAILED at security/apparmor/policy_unpack_test.c:150
        Expected array_size == (u16)16, but
            array_size == 4096 (0x1000)
            (u16)16 == 16 (0x10)
        # policy_unpack_test_unpack_array_with_null_name: pass:0 fail:1 skip:0 total:1
        not ok 3 policy_unpack_test_unpack_array_with_null_name
        # policy_unpack_test_unpack_array_with_name: EXPECTATION FAILED at security/apparmor/policy_unpack_test.c:164
        Expected array_size == (u16)16, but
            array_size == 4096 (0x1000)
            (u16)16 == 16 (0x10)
        # policy_unpack_test_unpack_array_with_name: pass:0 fail:1 skip:0 total:1
    
    Add the missing endianness conversions when generating test data.
    
    Fixes: 4d944bcd4e73 ("apparmor: add AppArmor KUnit tests for policy unpack")
    Cc: Brendan Higgins <brendanhiggins@google.com>
    Cc: Kees Cook <keescook@chromium.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: ACPI: NUMA: initialize all values of acpi_early_node_map to NUMA_NO_NODE [+ + +]
Author: Haibo Xu <haibo1.xu@intel.com>
Date:   Mon Aug 5 11:30:24 2024 +0800

    arm64: ACPI: NUMA: initialize all values of acpi_early_node_map to NUMA_NO_NODE
    
    commit a21dcf0ea8566ebbe011c79d6ed08cdfea771de3 upstream.
    
    Currently, only acpi_early_node_map[0] was initialized to NUMA_NO_NODE.
    To ensure all the values were properly initialized, switch to initialize
    all of them to NUMA_NO_NODE.
    
    Fixes: e18962491696 ("arm64: numa: rework ACPI NUMA initialization")
    Cc: <stable@vger.kernel.org> # 4.19.x
    Reported-by: Andrew Jones <ajones@ventanamicro.com>
    Suggested-by: Andrew Jones <ajones@ventanamicro.com>
    Signed-off-by: Haibo Xu <haibo1.xu@intel.com>
    Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
    Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
    Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Acked-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
    Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
    Link: https://lore.kernel.org/r/853d7f74aa243f6f5999e203246f0d1ae92d2b61.1722828421.git.haibo1.xu@intel.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

arm64: Fix KASAN random tag seed initialization [+ + +]
Author: Samuel Holland <samuel.holland@sifive.com>
Date:   Wed Aug 14 02:09:53 2024 -0700

    arm64: Fix KASAN random tag seed initialization
    
    [ Upstream commit f75c235565f90c4a17b125e47f1c68ef6b8c2bce ]
    
    Currently, kasan_init_sw_tags() is called before setup_per_cpu_areas(),
    so per_cpu(prng_state, cpu) accesses the same address regardless of the
    value of "cpu", and the same seed value gets copied to the percpu area
    for every CPU. Fix this by moving the call to smp_prepare_boot_cpu(),
    which is the first architecture hook after setup_per_cpu_areas().
    
    Fixes: 3c9e3aa11094 ("kasan: add tag related helper functions")
    Fixes: 3f41b6093823 ("kasan: fix random seed generation for tag-based mode")
    Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
    Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
    Link: https://lore.kernel.org/r/20240814091005.969756-1-samuel.holland@sifive.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: libata-core: Fix null pointer dereference on error [+ + +]
Author: Niklas Cassel <cassel@kernel.org>
Date:   Sat Jun 29 14:42:11 2024 +0200

    ata: libata-core: Fix null pointer dereference on error
    
    commit 5d92c7c566dc76d96e0e19e481d926bbe6631c1e upstream.
    
    If the ata_port_alloc() call in ata_host_alloc() fails,
    ata_host_release() will get called.
    
    However, the code in ata_host_release() tries to free ata_port struct
    members unconditionally, which can lead to the following:
    
    BUG: unable to handle page fault for address: 0000000000003990
    PGD 0 P4D 0
    Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
    RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]
    Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41
    RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246
    RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0
    RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68
    R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004
    R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006
    FS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? __die_body.cold+0x19/0x27
     ? page_fault_oops+0x15a/0x2f0
     ? exc_page_fault+0x7e/0x180
     ? asm_exc_page_fault+0x26/0x30
     ? ata_host_release.cold+0x2f/0x6e [libata]
     ? ata_host_release.cold+0x2f/0x6e [libata]
     release_nodes+0x35/0xb0
     devres_release_group+0x113/0x140
     ata_host_alloc+0xed/0x120 [libata]
     ata_host_alloc_pinfo+0x14/0xa0 [libata]
     ahci_init_one+0x6c9/0xd20 [ahci]
    
    Do not access ata_port struct members unconditionally.
    
    Fixes: 633273a3ed1c ("libata-pmp: hook PMP support and enable it")
    Cc: stable@vger.kernel.org
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: John Garry <john.g.garry@oracle.com>
    Link: https://lore.kernel.org/r/20240629124210.181537-7-cassel@kernel.org
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
atm: idt77252: prevent use after free in dequeue_rx() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Aug 9 15:28:19 2024 +0300

    atm: idt77252: prevent use after free in dequeue_rx()
    
    [ Upstream commit a9a18e8f770c9b0703dab93580d0b02e199a4c79 ]
    
    We can't dereference "skb" after calling vcc->push() because the skb
    is released.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
binfmt_misc: cleanup on filesystem umount [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Thu Oct 28 12:31:13 2021 +0200

    binfmt_misc: cleanup on filesystem umount
    
    [ Upstream commit 1c5976ef0f7ad76319df748ccb99a4c7ba2ba464 ]
    
    Currently, registering a new binary type pins the binfmt_misc
    filesystem. Specifically, this means that as long as there is at least
    one binary type registered the binfmt_misc filesystem survives all
    umounts, i.e. the superblock is not destroyed. Meaning that a umount
    followed by another mount will end up with the same superblock and the
    same binary type handlers. This is a behavior we tend to discourage for
    any new filesystems (apart from a few special filesystems such as e.g.
    configfs or debugfs). A umount operation without the filesystem being
    pinned - by e.g. someone holding a file descriptor to an open file -
    should usually result in the destruction of the superblock and all
    associated resources. This makes introspection easier and leads to
    clearly defined, simple and clean semantics. An administrator can rely
    on the fact that a umount will guarantee a clean slate making it
    possible to reinitialize a filesystem. Right now all binary types would
    need to be explicitly deleted before that can happen.
    
    This allows us to remove the heavy-handed calls to simple_pin_fs() and
    simple_release_fs() when creating and deleting binary types. This in
    turn allows us to replace the current brittle pinning mechanism abusing
    dget() which has caused a range of bugs judging from prior fixes in [2]
    and [3]. The additional dget() in load_misc_binary() pins the dentry but
    only does so for the sake to prevent ->evict_inode() from freeing the
    node when a user removes the binary type and kill_node() is run. Which
    would mean ->interpreter and ->interp_file would be freed causing a UAF.
    
    This isn't really nicely documented nor is it very clean because it
    relies on simple_pin_fs() pinning the filesystem as long as at least one
    binary type exists. Otherwise it would cause load_misc_binary() to hold
    on to a dentry belonging to a superblock that has been shutdown.
    Replace that implicit pinning with a clean and simple per-node refcount
    and get rid of the ugly dget() pinning. A similar mechanism exists for
    e.g. binderfs (cf. [4]). All the cleanup work can now be done in
    ->evict_inode().
    
    In a follow-up patch we will make it possible to use binfmt_misc in
    sandboxes. We will use the cleaner semantics where a umount for the
    filesystem will cause the superblock and all resources to be
    deallocated. In preparation for this apply the same semantics to the
    initial binfmt_misc mount. Note, that this is a user-visible change and
    as such a uapi change but one that we can reasonably risk. We've
    discussed this in earlier versions of this patchset (cf. [1]).
    
    The main user and provider of binfmt_misc is systemd. Systemd provides
    binfmt_misc via autofs since it is configurable as a kernel module and
    is used by a few exotic packages and users. As such a binfmt_misc mount
    is triggered when /proc/sys/fs/binfmt_misc is accessed and is only
    provided on demand. Other autofs on demand filesystems include EFI ESP
    which systemd umounts if the mountpoint stays idle for a certain amount
    of time. This doesn't apply to the binfmt_misc autofs mount which isn't
    touched once it is mounted meaning this change can't accidently wipe
    binary type handlers without someone having explicitly unmounted
    binfmt_misc. After speaking to systemd folks they don't expect this
    change to affect them.
    
    In line with our general policy, if we see a regression for systemd or
    other users with this change we will switch back to the old behavior for
    the initial binfmt_misc mount and have binary types pin the filesystem
    again. But while we touch this code let's take the chance and let's
    improve on the status quo.
    
    [1]: https://lore.kernel.org/r/20191216091220.465626-2-laurent@vivier.eu
    [2]: commit 43a4f2619038 ("exec: binfmt_misc: fix race between load_misc_binary() and kill_node()"
    [3]: commit 83f918274e4b ("exec: binfmt_misc: shift filp_close(interp_file) from kill_node() to bm_evict_inode()")
    [4]: commit f0fe2c0f050d ("binder: prevent UAF for binderfs devices II")
    
    Link: https://lore.kernel.org/r/20211028103114.2849140-1-brauner@kernel.org (v1)
    Cc: Sargun Dhillon <sargun@sargun.me>
    Cc: Serge Hallyn <serge@hallyn.com>
    Cc: Jann Horn <jannh@google.com>
    Cc: Henning Schild <henning.schild@siemens.com>
    Cc: Andrei Vagin <avagin@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Laurent Vivier <laurent@vivier.eu>
    Cc: linux-fsdevel@vger.kernel.org
    Acked-by: Serge Hallyn <serge@hallyn.com>
    Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bitmap: introduce generic optimized bitmap_size() [+ + +]
Author: Alexander Lobakin <aleksander.lobakin@intel.com>
Date:   Wed Mar 27 16:23:49 2024 +0100

    bitmap: introduce generic optimized bitmap_size()
    
    commit a37fbe666c016fd89e4460d0ebfcea05baba46dc upstream.
    
    The number of times yet another open coded
    `BITS_TO_LONGS(nbits) * sizeof(long)` can be spotted is huge.
    Some generic helper is long overdue.
    
    Add one, bitmap_size(), but with one detail.
    BITS_TO_LONGS() uses DIV_ROUND_UP(). The latter works well when both
    divident and divisor are compile-time constants or when the divisor
    is not a pow-of-2. When it is however, the compilers sometimes tend
    to generate suboptimal code (GCC 13):
    
    48 83 c0 3f             add    $0x3f,%rax
    48 c1 e8 06             shr    $0x6,%rax
    48 8d 14 c5 00 00 00 00 lea    0x0(,%rax,8),%rdx
    
    %BITS_PER_LONG is always a pow-2 (either 32 or 64), but GCC still does
    full division of `nbits + 63` by it and then multiplication by 8.
    Instead of BITS_TO_LONGS(), use ALIGN() and then divide by 8. GCC:
    
    8d 50 3f                lea    0x3f(%rax),%edx
    c1 ea 03                shr    $0x3,%edx
    81 e2 f8 ff ff 1f       and    $0x1ffffff8,%edx
    
    Now it shifts `nbits + 63` by 3 positions (IOW performs fast division
    by 8) and then masks bits[2:0]. bloat-o-meter:
    
    add/remove: 0/0 grow/shrink: 20/133 up/down: 156/-773 (-617)
    
    Clang does it better and generates the same code before/after starting
    from -O1, except that with the ALIGN() approach it uses %edx and thus
    still saves some bytes:
    
    add/remove: 0/0 grow/shrink: 9/133 up/down: 18/-538 (-520)
    
    Note that we can't expand DIV_ROUND_UP() by adding a check and using
    this approach there, as it's used in array declarations where
    expressions are not allowed.
    Add this helper to tools/ as well.
    
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Acked-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
block: use "unsigned long" for blk_validate_block_size(). [+ + +]
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date:   Sat Dec 18 18:41:56 2021 +0900

    block: use "unsigned long" for blk_validate_block_size().
    
    commit 37ae5a0f5287a52cf51242e76ccf198d02ffe495 upstream.
    
    Since lo_simple_ioctl(LOOP_SET_BLOCK_SIZE) and ioctl(NBD_SET_BLKSIZE) pass
    user-controlled "unsigned long arg" to blk_validate_block_size(),
    "unsigned long" should be used for validation.
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/9ecbf057-4375-c2db-ab53-e4cc0dff953d@i-love.sakura.ne.jp
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: David Hunter <david.hunter.linux@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Bluetooth: bnep: Fix out-of-bound access [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Feb 28 12:11:08 2024 -0500

    Bluetooth: bnep: Fix out-of-bound access
    
    [ Upstream commit 0f0639b4d6f649338ce29c62da3ec0787fa08cd1 ]
    
    This fixes attempting to access past ethhdr.h_source, although it seems
    intentional to copy also the contents of h_proto this triggers
    out-of-bound access problems with the likes of static analyzer, so this
    instead just copy ETH_ALEN and then proceed to use put_unaligned to copy
    h_proto separetely.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_core: Fix LE quote calculation [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Aug 12 11:22:08 2024 -0400

    Bluetooth: hci_core: Fix LE quote calculation
    
    [ Upstream commit 932021a11805b9da4bd6abf66fe233cccd59fe0e ]
    
    Function hci_sched_le needs to update the respective counter variable
    inplace other the likes of hci_quote_sent would attempt to use the
    possible outdated value of conn->{le_cnt,acl_cnt}.
    
    Link: https://github.com/bluez/bluez/issues/915
    Fixes: 73d80deb7bdf ("Bluetooth: prioritizing data over HCI")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_ldisc: check HCI_UART_PROTO_READY flag in HCIUARTGETPROTO [+ + +]
Author: Lee, Chun-Yi <joeyli.kernel@gmail.com>
Date:   Mon Jul 10 23:17:23 2023 +0800

    Bluetooth: hci_ldisc: check HCI_UART_PROTO_READY flag in HCIUARTGETPROTO
    
    commit 9c33663af9ad115f90c076a1828129a3fbadea98 upstream.
    
    This patch adds code to check HCI_UART_PROTO_READY flag before
    accessing hci_uart->proto. It fixes the race condition in
    hci_uart_tty_ioctl() between HCIUARTSETPROTO and HCIUARTGETPROTO.
    This issue bug found by Yu Hao and Weiteng Chen:
    
    BUG: general protection fault in hci_uart_tty_ioctl [1]
    
    The information of C reproducer can also reference the link [2]
    
    Reported-by: Yu Hao <yhao016@ucr.edu>
    Closes: https://lore.kernel.org/all/CA+UBctC3p49aTgzbVgkSZ2+TQcqq4fPDO7yZitFT5uBPDeCO2g@mail.gmail.com/ [1]
    Reported-by: Weiteng Chen <wchen130@ucr.edu>
    Closes: https://lore.kernel.org/lkml/CA+UBctDPEvHdkHMwD340=n02rh+jNRJNNQ5LBZNA+Wm4Keh2ow@mail.gmail.com/T/ [2]
    Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: MGMT: Add error handling to pair_device() [+ + +]
Author: Griffin Kroah-Hartman <griffin@kroah.com>
Date:   Thu Aug 15 13:51:00 2024 +0200

    Bluetooth: MGMT: Add error handling to pair_device()
    
    commit 538fd3921afac97158d4177139a0ad39f056dbb2 upstream.
    
    hci_conn_params_add() never checks for a NULL value and could lead to a NULL
    pointer dereference causing a crash.
    
    Fixed by adding error handling in the function.
    
    Cc: Stable <stable@kernel.org>
    Fixes: 5157b8a503fa ("Bluetooth: Fix initializing conn_params in scan phase")
    Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
    Reported-by: Yiwei Zhang <zhan4630@purdue.edu>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: SMP: Fix assumption of Central always being Initiator [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Aug 30 15:08:06 2023 -0700

    Bluetooth: SMP: Fix assumption of Central always being Initiator
    
    [ Upstream commit 28cd47f75185c4818b0fb1b46f2f02faaba96376 ]
    
    SMP initiator role shall be considered the one that initiates the
    pairing procedure with SMP_CMD_PAIRING_REQ:
    
    BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part H
    page 1557:
    
    Figure 2.1: LE pairing phases
    
    Note that by sending SMP_CMD_SECURITY_REQ it doesn't change the role to
    be Initiator.
    
    Link: https://github.com/bluez/bluez/issues/567
    Fixes: b28b4943660f ("Bluetooth: Add strict checks for allowed SMP PDUs")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bonding: fix bond_ipsec_offload_ok return type [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Fri Aug 16 14:48:10 2024 +0300

    bonding: fix bond_ipsec_offload_ok return type
    
    [ Upstream commit fc59b9a5f7201b9f7272944596113a82cc7773d5 ]
    
    Fix the return type which should be bool.
    
    Fixes: 955b785ec6b3 ("bonding: fix suspicious RCU usage in bond_ipsec_offload_ok()")
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bonding: fix null pointer deref in bond_ipsec_offload_ok [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Fri Aug 16 14:48:11 2024 +0300

    bonding: fix null pointer deref in bond_ipsec_offload_ok
    
    [ Upstream commit 95c90e4ad89d493a7a14fa200082e466e2548f9d ]
    
    We must check if there is an active slave before dereferencing the pointer.
    
    Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bonding: fix xfrm real_dev null pointer dereference [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Fri Aug 16 14:48:12 2024 +0300

    bonding: fix xfrm real_dev null pointer dereference
    
    [ Upstream commit f8cde9805981c50d0c029063dc7d82821806fc44 ]
    
    We shouldn't set real_dev to NULL because packets can be in transit and
    xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume
    real_dev is set.
    
     Example trace:
     kernel: BUG: unable to handle page fault for address: 0000000000001030
     kernel: bond0: (slave eni0np1): making interface the new active one
     kernel: #PF: supervisor write access in kernel mode
     kernel: #PF: error_code(0x0002) - not-present page
     kernel: PGD 0 P4D 0
     kernel: Oops: 0002 [#1] PREEMPT SMP
     kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12
     kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
     kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]
     kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
     kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f
     kernel: bond0: (slave eni0np1): making interface the new active one
     kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246
     kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
     kernel:
     kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60
     kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00
     kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014
     kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000
     kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000
     kernel: FS:  00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000
     kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0
     kernel: bond0: (slave eni0np1): making interface the new active one
     kernel: Call Trace:
     kernel:  <TASK>
     kernel:  ? __die+0x1f/0x60
     kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
     kernel:  ? page_fault_oops+0x142/0x4c0
     kernel:  ? do_user_addr_fault+0x65/0x670
     kernel:  ? kvm_read_and_reset_apf_flags+0x3b/0x50
     kernel: bond0: (slave eni0np1): making interface the new active one
     kernel:  ? exc_page_fault+0x7b/0x180
     kernel:  ? asm_exc_page_fault+0x22/0x30
     kernel:  ? nsim_bpf_uninit+0x50/0x50 [netdevsim]
     kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
     kernel:  ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim]
     kernel: bond0: (slave eni0np1): making interface the new active one
     kernel:  bond_ipsec_offload_ok+0x7b/0x90 [bonding]
     kernel:  xfrm_output+0x61/0x3b0
     kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
     kernel:  ip_push_pending_frames+0x56/0x80
    
    Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bonding: fix xfrm state handling when clearing active slave [+ + +]
Author: Nikolay Aleksandrov <razor@blackwall.org>
Date:   Fri Aug 16 14:48:13 2024 +0300

    bonding: fix xfrm state handling when clearing active slave
    
    [ Upstream commit c4c5c5d2ef40a9f67a9241dc5422eac9ffe19547 ]
    
    If the active slave is cleared manually the xfrm state is not flushed.
    This leads to xfrm add/del imbalance and adding the same state multiple
    times. For example when the device cannot handle anymore states we get:
     [ 1169.884811] bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA
    because it's filled with the same state after multiple active slave
    clearings. This change also has a few nice side effects: user-space
    gets a notification for the change, the old device gets its mac address
    and promisc/mcast adjusted properly.
    
    Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
    Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: change BUG_ON to assertion in tree_move_down() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Tue Feb 6 23:06:46 2024 +0100

    btrfs: change BUG_ON to assertion in tree_move_down()
    
    [ Upstream commit 56f335e043ae73c32dbb70ba95488845dc0f1e6e ]
    
    There's only one caller of tree_move_down() that does not pass level 0
    so the assertion is better suited here.
    
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: change BUG_ON to assertion when checking for delayed_node root [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Sat Jan 20 02:26:32 2024 +0100

    btrfs: change BUG_ON to assertion when checking for delayed_node root
    
    [ Upstream commit be73f4448b607e6b7ce41cd8ef2214fdf6e7986f ]
    
    The pointer to root is initialized in btrfs_init_delayed_node(), no need
    to check for it again. Change the BUG_ON to assertion.
    
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: delete pointless BUG_ON check on quota root in btrfs_qgroup_account_extent() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Tue Feb 6 23:20:53 2024 +0100

    btrfs: delete pointless BUG_ON check on quota root in btrfs_qgroup_account_extent()
    
    [ Upstream commit f40a3ea94881f668084f68f6b9931486b1606db0 ]
    
    The BUG_ON is deep in the qgroup code where we can expect that it
    exists. A NULL pointer would cause a crash.
    
    It was added long ago in 550d7a2ed5db35 ("btrfs: qgroup: Add new qgroup
    calculation function btrfs_qgroup_account_extents()."). It maybe made
    sense back then as the quota enable/disable state machine was not that
    robust as it is nowadays, so we can just delete it.
    
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: handle invalid root reference found in may_destroy_subvol() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Wed Jan 24 22:58:01 2024 +0100

    btrfs: handle invalid root reference found in may_destroy_subvol()
    
    [ Upstream commit 6fbc6f4ac1f4907da4fc674251527e7dc79ffbf6 ]
    
    The may_destroy_subvol() looks up a root by a key, allowing to do an
    inexact search when key->offset is -1.  It's never expected to find such
    item, as it would break the allowed range of a root id.
    
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: rename bitmap_set_bits() -> btrfs_bitmap_set_bits() [+ + +]
Author: Alexander Lobakin <aleksander.lobakin@intel.com>
Date:   Wed Mar 27 16:23:47 2024 +0100

    btrfs: rename bitmap_set_bits() -> btrfs_bitmap_set_bits()
    
    commit 4ca532d64648d4776d15512caed3efea05ca7195 upstream.
    
    bitmap_set_bits() does not start with the FS' prefix and may collide
    with a new generic helper one day. It operates with the FS-specific
    types, so there's no change those two could do the same thing.
    Just add the prefix to exclude such possible conflict.
    
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Acked-by: David Sterba <dsterba@suse.com>
    Reviewed-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: run delayed iputs when flushing delalloc [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 15:53:18 2024 -0400

    btrfs: run delayed iputs when flushing delalloc
    
    commit 2d3447261031503b181dacc549fe65ffe2d93d65 upstream.
    
    We have transient failures with btrfs/301, specifically in the part
    where we do
    
      for i in $(seq 0 10); do
              write 50m to file
              rm -f file
      done
    
    Sometimes this will result in a transient quota error, and it's because
    sometimes we start writeback on the file which results in a delayed
    iput, and thus the rm doesn't actually clean the file up.  When we're
    flushing the quota space we need to run the delayed iputs to make sure
    all the unlinks that we think have completed have actually completed.
    This removes the small window where we could fail to find enough space
    in our quota.
    
    CC: stable@vger.kernel.org # 5.15+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: send: handle unexpected data in header buffer in begin_cmd() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Tue Feb 6 22:47:13 2024 +0100

    btrfs: send: handle unexpected data in header buffer in begin_cmd()
    
    [ Upstream commit e80e3f732cf53c64b0d811e1581470d67f6c3228 ]
    
    Change BUG_ON to a proper error handling in the unlikely case of seeing
    data when the command is started. This is supposed to be reset when the
    command is finished (send_cmd, send_encoded_extent).
    
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: tree-checker: add dev extent item checks [+ + +]
Author: Qu Wenruo <wqu@suse.com>
Date:   Sun Aug 11 15:00:22 2024 +0930

    btrfs: tree-checker: add dev extent item checks
    
    commit 008e2512dc5696ab2dc5bf264e98a9fe9ceb830e upstream.
    
    [REPORT]
    There is a corruption report that btrfs refused to mount a fs that has
    overlapping dev extents:
    
      BTRFS error (device sdc): dev extent devid 4 physical offset 14263979671552 overlap with previous dev extent end 14263980982272
      BTRFS error (device sdc): failed to verify dev extents against chunks: -117
      BTRFS error (device sdc): open_ctree failed
    
    [CAUSE]
    The direct cause is very obvious, there is a bad dev extent item with
    incorrect length.
    
    With btrfs check reporting two overlapping extents, the second one shows
    some clue on the cause:
    
      ERROR: dev extent devid 4 offset 14263979671552 len 6488064 overlap with previous dev extent end 14263980982272
      ERROR: dev extent devid 13 offset 2257707008000 len 6488064 overlap with previous dev extent end 2257707270144
      ERROR: errors found in extent allocation tree or chunk allocation
    
    The second one looks like a bitflip happened during new chunk
    allocation:
    hex(2257707008000) = 0x20da9d30000
    hex(2257707270144) = 0x20da9d70000
    diff               = 0x00000040000
    
    So it looks like a bitflip happened during new dev extent allocation,
    resulting the second overlap.
    
    Currently we only do the dev-extent verification at mount time, but if the
    corruption is caused by memory bitflip, we really want to catch it before
    writing the corruption to the storage.
    
    Furthermore the dev extent items has the following key definition:
    
            (<device id> DEV_EXTENT <physical offset>)
    
    Thus we can not just rely on the generic key order check to make sure
    there is no overlapping.
    
    [ENHANCEMENT]
    Introduce dedicated dev extent checks, including:
    
    - Fixed member checks
      * chunk_tree should always be BTRFS_CHUNK_TREE_OBJECTID (3)
      * chunk_objectid should always be
        BTRFS_FIRST_CHUNK_CHUNK_TREE_OBJECTID (256)
    
    - Alignment checks
      * chunk_offset should be aligned to sectorsize
      * length should be aligned to sectorsize
      * key.offset should be aligned to sectorsize
    
    - Overlap checks
      If the previous key is also a dev-extent item, with the same
      device id, make sure we do not overlap with the previous dev extent.
    
    Reported: Stefan N <stefannnau@gmail.com>
    Link: https://lore.kernel.org/linux-btrfs/CA+W5K0rSO3koYTo=nzxxTm1-Pdu1HYgVxEpgJ=aGc7d=E8mGEg@mail.gmail.com/
    CC: stable@vger.kernel.org # 5.10+
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cdc-acm: Add DISABLE_ECHO quirk for GE HealthCare UI Controller [+ + +]
Author: Ian Ray <ian.ray@gehealthcare.com>
Date:   Wed Aug 14 10:29:05 2024 +0300

    cdc-acm: Add DISABLE_ECHO quirk for GE HealthCare UI Controller
    
    commit 0b00583ecacb0b51712a5ecd34cf7e6684307c67 upstream.
    
    USB_DEVICE(0x1901, 0x0006) may send data before cdc_acm is ready, which
    may be misinterpreted in the default N_TTY line discipline.
    
    Signed-off-by: Ian Ray <ian.ray@gehealthcare.com>
    Acked-by: Oliver Neuku <oneukum@suse.com>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/20240814072905.2501-1-ian.ray@gehealthcare.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cgroup/cpuset: Prevent UAF in proc_cpuset_show() [+ + +]
Author: Chen Ridong <chenridong@huawei.com>
Date:   Fri Jun 28 01:36:04 2024 +0000

    cgroup/cpuset: Prevent UAF in proc_cpuset_show()
    
    commit 1be59c97c83ccd67a519d8a49486b3a8a73ca28a upstream.
    
    An UAF can happen when /proc/cpuset is read as reported in [1].
    
    This can be reproduced by the following methods:
    1.add an mdelay(1000) before acquiring the cgroup_lock In the
     cgroup_path_ns function.
    2.$cat /proc/<pid>/cpuset   repeatly.
    3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/
    $umount /sys/fs/cgroup/cpuset/   repeatly.
    
    The race that cause this bug can be shown as below:
    
    (umount)                |       (cat /proc/<pid>/cpuset)
    css_release             |       proc_cpuset_show
    css_release_work_fn     |       css = task_get_css(tsk, cpuset_cgrp_id);
    css_free_rwork_fn       |       cgroup_path_ns(css->cgroup, ...);
    cgroup_destroy_root     |       mutex_lock(&cgroup_mutex);
    rebind_subsystems       |
    cgroup_free_root        |
                            |       // cgrp was freed, UAF
                            |       cgroup_path_ns_locked(cgrp,..);
    
    When the cpuset is initialized, the root node top_cpuset.css.cgrp
    will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will
    allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated
    &cgroup_root.cgrp. When the umount operation is executed,
    top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp.
    
    The problem is that when rebinding to cgrp_dfl_root, there are cases
    where the cgroup_root allocated by setting up the root for cgroup v1
    is cached. This could lead to a Use-After-Free (UAF) if it is
    subsequently freed. The descendant cgroups of cgroup v1 can only be
    freed after the css is released. However, the css of the root will never
    be released, yet the cgroup_root should be freed when it is unmounted.
    This means that obtaining a reference to the css of the root does
    not guarantee that css.cgrp->root will not be freed.
    
    Fix this problem by using rcu_read_lock in proc_cpuset_show().
    As cgroup_root is kfree_rcu after commit d23b5c577715
    ("cgroup: Make operations on the cgroup root_list RCU safe"),
    css->cgroup won't be freed during the critical section.
    To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to
    replace task_get_css with task_css.
    
    [1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd
    
    Fixes: a79a908fd2b0 ("cgroup: introduce cgroup namespaces")
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
char: xillybus: Check USB endpoints when probing device [+ + +]
Author: Eli Billauer <eli.billauer@gmail.com>
Date:   Fri Aug 16 10:02:00 2024 +0300

    char: xillybus: Check USB endpoints when probing device
    
    commit 2374bf7558de915edc6ec8cb10ec3291dfab9594 upstream.
    
    Ensure, as the driver probes the device, that all endpoints that the
    driver may attempt to access exist and are of the correct type.
    
    All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at
    address 1. This is verified in xillyusb_setup_base_eps().
    
    On top of that, a XillyUSB device may have additional Bulk OUT
    endpoints. The information about these endpoints' addresses is deduced
    from a data structure (the IDT) that the driver fetches from the device
    while probing it. These endpoints are checked in setup_channels().
    
    A XillyUSB device never has more than one IN endpoint, as all data
    towards the host is multiplexed in this single Bulk IN endpoint. This is
    why setup_channels() only checks OUT endpoints.
    
    Reported-by: syzbot+eac39cba052f2e750dbe@syzkaller.appspotmail.com
    Cc: stable <stable@kernel.org>
    Closes: https://lore.kernel.org/all/0000000000001d44a6061f7a54ee@google.com/T/
    Fixes: a53d1202aef1 ("char: xillybus: Add driver for XillyUSB (Xillybus variant for USB)").
    Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
    Link: https://lore.kernel.org/r/20240816070200.50695-2-eli.billauer@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

char: xillybus: Don't destroy workqueue from work item running on it [+ + +]
Author: Eli Billauer <eli.billauer@gmail.com>
Date:   Thu Aug 1 15:11:26 2024 +0300

    char: xillybus: Don't destroy workqueue from work item running on it
    
    commit ccbde4b128ef9c73d14d0d7817d68ef795f6d131 upstream.
    
    Triggered by a kref decrement, destroy_workqueue() may be called from
    within a work item for destroying its own workqueue. This illegal
    situation is averted by adding a module-global workqueue for exclusive
    use of the offending work item. Other work items continue to be queued
    on per-device workqueues to ensure performance.
    
    Reported-by: syzbot+91dbdfecdd3287734d8e@syzkaller.appspotmail.com
    Cc: stable <stable@kernel.org>
    Closes: https://lore.kernel.org/lkml/0000000000000ab25a061e1dfe9f@google.com/
    Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
    Link: https://lore.kernel.org/r/20240801121126.60183-1-eli.billauer@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

char: xillybus: Refine workqueue handling [+ + +]
Author: Eli Billauer <eli.billauer@gmail.com>
Date:   Fri Aug 16 10:01:59 2024 +0300

    char: xillybus: Refine workqueue handling
    
    commit ad899c301c880766cc709aad277991b3ab671b66 upstream.
    
    As the wakeup work item now runs on a separate workqueue, it needs to be
    flushed separately along with flushing the device's workqueue.
    
    Also, move the destroy_workqueue() call to the end of the exit method,
    so that deinitialization is done in the opposite order of
    initialization.
    
    Fixes: ccbde4b128ef ("char: xillybus: Don't destroy workqueue from work item running on it")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
    Link: https://lore.kernel.org/r/20240816070200.50695-1-eli.billauer@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
clocksource/drivers/arm_global_timer: Guard against division by zero [+ + +]
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date:   Sun Feb 25 16:13:35 2024 +0100

    clocksource/drivers/arm_global_timer: Guard against division by zero
    
    [ Upstream commit e651f2fae33634175fae956d896277cf916f5d09 ]
    
    The result of the division of new_rate by gt_target_rate can be zero (if
    new_rate is smaller than gt_target_rate). Using that result as divisor
    without checking can result in a division by zero error. Guard against
    this by checking for a zero value earlier.
    While here, also change the psv variable to an unsigned long to make
    sure we don't overflow the datatype as all other types involved are also
    unsiged long.
    
    Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20240225151336.2728533-3-martin.blumenstingl@googlemail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clocksource: Make watchdog and suspend-timing multiplication overflow safe [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Mon Mar 25 08:40:23 2024 +0200

    clocksource: Make watchdog and suspend-timing multiplication overflow safe
    
    [ Upstream commit d0304569fb019d1bcfbbbce1ce6df6b96f04079b ]
    
    Kernel timekeeping is designed to keep the change in cycles (since the last
    timer interrupt) below max_cycles, which prevents multiplication overflow
    when converting cycles to nanoseconds. However, if timer interrupts stop,
    the clocksource_cyc2ns() calculation will eventually overflow.
    
    Add protection against that. Simplify by folding together
    clocksource_delta() and clocksource_cyc2ns() into cycles_to_nsec_safe().
    Check against max_cycles, falling back to a slower higher precision
    calculation.
    
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20240325064023.2997-20-adrian.hunter@intel.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxgb4: add forgotten u64 ivlan cast before shift [+ + +]
Author: Nikolay Kuratov <kniv@yandex-team.ru>
Date:   Mon Aug 19 10:54:08 2024 +0300

    cxgb4: add forgotten u64 ivlan cast before shift
    
    commit 80a1e7b83bb1834b5568a3872e64c05795d88f31 upstream.
    
    It is done everywhere in cxgb4 code, e.g. in is_filter_exact_match()
    There is no reason it should not be done here
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE
    
    Signed-off-by: Nikolay Kuratov <kniv@yandex-team.ru>
    Cc: stable@vger.kernel.org
    Fixes: 12b276fbf6e0 ("cxgb4: add support to create hash filters")
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Link: https://patch.msgid.link/20240819075408.92378-1-kniv@yandex-team.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm persistent data: fix memory allocation failure [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Aug 13 16:35:14 2024 +0200

    dm persistent data: fix memory allocation failure
    
    commit faada2174c08662ae98b439c69efe3e79382c538 upstream.
    
    kmalloc is unreliable when allocating more than 8 pages of memory. It may
    fail when there is plenty of free memory but the memory is fragmented.
    Zdenek Kabelac observed such failure in his tests.
    
    This commit changes kmalloc to kvmalloc - kvmalloc will fall back to
    vmalloc if the large allocation fails.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
    Reviewed-by: Mike Snitzer <snitzer@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm resume: don't return EINVAL when signalled [+ + +]
Author: Khazhismel Kumykov <khazhy@google.com>
Date:   Tue Aug 13 12:39:52 2024 +0200

    dm resume: don't return EINVAL when signalled
    
    commit 7a636b4f03af9d541205f69e373672e7b2b60a8a upstream.
    
    If the dm_resume method is called on a device that is not suspended, the
    method will suspend the device briefly, before resuming it (so that the
    table will be swapped).
    
    However, there was a bug that the return value of dm_suspended_md was not
    checked. dm_suspended_md may return an error when it is interrupted by a
    signal. In this case, do_resume would call dm_swap_table, which would
    return -EINVAL.
    
    This commit fixes the logic, so that error returned by dm_suspend is
    checked and the resume operation is undone.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Khazhismel Kumykov <khazhy@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm suspend: return -ERESTARTSYS instead of -EINTR [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Tue Aug 13 12:38:51 2024 +0200

    dm suspend: return -ERESTARTSYS instead of -EINTR
    
    [ Upstream commit 1e1fd567d32fcf7544c6e09e0e5bc6c650da6e23 ]
    
    This commit changes device mapper, so that it returns -ERESTARTSYS
    instead of -EINTR when it is interrupted by a signal (so that the ioctl
    can be restarted).
    
    The manpage signal(7) says that the ioctl function should be restarted if
    the signal was handled with SA_RESTART.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: dw: Add memory bus width verification [+ + +]
Author: Serge Semin <fancer.lancer@gmail.com>
Date:   Fri Aug 2 10:50:47 2024 +0300

    dmaengine: dw: Add memory bus width verification
    
    [ Upstream commit d04b21bfa1c50a2ade4816cab6fdc91827b346b1 ]
    
    Currently in case of the DEV_TO_MEM or MEM_TO_DEV DMA transfers the memory
    data width (single transfer width) is determined based on the buffer
    length, buffer base address or DMA master-channel max address width
    capability. It isn't enough in case of the channel disabling prior the
    block transfer is finished. Here is what DW AHB DMA IP-core databook says
    regarding the port suspension (DMA-transfer pause) implementation in the
    controller:
    
    "When CTLx.SRC_TR_WIDTH < CTLx.DST_TR_WIDTH and the CFGx.CH_SUSP bit is
    high, the CFGx.FIFO_EMPTY is asserted once the contents of the FIFO do not
    permit a single word of CTLx.DST_TR_WIDTH to be formed. However, there may
    still be data in the channel FIFO, but not enough to form a single
    transfer of CTLx.DST_TR_WIDTH. In this scenario, once the channel is
    disabled, the remaining data in the channel FIFO is not transferred to the
    destination peripheral."
    
    So in case if the port gets to be suspended and then disabled it's
    possible to have the data silently discarded even though the controller
    reported that FIFO is empty and the CTLx.BLOCK_TS indicated the dropped
    data already received from the source device. This looks as if the data
    somehow got lost on a way from the peripheral device to memory and causes
    problems for instance in the DW APB UART driver, which pauses and disables
    the DMA-transfer as soon as the recv data timeout happens. Here is the way
    it looks:
    
     Memory <------- DMA FIFO <------ UART FIFO <---------------- UART
      DST_TR_WIDTH -+--------|       |         |
                    |        |       |         |                No more data
       Current lvl -+--------|       |---------+- DMA-burst lvl
                    |        |       |---------+- Leftover data
                    |        |       |---------+- SRC_TR_WIDTH
                   -+--------+-------+---------+
    
    In the example above: no more data is getting received over the UART port
    and BLOCK_TS is not even close to be fully received; some data is left in
    the UART FIFO, but not enough to perform a bursted DMA-xfer to the DMA
    FIFO; some data is left in the DMA FIFO, but not enough to be passed
    further to the system memory in a single transfer. In this situation the
    8250 UART driver catches the recv timeout interrupt, pauses the
    DMA-transfer and terminates it completely, after which the IRQ handler
    manually fetches the leftover data from the UART FIFO into the
    recv-buffer. But since the DMA-channel has been disabled with the data
    left in the DMA FIFO, that data will be just discarded and the recv-buffer
    will have a gap of the "current lvl" size in the recv-buffer at the tail
    of the lately received data portion. So the data will be lost just due to
    the misconfigured DMA transfer.
    
    Note this is only relevant for the case of the transfer suspension and
    _disabling_. No problem will happen if the transfer will be re-enabled
    afterwards or the block transfer is fully completed. In the later case the
    "FIFO flush mode" will be executed at the transfer final stage in order to
    push out the data left in the DMA FIFO.
    
    In order to fix the denoted problem the DW AHB DMA-engine driver needs to
    make sure that the _bursted_ source transfer width is greater or equal to
    the single destination transfer (note the HW databook describes more
    strict constraint than actually required). Since the peripheral-device
    side is prescribed by the client driver logic, the memory-side can be only
    used for that. The solution can be easily implemented for the DEV_TO_MEM
    transfers just by adjusting the memory-channel address width. Sadly it's
    not that easy for the MEM_TO_DEV transfers since the mem-to-dma burst size
    is normally dynamically determined by the controller. So the only thing
    that can be done is to make sure that memory-side address width is greater
    than the peripheral device address width.
    
    Fixes: a09820043c9e ("dw_dmac: autoconfigure data_width or get it via platform data")
    Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
    Acked-by: Andy Shevchenko <andy@kernel.org>
    Link: https://lore.kernel.org/r/20240802075100.6475-3-fancer.lancer@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: dw: Add peripheral bus width verification [+ + +]
Author: Serge Semin <fancer.lancer@gmail.com>
Date:   Fri Aug 2 10:50:46 2024 +0300

    dmaengine: dw: Add peripheral bus width verification
    
    [ Upstream commit b336268dde75cb09bd795cb24893d52152a9191f ]
    
    Currently the src_addr_width and dst_addr_width fields of the
    dma_slave_config structure are mapped to the CTLx.SRC_TR_WIDTH and
    CTLx.DST_TR_WIDTH fields of the peripheral bus side in order to have the
    properly aligned data passed to the target device. It's done just by
    converting the passed peripheral bus width to the encoded value using the
    __ffs() function. This implementation has several problematic sides:
    
    1. __ffs() is undefined if no bit exist in the passed value. Thus if the
    specified addr-width is DMA_SLAVE_BUSWIDTH_UNDEFINED, __ffs() may return
    unexpected value depending on the platform-specific implementation.
    
    2. DW AHB DMA-engine permits having the power-of-2 transfer width limited
    by the DMAH_Mk_HDATA_WIDTH IP-core synthesize parameter. Specifying
    bus-width out of that constraints scope will definitely cause unexpected
    result since the destination reg will be only partly touched than the
    client driver implied.
    
    Let's fix all of that by adding the peripheral bus width verification
    method and calling it in dwc_config() which is supposed to be executed
    before preparing any transfer. The new method will make sure that the
    passed source or destination address width is valid and if undefined then
    the driver will just fallback to the 1-byte width transfer.
    
    Fixes: 029a40e97d0d ("dmaengine: dw: provide DMA capabilities")
    Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
    Acked-by: Andy Shevchenko <andy@kernel.org>
    Link: https://lore.kernel.org/r/20240802075100.6475-2-fancer.lancer@gmail.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dpaa2-switch: Fix error checking in dpaa2_switch_seed_bp() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Sat Aug 17 09:52:46 2024 +0300

    dpaa2-switch: Fix error checking in dpaa2_switch_seed_bp()
    
    [ Upstream commit c50e7475961c36ec4d21d60af055b32f9436b431 ]
    
    The dpaa2_switch_add_bufs() function returns the number of bufs that it
    was able to add.  It returns BUFS_PER_CMD (7) for complete success or a
    smaller number if there are not enough pages available.  However, the
    error checking is looking at the total number of bufs instead of the
    number which were added on this iteration.  Thus the error checking
    only works correctly for the first iteration through the loop and
    subsequent iterations are always counted as a success.
    
    Fix this by checking only the bufs added in the current iteration.
    
    Fixes: 0b1b71370458 ("staging: dpaa2-switch: handle Rx path on control interface")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
    Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com>
    Link: https://patch.msgid.link/eec27f30-b43f-42b6-b8ee-04a6f83423b6@stanley.mountain
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amd/display: Validate hw_points_num before using it [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Mon Jul 10 18:23:58 2023 -0600

    drm/amd/display: Validate hw_points_num before using it
    
    [ Upstream commit 58c3b3341cea4f75dc8c003b89f8a6dd8ec55e50 ]
    
    [WHAT]
    hw_points_num is 0 before ogam LUT is programmed; however, function
    "dwb3_program_ogam_pwl" assumes hw_points_num is always greater than 0,
    i.e. substracting it by 1 as an array index.
    
    [HOW]
    Check hw_points_num is not equal to 0 before using it.
    
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu/jpeg2: properly set atomics vmid field [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Jul 12 10:00:33 2024 -0400

    drm/amdgpu/jpeg2: properly set atomics vmid field
    
    commit e414a304f2c5368a84f03ad34d29b89f965a33c9 upstream.
    
    This needs to be set as well if the IB uses atomics.
    
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit 35c628774e50b3784c59e8ca7973f03bcb067132)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdgpu: Actually check flags for all context ops. [+ + +]
Author: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Date:   Tue Aug 6 22:27:32 2024 +0200

    drm/amdgpu: Actually check flags for all context ops.
    
    commit 0573a1e2ea7e35bff08944a40f1adf2bb35cea61 upstream.
    
    Missing validation ...
    
    Checked libdrm and it clears all the structs, so we should be
    safe to just check everything.
    
    Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit c6b86421f1f9ddf9d706f2453159813ee39d0cf9)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc [+ + +]
Author: Jesse Zhang <jesse.zhang@amd.com>
Date:   Wed Apr 24 17:10:46 2024 +0800

    drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc
    
    commit 88a9a467c548d0b3c7761b4fd54a68e70f9c0944 upstream.
    
    Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.
    V2: To really improve the handling we would actually
       need to have a separate value of 0xffffffff.(Christian)
    
    Signed-off-by: Jesse Zhang <jesse.zhang@amd.com>
    Suggested-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Vamsi Krishna Brahmajosyula <vamsi-krishna.brahmajosyula@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amdkfd: don't allow mapping the MMIO HDP page with large pages [+ + +]
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Sun Apr 14 13:06:39 2024 -0400

    drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
    
    commit be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7 upstream.
    
    We don't get the right offset in that case.  The GPU has
    an unused 4K area of the register BAR space into which you can
    remap registers.  We remap the HDP flush registers into this
    space to allow userspace (CPU or GPU) to flush the HDP when it
    updates VRAM.  However, on systems with >4K pages, we end up
    exposing PAGE_SIZE of MMIO space.
    
    Fixes: d8e408a82704 ("drm/amdkfd: Expose HDP registers to user space")
    Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Felix Kuehling <felix.kuehling@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/lima: set gp bus_stop bit before hard reset [+ + +]
Author: Erico Nunes <nunes.erico@gmail.com>
Date:   Wed Jan 24 03:59:43 2024 +0100

    drm/lima: set gp bus_stop bit before hard reset
    
    [ Upstream commit 27aa58ec85f973d98d336df7b7941149308db80f ]
    
    This is required for reliable hard resets. Otherwise, doing a hard reset
    while a task is still running (such as a task which is being stopped by
    the drm_sched timeout handler) may result in random mmu write timeouts
    or lockups which cause the entire gpu to hang.
    
    Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
    Signed-off-by: Qiang Yu <yuq825@gmail.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240124025947.2110659-5-nunes.erico@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dp: reset the link phy params before link training [+ + +]
Author: Abhinav Kumar <quic_abhinavk@quicinc.com>
Date:   Thu Jul 25 15:04:50 2024 -0700

    drm/msm/dp: reset the link phy params before link training
    
    [ Upstream commit 319aca883bfa1b85ee08411541b51b9a934ac858 ]
    
    Before re-starting link training reset the link phy params namely
    the pre-emphasis and voltage swing levels otherwise the next
    link training begins at the previously cached levels which can result
    in link training failures.
    
    Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # SM8350-HDK
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Patchwork: https://patchwork.freedesktop.org/patch/605946/
    Link: https://lore.kernel.org/r/20240725220450.131245-1-quic_abhinavk@quicinc.com
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Tue Jun 25 00:13:41 2024 +0300

    drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails
    
    [ Upstream commit bfa1a6283be390947d3649c482e5167186a37016 ]
    
    If the dpu_format_populate_layout() fails, then FB is prepared, but not
    cleaned up. This ends up leaking the pin_count on the GEM object and
    causes a splat during DRM file closure:
    
    msm_obj->pin_count
    WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc
    [...]
    Call trace:
     update_lru_locked+0xc4/0xcc
     put_pages+0xac/0x100
     msm_gem_free_object+0x138/0x180
     drm_gem_object_free+0x1c/0x30
     drm_gem_object_handle_put_unlocked+0x108/0x10c
     drm_gem_object_release_handle+0x58/0x70
     idr_for_each+0x68/0xec
     drm_gem_release+0x28/0x40
     drm_file_free+0x174/0x234
     drm_release+0xb0/0x160
     __fput+0xc0/0x2c8
     __fput_sync+0x50/0x5c
     __arm64_sys_close+0x38/0x7c
     invoke_syscall+0x48/0x118
     el0_svc_common.constprop.0+0x40/0xe0
     do_el0_svc+0x1c/0x28
     el0_svc+0x4c/0x120
     el0t_64_sync_handler+0x100/0x12c
     el0t_64_sync+0x190/0x194
    irq event stamp: 129818
    hardirqs last  enabled at (129817): [<ffffa5f6d953fcc0>] console_unlock+0x118/0x124
    hardirqs last disabled at (129818): [<ffffa5f6da7dcf04>] el1_dbg+0x24/0x8c
    softirqs last  enabled at (129808): [<ffffa5f6d94afc18>] handle_softirqs+0x4c8/0x4e8
    softirqs last disabled at (129785): [<ffffa5f6d94105e4>] __do_softirq+0x14/0x20
    
    Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/600714/
    Link: https://lore.kernel.org/r/20240625-dpu-mode-config-width-v5-1-501d984d634f@linaro.org
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/msm/dpu: don't play tricks with debug macros [+ + +]
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri Aug 2 22:47:34 2024 +0300

    drm/msm/dpu: don't play tricks with debug macros
    
    [ Upstream commit df24373435f5899a2a98b7d377479c8d4376613b ]
    
    DPU debugging macros need to be converted to a proper drm_debug_*
    macros, however this is a going an intrusive patch, not suitable for a
    fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER
    to make sure that DPU debugging messages always end up in the drm debug
    messages and are controlled via the usual drm.debug mask.
    
    I don't think that it is a good idea for a generic DPU_DEBUG macro to be
    tied to DRM_UT_KMS. It is used to report a debug message from driver, so by
    default it should go to the DRM_UT_DRIVER channel. While refactoring
    debug macros later on we might end up with particular messages going to
    ATOMIC or KMS, but DRIVER should be the default.
    
    Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/606932/
    Link: https://lore.kernel.org/r/20240802-dpu-fix-wb-v2-2-7eac9eb8e895@linaro.org
    Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ethtool: check device is present when getting link settings [+ + +]
Author: Jamie Bainbridge <jamie.bainbridge@gmail.com>
Date:   Fri Aug 23 16:26:58 2024 +1000

    ethtool: check device is present when getting link settings
    
    [ Upstream commit a699781c79ecf6cfe67fb00a0331b4088c7c8466 ]
    
    A sysfs reader can race with a device reset or removal, attempting to
    read device state when the device is not actually present. eg:
    
         [exception RIP: qed_get_current_link+17]
      #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
      #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
     #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
     #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
     #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
     #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
     #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
     #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
     #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
     #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb
    
     crash> struct net_device.state ffff9a9d21336000
        state = 5,
    
    state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
    The device is not present, note lack of __LINK_STATE_PRESENT (0b10).
    
    This is the same sort of panic as observed in commit 4224cfd7fb65
    ("net-sysfs: add check for netdevice being present to speed_show").
    
    There are many other callers of __ethtool_get_link_ksettings() which
    don't have a device presence check.
    
    Move this check into ethtool to protect all callers.
    
    Fixes: d519e17e2d01 ("net: export device speed and duplex via sysfs")
    Fixes: 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show")
    Signed-off-by: Jamie Bainbridge <jamie.bainbridge@gmail.com>
    Link: https://patch.msgid.link/8bae218864beaa44ed01628140475b9bf641c5b0.1724393671.git.jamie.bainbridge@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: do not trim the group with corrupted block bitmap [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Jan 4 22:20:34 2024 +0800

    ext4: do not trim the group with corrupted block bitmap
    
    [ Upstream commit 172202152a125955367393956acf5f4ffd092e0d ]
    
    Otherwise operating on an incorrupted block bitmap can lead to all sorts
    of unknown problems.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240104142040.2835097-3-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: set the type of max_zeroout to unsigned int to avoid overflow [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Tue Mar 19 19:33:24 2024 +0800

    ext4: set the type of max_zeroout to unsigned int to avoid overflow
    
    [ Upstream commit 261341a932d9244cbcd372a3659428c8723e5a49 ]
    
    The max_zeroout is of type int and the s_extent_max_zeroout_kb is of
    type uint, and the s_extent_max_zeroout_kb can be freely modified via
    the sysfs interface. When the block size is 1024, max_zeroout may
    overflow, so declare it as unsigned int to avoid overflow.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240319113325.3110393-9-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
f2fs: fix to do sanity check in update_sit_entry [+ + +]
Author: Zhiguo Niu <zhiguo.niu@unisoc.com>
Date:   Wed Feb 28 19:59:54 2024 +0800

    f2fs: fix to do sanity check in update_sit_entry
    
    [ Upstream commit 36959d18c3cf09b3c12157c6950e18652067de77 ]
    
    If GET_SEGNO return NULL_SEGNO for some unecpected case,
    update_sit_entry will access invalid memory address,
    cause system crash. It is better to do sanity check about
    GET_SEGNO just like update_segment_mtime & locate_dirty_segment.
    
    Also remove some redundant judgment code.
    
    Signed-off-by: Zhiguo Niu <zhiguo.niu@unisoc.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Aug 3 18:02:00 2024 -0400

    fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE
    
    commit 9a2fa1472083580b6c66bdaf291f591e1170123a upstream.
    
    copy_fd_bitmaps(new, old, count) is expected to copy the first
    count/BITS_PER_LONG bits from old->full_fds_bits[] and fill
    the rest with zeroes.  What it does is copying enough words
    (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.
    That works fine, *if* all bits past the cutoff point are
    clear.  Otherwise we are risking garbage from the last word
    we'd copied.
    
    For most of the callers that is true - expand_fdtable() has
    count equal to old->max_fds, so there's no open descriptors
    past count, let alone fully occupied words in ->open_fds[],
    which is what bits in ->full_fds_bits[] correspond to.
    
    The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),
    which is the smallest multiple of BITS_PER_LONG that covers all
    opened descriptors below max_fds.  In the common case (copying on
    fork()) max_fds is ~0U, so all opened descriptors will be below
    it and we are fine, by the same reasons why the call in expand_fdtable()
    is safe.
    
    Unfortunately, there is a case where max_fds is less than that
    and where we might, indeed, end up with junk in ->full_fds_bits[] -
    close_range(from, to, CLOSE_RANGE_UNSHARE) with
            * descriptor table being currently shared
            * 'to' being above the current capacity of descriptor table
            * 'from' being just under some chunk of opened descriptors.
    In that case we end up with observably wrong behaviour - e.g. spawn
    a child with CLONE_FILES, get all descriptors in range 0..127 open,
    then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending
    up with descriptor #128, despite #64 being observably not open.
    
    The minimally invasive fix would be to deal with that in dup_fd().
    If this proves to add measurable overhead, we can go that way, but
    let's try to fix copy_fd_bitmaps() first.
    
    * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).
    * make copy_fd_bitmaps() take the bitmap size in words, rather than
    bits; it's 'count' argument is always a multiple of BITS_PER_LONG,
    so we are not losing any information, and that way we can use the
    same helper for all three bitmaps - compiler will see that count
    is a multiple of BITS_PER_LONG for the large ones, so it'll generate
    plain memcpy()+memset().
    
    Reproducer added to tools/testing/selftests/core/close_range_test.c
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs/ntfs3: add prefix to bitmap_size() and use BITS_TO_U64() [+ + +]
Author: Alexander Lobakin <aleksander.lobakin@intel.com>
Date:   Wed Mar 27 16:23:46 2024 +0100

    fs/ntfs3: add prefix to bitmap_size() and use BITS_TO_U64()
    
    commit 3f5ef5109f6a054ce58b3bec7214ed76c9cc269f upstream.
    
    bitmap_size() is a pretty generic name and one may want to use it for
    a generic bitmap API function. At the same time, its logic is
    NTFS-specific, as it aligns to the sizeof(u64), not the sizeof(long)
    (although it uses ideologically right ALIGN() instead of division).
    Add the prefix 'ntfs3_' used for that FS (not just 'ntfs_' to not mix
    it with the legacy module) and use generic BITS_TO_U64() while at it.
    
    Suggested-by: Yury Norov <yury.norov@gmail.com> # BITS_TO_U64()
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fs: binfmt_elf_efpic: don't use missing interpreter's properties [+ + +]
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Thu Jan 18 07:06:37 2024 -0800

    fs: binfmt_elf_efpic: don't use missing interpreter's properties
    
    [ Upstream commit 15fd1dc3dadb4268207fa6797e753541aca09a2a ]
    
    Static FDPIC executable may get an executable stack even when it has
    non-executable GNU_STACK segment. This happens when STACK segment has rw
    permissions, but does not specify stack size. In that case FDPIC loader
    uses permissions of the interpreter's stack, and for static executables
    with no interpreter it results in choosing the arch-default permissions
    for the stack.
    
    Fix that by using the interpreter's properties only when the interpreter
    is actually used.
    
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Link: https://lore.kernel.org/r/20240118150637.660461-1-jcmvbkbc@gmail.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fuse: fix UAF in rcu pathwalks [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Thu Sep 28 00:19:39 2023 -0400

    fuse: fix UAF in rcu pathwalks
    
    [ Upstream commit 053fc4f755ad43cf35210677bcba798ccdc48d0c ]
    
    ->permission(), ->get_link() and ->inode_get_acl() might dereference
    ->s_fs_info (and, in case of ->permission(), ->s_fs_info->fc->user_ns
    as well) when called from rcu pathwalk.
    
    Freeing ->s_fs_info->fc is rcu-delayed; we need to make freeing ->s_fs_info
    and dropping ->user_ns rcu-delayed too.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fuse: Initialize beyond-EOF page contents before setting uptodate [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Tue Aug 6 21:51:42 2024 +0200

    fuse: Initialize beyond-EOF page contents before setting uptodate
    
    commit 3c0da3d163eb32f1f91891efaade027fa9b245b9 upstream.
    
    fuse_notify_store(), unlike fuse_do_readpage(), does not enable page
    zeroing (because it can be used to change partial page contents).
    
    So fuse_notify_store() must be more careful to fully initialize page
    contents (including parts of the page that are beyond end-of-file)
    before marking the page uptodate.
    
    The current code can leave beyond-EOF page contents uninitialized, which
    makes these uninitialized page contents visible to userspace via mmap().
    
    This is an information leak, but only affects systems which do not
    enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the
    corresponding kernel command line parameter).
    
    Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2574
    Cc: stable@kernel.org
    Fixes: a1d75f258230 ("fuse: add store request")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
gfs2: setattr_chown: Add missing initialization [+ + +]
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date:   Sat Oct 21 20:51:13 2023 +0200

    gfs2: setattr_chown: Add missing initialization
    
    [ Upstream commit 2d8d7990619878a848b1d916c2f936d3012ee17d ]
    
    Add a missing initialization of variable ap in setattr_chown().
    Without, chown() may be able to bypass quotas.
    
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gtp: fix a potential NULL pointer dereference [+ + +]
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Sun Aug 25 12:16:38 2024 -0700

    gtp: fix a potential NULL pointer dereference
    
    [ Upstream commit defd8b3c37b0f9cb3e0f60f47d3d78d459d57fda ]
    
    When sockfd_lookup() fails, gtp_encap_enable_socket() returns a
    NULL pointer, but its callers only check for error pointers thus miss
    the NULL pointer case.
    
    Fix it by returning an error pointer with the error code carried from
    sockfd_lookup().
    
    (I found this bug during code inspection.)
    
    Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional")
    Cc: Andreas Schultz <aschultz@tpip.net>
    Cc: Harald Welte <laforge@gnumonks.org>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Link: https://patch.msgid.link/20240825191638.146748-1-xiyou.wangcong@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

gtp: pull network headers in gtp_dev_xmit() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Aug 8 13:24:55 2024 +0000

    gtp: pull network headers in gtp_dev_xmit()
    
    commit 3a3be7ff9224f424e485287b54be00d2c6bd9c40 upstream.
    
    syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]
    
    We must make sure the IPv4 or Ipv6 header is pulled in skb->head
    before accessing fields in them.
    
    Use pskb_inet_may_pull() to fix this issue.
    
    [1]
    BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]
     BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
     BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
      ipv6_pdp_find drivers/net/gtp.c:220 [inline]
      gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
      gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
      __netdev_start_xmit include/linux/netdevice.h:4913 [inline]
      netdev_start_xmit include/linux/netdevice.h:4922 [inline]
      xmit_one net/core/dev.c:3580 [inline]
      dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596
      __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423
      dev_queue_xmit include/linux/netdevice.h:3105 [inline]
      packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
      packet_snd net/packet/af_packet.c:3145 [inline]
      packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:745
      __sys_sendto+0x685/0x830 net/socket.c:2204
      __do_sys_sendto net/socket.c:2216 [inline]
      __se_sys_sendto net/socket.c:2212 [inline]
      __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
      x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    Uninit was created at:
      slab_post_alloc_hook mm/slub.c:3994 [inline]
      slab_alloc_node mm/slub.c:4037 [inline]
      kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080
      kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583
      __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674
      alloc_skb include/linux/skbuff.h:1320 [inline]
      alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526
      sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815
      packet_alloc_skb net/packet/af_packet.c:2994 [inline]
      packet_snd net/packet/af_packet.c:3088 [inline]
      packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:745
      __sys_sendto+0x685/0x830 net/socket.c:2204
      __do_sys_sendto net/socket.c:2216 [inline]
      __se_sys_sendto net/socket.c:2212 [inline]
      __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
      x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
      do_syscall_x64 arch/x86/entry/common.c:52 [inline]
      do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    
    CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
    
    Fixes: 999cb275c807 ("gtp: add IPv6 support")
    Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Harald Welte <laforge@gnumonks.org>
    Reviewed-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Link: https://patch.msgid.link/20240808132455.3413916-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HID: microsoft: Add rumble support to latest xbox controllers [+ + +]
Author: Siarhei Vishniakou <svv@google.com>
Date:   Tue Apr 25 09:38:44 2023 -0700

    HID: microsoft: Add rumble support to latest xbox controllers
    
    commit f5554725f30475b05b5178b998366f11ecb50c7f upstream.
    
    Currently, rumble is only supported via bluetooth on a single xbox
    controller, called 'model 1708'. On the back of the device, it's named
    'wireless controller for xbox one'. However, in 2021, Microsoft released
    a firmware update for this controller. As part of this update, the HID
    descriptor of the device changed. The product ID was also changed from
    0x02fd to 0x0b20. On this controller, rumble was supported via
    hid-microsoft, which matched against the old product id (0x02fd). As a
    result, the firmware update broke rumble support on this controller.
    
    See:
    https://news.xbox.com/en-us/2021/09/08/xbox-controller-firmware-update-rolling-out-to-insiders-starting-today/
    
    The hid-microsoft driver actually supports rumble on the new firmware,
    as well. So simply adding new product id is sufficient to bring back
    this support.
    
    After discussing further with the xbox team, it was pointed out that
    another xbox controller, xbox elite series 2, can be supported in a
    similar way.
    
    Add rumble support for all of these devices in this patch. Two of the
    devices have received firmware updates that caused their product id's to
    change. Both old and new firmware versions of these devices were tested.
    
    The tested controllers are:
    
    1. 'wireless controller for xbox one', model 1708
    2. 'xbox wireless controller', model 1914. This is also sometimes
       referred to as 'xbox series S|X'.
    3. 'elite series 2', model 1797.
    
    The tested configurations are:
    1. model 1708, pid 0x02fd (old firmware)
    2. model 1708, pid 0x0b20 (new firmware)
    3. model 1914, pid 0x0b13
    4. model 1797, pid 0x0b05 (old firmware)
    5. model 1797, pid 0x0b22 (new firmware)
    
    I verified rumble support on both bluetooth and usb.
    
    Reviewed-by: Bastien Nocera <hadess@hadess.net>
    Signed-off-by: Siarhei Vishniakou <svv@google.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

HID: wacom: Defer calculation of resolution until resolution_code is known [+ + +]
Author: Jason Gerecke <jason.gerecke@wacom.com>
Date:   Tue Jul 30 08:51:55 2024 -0700

    HID: wacom: Defer calculation of resolution until resolution_code is known
    
    commit 1b8f9c1fb464968a5b18d3acc1da8c00bad24fad upstream.
    
    The Wacom driver maps the HID_DG_TWIST usage to ABS_Z (rather than ABS_RZ)
    for historic reasons. When the code to support twist was introduced in
    commit 50066a042da5 ("HID: wacom: generic: Add support for height, tilt,
    and twist usages"), we were careful to write it in such a way that it had
    HID calculate the resolution of the twist axis assuming ABS_RZ instead
    (so that we would get correct angular behavior). This was broken with
    the introduction of commit 08a46b4190d3 ("HID: wacom: Set a default
    resolution for older tablets"), which moved the resolution calculation
    to occur *before* the adjustment from ABS_Z to ABS_RZ occurred.
    
    This commit moves the calculation of resolution after the point that
    we are finished setting things up for its proper use.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Fixes: 08a46b4190d3 ("HID: wacom: Set a default resolution for older tablets")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hrtimer: Prevent queuing of hrtimer without a function callback [+ + +]
Author: Phil Chang <phil.chang@mediatek.com>
Date:   Mon Jun 10 21:31:36 2024 +0800

    hrtimer: Prevent queuing of hrtimer without a function callback
    
    [ Upstream commit 5a830bbce3af16833fe0092dec47b6dd30279825 ]
    
    The hrtimer function callback must not be NULL. It has to be specified by
    the call side but it is not validated by the hrtimer code. When a hrtimer
    is queued without a function callback, the kernel crashes with a null
    pointer dereference when trying to execute the callback in __run_hrtimer().
    
    Introduce a validation before queuing the hrtimer in
    hrtimer_start_range_ns().
    
    [anna-maria: Rephrase commit message]
    
    Signed-off-by: Phil Chang <phil.chang@mediatek.com>
    Signed-off-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwmon: (ltc2992) Avoid division by zero [+ + +]
Author: Antoniu Miclaus <antoniu.miclaus@analog.com>
Date:   Wed Oct 11 16:57:53 2023 +0300

    hwmon: (ltc2992) Avoid division by zero
    
    [ Upstream commit 10b02902048737f376104bc69e5212466e65a542 ]
    
    Do not allow setting shunt resistor to 0. This results in a division by
    zero when performing current value computations based on input voltages
    and connected resistor values.
    
    Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
    Link: https://lore.kernel.org/r/20231011135754.13508-1-antoniu.miclaus@analog.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwmon: (ltc2992) Fix memory leak in ltc2992_parse_dt() [+ + +]
Author: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Date:   Thu May 23 17:47:14 2024 +0200

    hwmon: (ltc2992) Fix memory leak in ltc2992_parse_dt()
    
    commit a94ff8e50c20bde6d50864849a98b106e45d30c6 upstream.
    
    A new error path was added to the fwnode_for_each_available_node() loop
    in ltc2992_parse_dt(), which leads to an early return that requires a
    call to fwnode_handle_put() to avoid a memory leak in that case.
    
    Add the missing fwnode_handle_put() in the error path from a zero value
    shunt resistor.
    
    Cc: stable@vger.kernel.org
    Fixes: 10b029020487 ("hwmon: (ltc2992) Avoid division by zero")
    Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
    Link: https://lore.kernel.org/r/20240523-fwnode_for_each_available_child_node_scoped-v2-1-701f3a03f2fb@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
i2c: riic: avoid potential division by zero [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Wed Sep 6 22:00:23 2023 +0200

    i2c: riic: avoid potential division by zero
    
    [ Upstream commit 7890fce6201aed46d3576e3d641f9ee5c1f0e16f ]
    
    Value comes from DT, so it could be 0. Unlikely, but could be.
    
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i3c: mipi-i3c-hci: Do not unmap region not mapped for transfer [+ + +]
Author: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Date:   Thu Sep 21 08:57:01 2023 +0300

    i3c: mipi-i3c-hci: Do not unmap region not mapped for transfer
    
    [ Upstream commit b8806e0c939f168237593af0056c309bf31022b0 ]
    
    Fix following warning (with CONFIG_DMA_API_DEBUG) which happens with a
    transfer without a data buffer.
    
            DMA-API: i3c mipi-i3c-hci.0: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=0 bytes]
    
    For those transfers the hci_dma_queue_xfer() doesn't create a mapping and
    the DMA address pointer xfer->data_dma is not set.
    
    Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Link: https://lore.kernel.org/r/20230921055704.1087277-10-jarkko.nikula@linux.intel.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i3c: mipi-i3c-hci: Remove BUG() when Ring Abort request times out [+ + +]
Author: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Date:   Thu Sep 21 08:56:57 2023 +0300

    i3c: mipi-i3c-hci: Remove BUG() when Ring Abort request times out
    
    [ Upstream commit 361acacaf7c706223968c8186f0d3b6e214e7403 ]
    
    Ring Abort request will timeout in case there is an error in the Host
    Controller interrupt delivery or Ring Header configuration. Using BUG()
    makes hard to debug those cases.
    
    Make it less severe and turn BUG() to WARN_ON().
    
    Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
    Link: https://lore.kernel.org/r/20230921055704.1087277-6-jarkko.nikula@linux.intel.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/hfi1: Fix potential deadlock on &irq_src_lock and &dd->uctxt_lock [+ + +]
Author: Chengfeng Ye <dg573847474@gmail.com>
Date:   Tue Sep 26 10:11:16 2023 +0000

    IB/hfi1: Fix potential deadlock on &irq_src_lock and &dd->uctxt_lock
    
    [ Upstream commit 2f19c4b8395ccb6eb25ccafee883c8cfbe3fc193 ]
    
    handle_receive_interrupt_napi_sp() running inside interrupt handler
    could introduce inverse lock ordering between &dd->irq_src_lock
    and &dd->uctxt_lock, if read_mod_write() is preempted by the isr.
    
              [CPU0]                                        |          [CPU1]
    hfi1_ipoib_dev_open()                                   |
    --> hfi1_netdev_enable_queues()                         |
    --> enable_queues(rx)                                   |
    --> hfi1_rcvctrl()                                      |
    --> set_intr_bits()                                     |
    --> read_mod_write()                                    |
    --> spin_lock(&dd->irq_src_lock)                        |
                                                            | hfi1_poll()
                                                            | --> poll_next()
                                                            | --> spin_lock_irq(&dd->uctxt_lock)
                                                            |
                                                            | --> hfi1_rcvctrl()
                                                            | --> set_intr_bits()
                                                            | --> read_mod_write()
                                                            | --> spin_lock(&dd->irq_src_lock)
    <interrupt>                                             |
       --> handle_receive_interrupt_napi_sp()               |
       --> set_all_fastpath()                               |
       --> hfi1_rcd_get_by_index()                          |
       --> spin_lock_irqsave(&dd->uctxt_lock)               |
    
    This flaw was found by an experimental static analysis tool I am
    developing for irq-related deadlock.
    
    To prevent the potential deadlock, the patch use spin_lock_irqsave()
    on &dd->irq_src_lock inside read_mod_write() to prevent the possible
    deadlock scenario.
    
    Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
    Link: https://lore.kernel.org/r/20230926101116.2797-1-dg573847474@gmail.com
    Acked-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ice: fix ICE_LAST_OFFSET formula [+ + +]
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date:   Wed Aug 7 12:53:25 2024 +0200

    ice: fix ICE_LAST_OFFSET formula
    
    [ Upstream commit b966ad832942b5a11e002f9b5ef102b08425b84a ]
    
    For bigger PAGE_SIZE archs, ice driver works on 3k Rx buffers.
    Therefore, ICE_LAST_OFFSET should take into account ICE_RXBUF_3072, not
    ICE_RXBUF_2048.
    
    Fixes: 7237f5b0dba4 ("ice: introduce legacy Rx flag")
    Suggested-by: Luiz Capitulino <luizcap@redhat.com>
    Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
igc: Correct the launchtime offset [+ + +]
Author: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
Date:   Wed Sep 21 10:49:40 2022 +0800

    igc: Correct the launchtime offset
    
    [ Upstream commit 790835fcc0cb9992349ae3c9010dbc7321aaa24d ]
    
    The launchtime offset should be corrected according to sections 7.5.2.6
    Transmit Scheduling Latency of the Intel Ethernet I225/I226 Software
    User Manual.
    
    Software can compensate the latency between the transmission scheduling
    and the time that packet is transmitted to the network by setting this
    GTxOffset register. Without setting this register, there may be a
    significant delay between the packet scheduling and the network point.
    
    This patch helps to reduce the latency for each of the link speed.
    
    Before:
    
    10Mbps   : 11000 - 13800 nanosecond
    100Mbps  : 1300 - 1700 nanosecond
    1000Mbps : 190 - 600 nanosecond
    2500Mbps : 1400 - 1700 nanosecond
    
    After:
    
    10Mbps   : less than 750 nanosecond
    100Mbps  : less than 192 nanosecond
    1000Mbps : less than 128 nanosecond
    2500Mbps : less than 128 nanosecond
    
    Test Setup:
    
    Talker : Use l2_tai.c to generate the launchtime into packet payload.
    Listener: Use timedump.c to compute the delta between packet arrival and
    LaunchTime packet payload.
    
    Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Signed-off-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
    Acked-by: Sasha Neftin <sasha.neftin@intel.com>
    Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Tested-by: Naama Meir <naamax.meir@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Stable-dep-of: e037a26ead18 ("igc: Fix packet still tx after gate close by reducing i226 MAC retry buffer")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

igc: Fix packet still tx after gate close by reducing i226 MAC retry buffer [+ + +]
Author: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Date:   Sat Jul 6 11:38:07 2024 -0400

    igc: Fix packet still tx after gate close by reducing i226 MAC retry buffer
    
    [ Upstream commit e037a26ead187901f83cad9c503ccece5ff6817a ]
    
    Testing uncovered that even when the taprio gate is closed, some packets
    still transmit.
    
    According to i225/6 hardware errata [1], traffic might overflow the
    planned QBV window. This happens because MAC maintains an internal buffer,
    primarily for supporting half duplex retries. Therefore, even when the
    gate closes, residual MAC data in the buffer may still transmit.
    
    To mitigate this for i226, reduce the MAC's internal buffer from 192 bytes
    to the recommended 88 bytes by modifying the RETX_CTL register value.
    
    This follows guidelines from:
    [1] Ethernet Controller I225/I22 Spec Update Rev 2.1 Errata Item 9:
        TSN: Packet Transmission Might Cross Qbv Window
    [2] I225/6 SW User Manual Rev 1.2.4: Section 8.11.5 Retry Buffer Control
    
    Note that the RETX_CTL register can't be used in TSN mode because half
    duplex feature cannot coexist with TSN.
    
    Test Steps:
    1.  Send taprio cmd to board A:
        tc qdisc replace dev enp1s0 parent root handle 100 taprio \
        num_tc 4 \
        map 3 2 1 0 3 3 3 3 3 3 3 3 3 3 3 3 \
        queues 1@0 1@1 1@2 1@3 \
        base-time 0 \
        sched-entry S 0x07 500000 \
        sched-entry S 0x0f 500000 \
        flags 0x2 \
        txtime-delay 0
    
        Note that for TC3, gate should open for 500us and close for another
        500us.
    
    3.  Take tcpdump log on Board B.
    
    4.  Send udp packets via UDP tai app from Board A to Board B.
    
    5.  Analyze tcpdump log via wireshark log on Board B. Ensure that the
        total time from the first to the last packet received during one cycle
        for TC3 does not exceed 500us.
    
    Fixes: 43546211738e ("igc: Add new device ID's")
    Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
    Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Tested-by: Mor Bar-Gabay <morx.bar.gabay@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

igc: Fix qbv tx latency by setting gtxoffset [+ + +]
Author: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Date:   Sun Jul 7 08:53:18 2024 -0400

    igc: Fix qbv tx latency by setting gtxoffset
    
    commit 6c3fc0b1c3d073bd6fc3bf43dbd0e64240537464 upstream.
    
    A large tx latency issue was discovered during testing when only QBV was
    enabled. The issue occurs because gtxoffset was not set when QBV is
    active, it was only set when launch time is active.
    
    The patch "igc: Correct the launchtime offset" only sets gtxoffset when
    the launchtime_enable field is set by the user. Enabling launchtime_enable
    ultimately sets the register IGC_TXQCTL_QUEUE_MODE_LAUNCHT (referred to as
    LaunchT in the SW user manual).
    
    Section 7.5.2.6 of the IGC i225/6 SW User Manual Rev 1.2.4 states:
    "The latency between transmission scheduling (launch time) and the
    time the packet is transmitted to the network is listed in Table 7-61."
    
    However, the patch misinterprets the phrase "launch time" in that section
    by assuming it specifically refers to the LaunchT register, whereas it
    actually denotes the generic term for when a packet is released from the
    internal buffer to the MAC transmit logic.
    
    This launch time, as per that section, also implicitly refers to the QBV
    gate open time, where a packet waits in the buffer for the QBV gate to
    open. Therefore, latency applies whenever QBV is in use. TSN features such
    as QBU and QAV reuse QBV, making the latency universal to TSN features.
    
    Discussed with i226 HW owner (Shalev, Avi) and we were in agreement that
    the term "launch time" used in Section 7.5.2.6 is not clear and can be
    easily misinterpreted. Avi will update this section to:
    "When TQAVCTRL.TRANSMIT_MODE = TSN, the latency between transmission
    scheduling and the time the packet is transmitted to the network is listed
    in Table 7-61."
    
    Fix this issue by using igc_tsn_is_tx_mode_in_tsn() as a condition to
    write to gtxoffset, aligning with the newly updated SW User Manual.
    
    Tested:
    1. Enrol taprio on talker board
       base-time 0
       cycle-time 1000000
       flags 0x2
       index 0 cmd S gatemask 0x1 interval1
       index 0 cmd S gatemask 0x1 interval2
    
       Note:
       interval1 = interval for a 64 bytes packet to go through
       interval2 = cycle-time - interval1
    
    2. Take tcpdump on listener board
    
    3. Use udp tai app on talker to send packets to listener
    
    4. Check the timestamp on listener via wireshark
    
    Test Result:
    100 Mbps: 113 ~193 ns
    1000 Mbps: 52 ~ 84 ns
    2500 Mbps: 95 ~ 223 ns
    
    Note that the test result is similar to the patch "igc: Correct the
    launchtime offset".
    
    Fixes: 790835fcc0cb ("igc: Correct the launchtime offset")
    Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Tested-by: Mor Bar-Gabay <morx.bar.gabay@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

igc: Fix reset adapter logics when tx mode change [+ + +]
Author: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Date:   Sun Jul 7 08:53:17 2024 -0400

    igc: Fix reset adapter logics when tx mode change
    
    commit 0afeaeb5dae86aceded0d5f0c3a54d27858c0c6f upstream.
    
    Following the "igc: Fix TX Hang issue when QBV Gate is close" changes,
    remaining issues with the reset adapter logic in igc_tsn_offload_apply()
    have been observed:
    
    1. The reset adapter logics for i225 and i226 differ, although they should
       be the same according to the guidelines in I225/6 HW Design Section
       7.5.2.1 on software initialization during tx mode changes.
    2. The i225 resets adapter every time, even though tx mode doesn't change.
       This occurs solely based on the condition  igc_is_device_id_i225() when
       calling schedule_work().
    3. i226 doesn't reset adapter for tsn->legacy tx mode changes. It only
       resets adapter for legacy->tsn tx mode transitions.
    4. qbv_count introduced in the patch is actually not needed; in this
       context, a non-zero value of qbv_count is used to indicate if tx mode
       was unconditionally set to tsn in igc_tsn_enable_offload(). This could
       be replaced by checking the existing register
       IGC_TQAVCTRL_TRANSMIT_MODE_TSN bit.
    
    This patch resolves all issues and enters schedule_work() to reset the
    adapter only when changing tx mode. It also removes reliance on qbv_count.
    
    qbv_count field will be removed in a future patch.
    
    Test ran:
    
    1. Verify reset adapter behaviour in i225/6:
       a) Enrol a new GCL
          Reset adapter observed (tx mode change legacy->tsn)
       b) Enrol a new GCL without deleting qdisc
          No reset adapter observed (tx mode remain tsn->tsn)
       c) Delete qdisc
          Reset adapter observed (tx mode change tsn->legacy)
    
    2. Tested scenario from "igc: Fix TX Hang issue when QBV Gate is closed"
       to confirm it remains resolved.
    
    Fixes: 175c241288c0 ("igc: Fix TX Hang issue when QBV Gate is closed")
    Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
    Tested-by: Mor Bar-Gabay <morx.bar.gabay@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    [ Only want the igc_tsn_is_tx_mode_in_tsn() portion of this for older stable
      kernels - gregkh ]
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

igc: remove I226 Qbv BaseTime restriction [+ + +]
Author: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
Date:   Thu Dec 15 00:29:07 2022 +0800

    igc: remove I226 Qbv BaseTime restriction
    
    [ Upstream commit b8897dc54e3bc9d25281bbb42a7d730782ff4588 ]
    
    Remove the Qbv BaseTime restriction for I226 so that the BaseTime can be
    scheduled to the future time. A new register bit of Tx Qav Control
    (Bit-7: FutScdDis) was introduced to allow I226 scheduling future time as
    Qbv BaseTime and not having the Tx hang timeout issue.
    
    Besides, according to datasheet section 7.5.2.9.3.3, FutScdDis bit has to
    be configured first before the cycle time and base time.
    
    Indeed the FutScdDis bit is only active on re-configuration, thus we have
    to set the BASET_L to zero and then only set it to the desired value.
    
    Please also note that the Qbv configuration flow is moved around based on
    the Qbv programming guideline that is documented in the latest datasheet.
    
    Co-developed-by: Tan Tee Min <tee.min.tan@linux.intel.com>
    Signed-off-by: Tan Tee Min <tee.min.tan@linux.intel.com>
    Signed-off-by: Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
    Tested-by: Naama Meir <naamax.meir@linux.intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Stable-dep-of: e037a26ead18 ("igc: Fix packet still tx after gate close by reducing i226 MAC retry buffer")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: MT - limit max slots [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon Jul 29 21:51:30 2024 +0900

    Input: MT - limit max slots
    
    commit 99d3bf5f7377d42f8be60a6b9cb60fb0be34dceb upstream.
    
    syzbot is reporting too large allocation at input_mt_init_slots(), for
    num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).
    
    Since nobody knows possible max slots, this patch chose 1024.
    
    Reported-by: syzbot <syzbot+0122fa359a69694395d5@syzkaller.appspotmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5
    Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: George Kennedy <george.kennedy@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ip6_tunnel: Fix broken GRO [+ + +]
Author: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Date:   Thu Aug 15 17:14:16 2024 +0200

    ip6_tunnel: Fix broken GRO
    
    [ Upstream commit 4b3e33fcc38f7750604b065c55a43e94c5bc3145 ]
    
    GRO code checks for matching layer 2 headers to see, if packet belongs
    to the same flow and because ip6 tunnel set dev->hard_header_len
    this check fails in cases, where it shouldn't. To fix this don't
    set hard_header_len, but use needed_headroom like ipv4/ip_tunnel.c
    does.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
    Link: https://patch.msgid.link/20240815151419.109864-1-tbogendoerfer@suse.de
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: fix possible UAF in ip6_finish_output2() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Aug 20 16:08:58 2024 +0000

    ipv6: fix possible UAF in ip6_finish_output2()
    
    [ Upstream commit da273b377ae0d9bd255281ed3c2adb228321687b ]
    
    If skb_expand_head() returns NULL, skb has been freed
    and associated dst/idev could also have been freed.
    
    We need to hold rcu_read_lock() to make sure the dst and
    associated idev are alive.
    
    Fixes: 5796015fa968 ("ipv6: allocate enough headroom in ip6_finish_output2()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Vasily Averin <vasily.averin@linux.dev>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://patch.msgid.link/20240820160859.3786976-3-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: prevent possible UAF in ip6_xmit() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Aug 20 16:08:59 2024 +0000

    ipv6: prevent possible UAF in ip6_xmit()
    
    [ Upstream commit 2d5ff7e339d04622d8282661df36151906d0e1c7 ]
    
    If skb_expand_head() returns NULL, skb has been freed
    and the associated dst/idev could also have been freed.
    
    We must use rcu_read_lock() to prevent a possible UAF.
    
    Fixes: 0c9f227bee11 ("ipv6: use skb_expand_head in ip6_xmit")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Vasily Averin <vasily.averin@linux.dev>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://patch.msgid.link/20240820160859.3786976-4-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipv6: prevent UAF in ip6_send_skb() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Aug 20 16:08:57 2024 +0000

    ipv6: prevent UAF in ip6_send_skb()
    
    [ Upstream commit faa389b2fbaaec7fd27a390b4896139f9da662e3 ]
    
    syzbot reported an UAF in ip6_send_skb() [1]
    
    After ip6_local_out() has returned, we no longer can safely
    dereference rt, unless we hold rcu_read_lock().
    
    A similar issue has been fixed in commit
    a688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")
    
    Another potential issue in ip6_finish_output2() is handled in a
    separate patch.
    
    [1]
     BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
    Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530
    
    CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:93 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
      print_address_description mm/kasan/report.c:377 [inline]
      print_report+0x169/0x550 mm/kasan/report.c:488
      kasan_report+0x143/0x180 mm/kasan/report.c:601
      ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
      rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588
      rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x1a6/0x270 net/socket.c:745
      sock_write_iter+0x2dd/0x400 net/socket.c:1160
     do_iter_readv_writev+0x60a/0x890
      vfs_writev+0x37c/0xbb0 fs/read_write.c:971
      do_writev+0x1b1/0x350 fs/read_write.c:1018
      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
    RIP: 0033:0x7f936bf79e79
    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:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
    RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79
    RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004
    RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
    R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8
     </TASK>
    
    Allocated by task 6530:
      kasan_save_stack mm/kasan/common.c:47 [inline]
      kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
      unpoison_slab_object mm/kasan/common.c:312 [inline]
      __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
      kasan_slab_alloc include/linux/kasan.h:201 [inline]
      slab_post_alloc_hook mm/slub.c:3988 [inline]
      slab_alloc_node mm/slub.c:4037 [inline]
      kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044
      dst_alloc+0x12b/0x190 net/core/dst.c:89
      ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670
      make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]
      xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313
      ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257
      rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x1a6/0x270 net/socket.c:745
      ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
      ___sys_sendmsg net/socket.c:2651 [inline]
      __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680
      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
    
    Freed by task 45:
      kasan_save_stack mm/kasan/common.c:47 [inline]
      kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
      kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
      poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
      __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
      kasan_slab_free include/linux/kasan.h:184 [inline]
      slab_free_hook mm/slub.c:2252 [inline]
      slab_free mm/slub.c:4473 [inline]
      kmem_cache_free+0x145/0x350 mm/slub.c:4548
      dst_destroy+0x2ac/0x460 net/core/dst.c:124
      rcu_do_batch kernel/rcu/tree.c:2569 [inline]
      rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2843
      handle_softirqs+0x2c4/0x970 kernel/softirq.c:554
      __do_softirq kernel/softirq.c:588 [inline]
      invoke_softirq kernel/softirq.c:428 [inline]
      __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637
      irq_exit_rcu+0x9/0x30 kernel/softirq.c:649
      instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
      sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
      asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
    
    Last potentially related work creation:
      kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
      __kasan_record_aux_stack+0xac/0xc0 mm/kasan/generic.c:541
      __call_rcu_common kernel/rcu/tree.c:3106 [inline]
      call_rcu+0x167/0xa70 kernel/rcu/tree.c:3210
      refdst_drop include/net/dst.h:263 [inline]
      skb_dst_drop include/net/dst.h:275 [inline]
      nf_ct_frag6_queue net/ipv6/netfilter/nf_conntrack_reasm.c:306 [inline]
      nf_ct_frag6_gather+0xb9a/0x2080 net/ipv6/netfilter/nf_conntrack_reasm.c:485
      ipv6_defrag+0x2c8/0x3c0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:67
      nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
      nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
      nf_hook include/linux/netfilter.h:269 [inline]
      __ip6_local_out+0x6fa/0x800 net/ipv6/output_core.c:143
      ip6_local_out+0x26/0x70 net/ipv6/output_core.c:153
      ip6_send_skb+0x112/0x230 net/ipv6/ip6_output.c:1959
      rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588
      rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x1a6/0x270 net/socket.c:745
      sock_write_iter+0x2dd/0x400 net/socket.c:1160
     do_iter_readv_writev+0x60a/0x890
    
    Fixes: 0625491493d9 ("ipv6: ip6_push_pending_frames() should increment IPSTATS_MIB_OUTDISCARDS")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://patch.msgid.link/20240820160859.3786976-2-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
irqchip/gic-v3-its: Remove BUG_ON in its_vpe_irq_domain_alloc [+ + +]
Author: Guanrui Huang <guanrui.huang@linux.alibaba.com>
Date:   Thu Apr 18 14:10:53 2024 +0800

    irqchip/gic-v3-its: Remove BUG_ON in its_vpe_irq_domain_alloc
    
    [ Upstream commit 382d2ffe86efb1e2fa803d2cf17e5bfc34e574f3 ]
    
    This BUG_ON() is useless, because the same effect will be obtained
    by letting the code run its course and vm being dereferenced,
    triggering an exception.
    
    So just remove this check.
    
    Signed-off-by: Guanrui Huang <guanrui.huang@linux.alibaba.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Zenghui Yu <yuzenghui@huawei.com>
    Acked-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20240418061053.96803-3-guanrui.huang@linux.alibaba.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kcm: Serialise kcm_sendmsg() for the same socket. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Thu Aug 15 15:04:37 2024 -0700

    kcm: Serialise kcm_sendmsg() for the same socket.
    
    [ Upstream commit 807067bf014d4a3ae2cc55bd3de16f22a01eb580 ]
    
    syzkaller reported UAF in kcm_release(). [0]
    
    The scenario is
    
      1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb.
    
      2. Thread A resumes building skb from kcm->seq_skb but is blocked
         by sk_stream_wait_memory()
    
      3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb
         and puts the skb to the write queue
    
      4. Thread A faces an error and finally frees skb that is already in the
         write queue
    
      5. kcm_release() does double-free the skb in the write queue
    
    When a thread is building a MSG_MORE skb, another thread must not touch it.
    
    Let's add a per-sk mutex and serialise kcm_sendmsg().
    
    [0]:
    BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]
    BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]
    BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
    BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]
    BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
    Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167
    
    CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G    B              6.8.0-rc5-syzkaller-g9abbc24128bc #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
    Call trace:
     dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291
     show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:377 [inline]
     print_report+0x178/0x518 mm/kasan/report.c:488
     kasan_report+0xd8/0x138 mm/kasan/report.c:601
     __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381
     __skb_unlink include/linux/skbuff.h:2366 [inline]
     __skb_dequeue include/linux/skbuff.h:2385 [inline]
     __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
     __skb_queue_purge include/linux/skbuff.h:3181 [inline]
     kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
     __sock_release net/socket.c:659 [inline]
     sock_close+0xa4/0x1e8 net/socket.c:1421
     __fput+0x30c/0x738 fs/file_table.c:376
     ____fput+0x20/0x30 fs/file_table.c:404
     task_work_run+0x230/0x2e0 kernel/task_work.c:180
     exit_task_work include/linux/task_work.h:38 [inline]
     do_exit+0x618/0x1f64 kernel/exit.c:871
     do_group_exit+0x194/0x22c kernel/exit.c:1020
     get_signal+0x1500/0x15ec kernel/signal.c:2893
     do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249
     do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148
     exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]
     exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]
     el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713
     el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
     el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
    
    Allocated by task 6166:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x40/0x78 mm/kasan/common.c:68
     kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626
     unpoison_slab_object mm/kasan/common.c:314 [inline]
     __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340
     kasan_slab_alloc include/linux/kasan.h:201 [inline]
     slab_post_alloc_hook mm/slub.c:3813 [inline]
     slab_alloc_node mm/slub.c:3860 [inline]
     kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903
     __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641
     alloc_skb include/linux/skbuff.h:1296 [inline]
     kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783
     sock_sendmsg_nosec net/socket.c:730 [inline]
     __sock_sendmsg net/socket.c:745 [inline]
     sock_sendmsg+0x220/0x2c0 net/socket.c:768
     splice_to_socket+0x7cc/0xd58 fs/splice.c:889
     do_splice_from fs/splice.c:941 [inline]
     direct_splice_actor+0xec/0x1d8 fs/splice.c:1164
     splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108
     do_splice_direct_actor fs/splice.c:1207 [inline]
     do_splice_direct+0x1e4/0x304 fs/splice.c:1233
     do_sendfile+0x460/0xb3c fs/read_write.c:1295
     __do_sys_sendfile64 fs/read_write.c:1362 [inline]
     __se_sys_sendfile64 fs/read_write.c:1348 [inline]
     __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1348
     __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
     invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
     el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
     do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
     el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712
     el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
     el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
    
    Freed by task 6167:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x40/0x78 mm/kasan/common.c:68
     kasan_save_free_info+0x5c/0x74 mm/kasan/generic.c:640
     poison_slab_object+0x124/0x18c mm/kasan/common.c:241
     __kasan_slab_free+0x3c/0x78 mm/kasan/common.c:257
     kasan_slab_free include/linux/kasan.h:184 [inline]
     slab_free_hook mm/slub.c:2121 [inline]
     slab_free mm/slub.c:4299 [inline]
     kmem_cache_free+0x15c/0x3d4 mm/slub.c:4363
     kfree_skbmem+0x10c/0x19c
     __kfree_skb net/core/skbuff.c:1109 [inline]
     kfree_skb_reason+0x240/0x6f4 net/core/skbuff.c:1144
     kfree_skb include/linux/skbuff.h:1244 [inline]
     kcm_release+0x104/0x4c8 net/kcm/kcmsock.c:1685
     __sock_release net/socket.c:659 [inline]
     sock_close+0xa4/0x1e8 net/socket.c:1421
     __fput+0x30c/0x738 fs/file_table.c:376
     ____fput+0x20/0x30 fs/file_table.c:404
     task_work_run+0x230/0x2e0 kernel/task_work.c:180
     exit_task_work include/linux/task_work.h:38 [inline]
     do_exit+0x618/0x1f64 kernel/exit.c:871
     do_group_exit+0x194/0x22c kernel/exit.c:1020
     get_signal+0x1500/0x15ec kernel/signal.c:2893
     do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249
     do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148
     exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]
     exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]
     el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713
     el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
     el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
    
    The buggy address belongs to the object at ffff0000ced0fc80
     which belongs to the cache skbuff_head_cache of size 240
    The buggy address is located 0 bytes inside of
     freed 240-byte region [ffff0000ced0fc80, ffff0000ced0fd70)
    
    The buggy address belongs to the physical page:
    page:00000000d35f4ae4 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10ed0f
    flags: 0x5ffc00000000800(slab|node=0|zone=2|lastcpupid=0x7ff)
    page_type: 0xffffffff()
    raw: 05ffc00000000800 ffff0000c1cbf640 fffffdffc3423100 dead000000000004
    raw: 0000000000000000 00000000000c000c 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff0000ced0fb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff0000ced0fc00: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
    >ffff0000ced0fc80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
     ffff0000ced0fd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc
     ffff0000ced0fd80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
    
    Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module")
    Reported-by: syzbot+b72d86aa5df17ce74c60@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=b72d86aa5df17ce74c60
    Tested-by: syzbot+b72d86aa5df17ce74c60@syzkaller.appspotmail.com
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Link: https://patch.msgid.link/20240815220437.69511-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Aug 20 11:03:38 2024 +0100

    KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3
    
    commit 3e6245ebe7ef341639e9a7e402b3ade8ad45a19f upstream.
    
    On a system with a GICv3, if a guest hasn't been configured with
    GICv3 and that the host is not capable of GICv2 emulation,
    a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.
    
    We therefore try to emulate the SGI access, only to hit a NULL
    pointer as no private interrupt is allocated (no GIC, remember?).
    
    The obvious fix is to give the guest what it deserves, in the
    shape of a UNDEF exception.
    
    Reported-by: Alexander Potapenko <glider@google.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240820100349.3544850-2-maz@kernel.org
    Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 5.15.166 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Sep 4 13:23:42 2024 +0200

    Linux 5.15.166
    
    Link: https://lore.kernel.org/r/20240901160823.230213148@linuxfoundation.org
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
md: clean up invalid BUG_ON in md_ioctl [+ + +]
Author: Li Nan <linan122@huawei.com>
Date:   Mon Feb 26 11:14:38 2024 +0800

    md: clean up invalid BUG_ON in md_ioctl
    
    [ Upstream commit 9dd8702e7cd28ebf076ff838933f29cf671165ec ]
    
    'disk->private_data' is set to mddev in md_alloc() and never set to NULL,
    and users need to open mddev before submitting ioctl. So mddev must not
    have been freed during ioctl, and there is no need to check mddev here.
    Clean up it.
    
    Signed-off-by: Li Nan <linan122@huawei.com>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240226031444.3606764-4-linan666@huaweicloud.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: drivers/media/dvb-core: copy user arrays safely [+ + +]
Author: Philipp Stanner <pstanner@redhat.com>
Date:   Thu Nov 2 20:16:34 2023 +0100

    media: drivers/media/dvb-core: copy user arrays safely
    
    [ Upstream commit 102fb77c2deb0df3683ef8ff7a6f4cf91dc456e2 ]
    
    At several positions in dvb_frontend.c, memdup_user() is utilized to
    copy userspace arrays. This is done without overflow checks.
    
    Use the new wrapper memdup_array_user() to copy the arrays more safely.
    
    Link: https://lore.kernel.org/linux-media/20231102191633.52592-2-pstanner@redhat.com
    Suggested-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Philipp Stanner <pstanner@redhat.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: pci: cx23885: check cx23885_vdev_init() return [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Thu Oct 19 08:58:49 2023 +0200

    media: pci: cx23885: check cx23885_vdev_init() return
    
    [ Upstream commit 15126b916e39b0cb67026b0af3c014bfeb1f76b3 ]
    
    cx23885_vdev_init() can return a NULL pointer, but that pointer
    is used in the next line without a check.
    
    Add a NULL pointer check and go to the error unwind if it is NULL.
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reported-by: Sicong Huang <huangsicong@iie.ac.cn>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: qcom: venus: fix incorrect return value [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri Oct 6 12:08:47 2023 +0200

    media: qcom: venus: fix incorrect return value
    
    [ Upstream commit 51b74c09ac8c5862007fc2bf0d465529d06dd446 ]
    
    'pd' can be NULL, and in that case it shouldn't be passed to
    PTR_ERR. Fixes a smatch warning:
    
    drivers/media/platform/qcom/venus/pm_helpers.c:873 vcodec_domains_get() warn: passing zero to 'PTR_ERR'
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: radio-isa: use dev_name to fill in bus_info [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Sat Sep 23 17:21:04 2023 +0200

    media: radio-isa: use dev_name to fill in bus_info
    
    [ Upstream commit 8b7f3cf4eb9a95940eaabad3226caeaa0d9aa59d ]
    
    This fixes this warning:
    
    drivers/media/radio/radio-isa.c: In function 'radio_isa_querycap':
    drivers/media/radio/radio-isa.c:39:57: warning: '%s' directive output may be truncated writing up to 35 bytes into a region of size 28 [-Wformat-truncation=]
       39 |         snprintf(v->bus_info, sizeof(v->bus_info), "ISA:%s", isa->v4l2_dev.name);
          |                                                         ^~
    drivers/media/radio/radio-isa.c:39:9: note: 'snprintf' output between 5 and 40 bytes into a destination of size 32
       39 |         snprintf(v->bus_info, sizeof(v->bus_info), "ISA:%s", isa->v4l2_dev.name);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c) [+ + +]
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Sat Jan 13 19:33:31 2024 +0100

    media: solo6x10: replace max(a, min(b, c)) by clamp(b, a, c)
    
    commit 31e97d7c9ae3de072d7b424b2cf706a03ec10720 upstream.
    
    This patch replaces max(a, min(b, c)) by clamp(b, a, c) in the solo6x10
    driver.  This improves the readability and more importantly, for the
    solo6x10-p2m.c file, this reduces on my system (x86-64, gcc 13):
    
     - the preprocessed size from 121 MiB to 4.5 MiB;
    
     - the build CPU time from 46.8 s to 1.6 s;
    
     - the build memory from 2786 MiB to 98MiB.
    
    In fine, this allows this relatively simple C file to be built on a
    32-bit system.
    
    Reported-by: Jiri Slaby <jirislaby@gmail.com>
    Closes: https://lore.kernel.org/lkml/18c6df0d-45ed-450c-9eda-95160a2bbb8e@gmail.com/
    Cc:  <stable@vger.kernel.org> # v6.7+
    Suggested-by: David Laight <David.Laight@ACULAB.COM>
    Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
    Reviewed-by: David Laight <David.Laight@ACULAB.COM>
    Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
memcg_write_event_control(): fix a user-triggerable oops [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sun Jul 21 14:45:08 2024 -0400

    memcg_write_event_control(): fix a user-triggerable oops
    
    commit 046667c4d3196938e992fba0dfcde570aa85cd0e upstream.
    
    we are *not* guaranteed that anything past the terminating NUL
    is mapped (let alone initialized with anything sane).
    
    Fixes: 0dea116876ee ("cgroup: implement eventfd-based generic API for notifications")
    Cc: stable@vger.kernel.org
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
memory: stm32-fmc2-ebi: check regmap_read return value [+ + +]
Author: Christophe Kerello <christophe.kerello@foss.st.com>
Date:   Mon Feb 26 11:14:25 2024 +0100

    memory: stm32-fmc2-ebi: check regmap_read return value
    
    [ Upstream commit 722463f73bcf65a8c818752a38c14ee672c77da1 ]
    
    Check regmap_read return value to avoid to use uninitialized local
    variables.
    
    Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
    Link: https://lore.kernel.org/r/20240226101428.37791-3-christophe.kerello@foss.st.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

memory: tegra: Skip SID programming if SID registers aren't set [+ + +]
Author: Ashish Mhetre <amhetre@nvidia.com>
Date:   Tue Nov 7 16:57:13 2023 +0530

    memory: tegra: Skip SID programming if SID registers aren't set
    
    [ Upstream commit 0d6c918011ce4764ed277de4726a468b7ffe5fed ]
    
    There are few MC clients where SID security and override register
    offsets are not specified like "sw_cluster0" in tegra234. Don't program
    SID override for such clients because it leads to access to invalid
    addresses.
    
    Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
    Link: https://lore.kernel.org/r/20231107112713.21399-2-amhetre@nvidia.com
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: Loongson64: Set timer mode in cpu-probe [+ + +]
Author: Jiaxun Yang <jiaxun.yang@flygoat.com>
Date:   Tue Jul 23 17:15:44 2024 +0800

    MIPS: Loongson64: Set timer mode in cpu-probe
    
    commit 1cb6ab446424649f03c82334634360c2e3043684 upstream.
    
    Loongson64 C and G processors have EXTIMER feature which
    is conflicting with CP0 counter.
    
    Although the processor resets in EXTIMER disabled & INTIMER
    enabled mode, which is compatible with MIPS CP0 compare, firmware
    may attempt to enable EXTIMER and interfere CP0 compare.
    
    Set timer mode back to MIPS compatible mode to fix booting on
    systems with such firmware before we have an actual driver for
    EXTIMER.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mlxbf_gige: disable RX filters until RX path initialized [+ + +]
Author: David Thompson <davthompson@nvidia.com>
Date:   Fri Aug 9 12:36:12 2024 -0400

    mlxbf_gige: disable RX filters until RX path initialized
    
    [ Upstream commit df934abb185c71c9f2fa07a5013672d0cbd36560 ]
    
    A recent change to the driver exposed a bug where the MAC RX
    filters (unicast MAC, broadcast MAC, and multicast MAC) are
    configured and enabled before the RX path is fully initialized.
    The result of this bug is that after the PHY is started packets
    that match these MAC RX filters start to flow into the RX FIFO.
    And then, after rx_init() is completed, these packets will go
    into the driver RX ring as well. If enough packets are received
    to fill the RX ring (default size is 128 packets) before the call
    to request_irq() completes, the driver RX function becomes stuck.
    
    This bug is intermittent but is most likely to be seen where the
    oob_net0 interface is connected to a busy network with lots of
    broadcast and multicast traffic.
    
    All the MAC RX filters must be disabled until the RX path is ready,
    i.e. all initialization is done and all the IRQs are installed.
    
    Fixes: f7442a634ac0 ("mlxbf_gige: call request_irq() after NAPI initialized")
    Reviewed-by: Asmaa Mnebhi <asmaa@nvidia.com>
    Signed-off-by: David Thompson <davthompson@nvidia.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20240809163612.12852-1-davthompson@nvidia.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mlxbf_gige: Remove two unused function declarations [+ + +]
Author: Yue Haibing <yuehaibing@huawei.com>
Date:   Tue Aug 8 22:52:49 2023 +0800

    mlxbf_gige: Remove two unused function declarations
    
    [ Upstream commit 98261be155f8de38f11b6542d4a8935e5532687b ]
    
    Commit f92e1869d74e ("Add Mellanox BlueField Gigabit Ethernet driver")
    declared but never implemented these.
    
    Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Asmaa Mnebhi <asmaa@nvidia.com>
    Link: https://lore.kernel.org/r/20230808145249.41596-1-yuehaibing@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: df934abb185c ("mlxbf_gige: disable RX filters until RX path initialized")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm/numa: no task_numa_fault() call if PMD is changed [+ + +]
Author: Zi Yan <ziy@nvidia.com>
Date:   Fri Aug 9 10:59:05 2024 -0400

    mm/numa: no task_numa_fault() call if PMD is changed
    
    commit fd8c35a92910f4829b7c99841f39b1b952c259d5 upstream.
    
    When handling a numa page fault, task_numa_fault() should be called by a
    process that restores the page table of the faulted folio to avoid
    duplicated stats counting.  Commit c5b5a3dd2c1f ("mm: thp: refactor NUMA
    fault handling") restructured do_huge_pmd_numa_page() and did not avoid
    task_numa_fault() call in the second page table check after a numa
    migration failure.  Fix it by making all !pmd_same() return immediately.
    
    This issue can cause task_numa_fault() being called more than necessary
    and lead to unexpected numa balancing results (It is hard to tell whether
    the issue will cause positive or negative performance impact due to
    duplicated numa fault counting).
    
    Link: https://lkml.kernel.org/r/20240809145906.1513458-3-ziy@nvidia.com
    Fixes: c5b5a3dd2c1f ("mm: thp: refactor NUMA fault handling")
    Reported-by: "Huang, Ying" <ying.huang@intel.com>
    Closes: https://lore.kernel.org/linux-mm/87zfqfw0yw.fsf@yhuang6-desk2.ccr.corp.intel.com/
    Signed-off-by: Zi Yan <ziy@nvidia.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
    Cc: "Huang, Ying" <ying.huang@intel.com>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mm/numa: no task_numa_fault() call if PTE is changed [+ + +]
Author: Zi Yan <ziy@nvidia.com>
Date:   Fri Aug 9 10:59:04 2024 -0400

    mm/numa: no task_numa_fault() call if PTE is changed
    
    commit 40b760cfd44566bca791c80e0720d70d75382b84 upstream.
    
    When handling a numa page fault, task_numa_fault() should be called by a
    process that restores the page table of the faulted folio to avoid
    duplicated stats counting.  Commit b99a342d4f11 ("NUMA balancing: reduce
    TLB flush via delaying mapping on hint page fault") restructured
    do_numa_page() and did not avoid task_numa_fault() call in the second page
    table check after a numa migration failure.  Fix it by making all
    !pte_same() return immediately.
    
    This issue can cause task_numa_fault() being called more than necessary
    and lead to unexpected numa balancing results (It is hard to tell whether
    the issue will cause positive or negative performance impact due to
    duplicated numa fault counting).
    
    Link: https://lkml.kernel.org/r/20240809145906.1513458-2-ziy@nvidia.com
    Fixes: b99a342d4f11 ("NUMA balancing: reduce TLB flush via delaying mapping on hint page fault")
    Signed-off-by: Zi Yan <ziy@nvidia.com>
    Reported-by: "Huang, Ying" <ying.huang@intel.com>
    Closes: https://lore.kernel.org/linux-mm/87zfqfw0yw.fsf@yhuang6-desk2.ccr.corp.intel.com/
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Yang Shi <shy828301@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: dw_mmc: allow biu and ciu clocks to defer [+ + +]
Author: Ben Whitten <ben.whitten@gmail.com>
Date:   Sun Aug 11 22:22:11 2024 +0100

    mmc: dw_mmc: allow biu and ciu clocks to defer
    
    commit 6275c7bc8dd07644ea8142a1773d826800f0f3f7 upstream.
    
    Fix a race condition if the clock provider comes up after mmc is probed,
    this causes mmc to fail without retrying.
    When given the DEFER error from the clk source, pass it on up the chain.
    
    Fixes: f90a0612f0e1 ("mmc: dw_mmc: lookup for optional biu and ciu clocks")
    Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240811212212.123255-1-ben.whitten@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: mmc_test: Fix NULL dereference on allocation failure [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Tue Aug 20 11:44:08 2024 +0300

    mmc: mmc_test: Fix NULL dereference on allocation failure
    
    [ Upstream commit a1e627af32ed60713941cbfc8075d44cad07f6dd ]
    
    If the "test->highmem = alloc_pages()" allocation fails then calling
    __free_pages(test->highmem) will result in a NULL dereference.  Also
    change the error code to -ENOMEM instead of returning success.
    
    Fixes: 2661081f5ab9 ("mmc_test: highmem tests")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/8c90be28-67b4-4b0d-a105-034dc72a0b31@stanley.mountain
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: correct MPTCP_SUBFLOW_ATTR_SSN_OFFSET reserved size [+ + +]
Author: Eugene Syromiatnikov <esyr@redhat.com>
Date:   Mon Aug 12 08:51:23 2024 +0200

    mptcp: correct MPTCP_SUBFLOW_ATTR_SSN_OFFSET reserved size
    
    [ Upstream commit 655111b838cdabdb604f3625a9ff08c5eedb11da ]
    
    ssn_offset field is u32 and is placed into the netlink response with
    nla_put_u32(), but only 2 bytes are reserved for the attribute payload
    in subflow_get_info_size() (even though it makes no difference
    in the end, as it is aligned up to 4 bytes).  Supply the correct
    argument to the relevant nla_total_size() call to make it less
    confusing.
    
    Fixes: 5147dfb50832 ("mptcp: allow dumping subflow context to userspace")
    Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240812065024.GA19719@asgard.redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mptcp: sched: check both backup in retrans [+ + +]
Author: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Date:   Mon Aug 26 19:11:20 2024 +0200

    mptcp: sched: check both backup in retrans
    
    commit 2a1f596ebb23eadc0f9b95a8012e18ef76295fc8 upstream.
    
    The 'mptcp_subflow_context' structure has two items related to the
    backup flags:
    
     - 'backup': the subflow has been marked as backup by the other peer
    
     - 'request_bkup': the backup flag has been set by the host
    
    Looking only at the 'backup' flag can make sense in some cases, but it
    is not the behaviour of the default packet scheduler when selecting
    paths.
    
    As explained in the commit b6a66e521a20 ("mptcp: sched: check both
    directions for backup"), the packet scheduler should look at both flags,
    because that was the behaviour from the beginning: the 'backup' flag was
    set by accident instead of the 'request_bkup' one. Now that the latter
    has been fixed, get_retrans() needs to be adapted as well.
    
    Fixes: b6a66e521a20 ("mptcp: sched: check both directions for backup")
    Cc: stable@vger.kernel.org
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-3-905199fe1172@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5e: Correctly report errors for ethtool rx flows [+ + +]
Author: Cosmin Ratiu <cratiu@nvidia.com>
Date:   Thu Aug 8 17:41:05 2024 +0300

    net/mlx5e: Correctly report errors for ethtool rx flows
    
    [ Upstream commit cbc796be1779c4dbc9a482c7233995e2a8b6bfb3 ]
    
    Previously, an ethtool rx flow with no attrs would not be added to the
    NIC as it has no rules to configure the hw with, but it would be
    reported as successful to the caller (return code 0). This is confusing
    for the user as ethtool then reports "Added rule $num", but no rule was
    actually added.
    
    This change corrects that by instead reporting these wrong rules as
    -EINVAL.
    
    Fixes: b29c61dac3a2 ("net/mlx5e: Ethtool steering flow validation refactoring")
    Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
    Reviewed-by: Saeed Mahameed <saeedm@nvidia.com>
    Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Link: https://patch.msgid.link/20240808144107.2095424-5-tariqt@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sun3_82586: Avoid reading past buffer in debug output [+ + +]
Author: Kees Cook <kees@kernel.org>
Date:   Tue Feb 6 08:16:54 2024 -0800

    net/sun3_82586: Avoid reading past buffer in debug output
    
    [ Upstream commit 4bea747f3fbec33c16d369b2f51e55981d7c78d0 ]
    
    Since NUM_XMIT_BUFFS is always 1, building m68k with sun3_defconfig and
    -Warraybounds, this build warning is visible[1]:
    
    drivers/net/ethernet/i825xx/sun3_82586.c: In function 'sun3_82586_timeout':
    drivers/net/ethernet/i825xx/sun3_82586.c:990:122: warning: array subscript 1 is above array bounds of 'volatile struct transmit_cmd_struct *[1]' [-Warray-bounds=]
      990 |                 printk("%s: command-stats: %04x %04x\n",dev->name,swab16(p->xmit_cmds[0]->cmd_status),swab16(p->xmit_cmds[1]->cmd_status));
          |                                                                                                               ~~~~~~~~~~~~^~~
    ...
    drivers/net/ethernet/i825xx/sun3_82586.c:156:46: note: while referencing 'xmit_cmds'
      156 |         volatile struct transmit_cmd_struct *xmit_cmds[NUM_XMIT_BUFFS];
    
    Avoid accessing index 1 since it doesn't exist.
    
    Link: https://github.com/KSPP/linux/issues/325 [1]
    Cc: Sam Creasey <sammy@sammy.net>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Simon Horman <horms@kernel.org> # build-tested
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Link: https://lore.kernel.org/r/20240206161651.work.876-kees@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: axienet: Fix register defines comment description [+ + +]
Author: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Date:   Fri Aug 9 11:56:09 2024 +0530

    net: axienet: Fix register defines comment description
    
    [ Upstream commit 9ff2f816e2aa65ca9a1cdf0954842f8173c0f48d ]
    
    In axiethernet header fix register defines comment description to be
    inline with IP documentation. It updates MAC configuration register,
    MDIO configuration register and frame filter control description.
    
    Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: busy-poll: use ktime_get_ns() instead of local_clock() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Aug 27 11:49:16 2024 +0000

    net: busy-poll: use ktime_get_ns() instead of local_clock()
    
    [ Upstream commit 0870b0d8b393dde53106678a1e2cec9dfa52f9b7 ]
    
    Typically, busy-polling durations are below 100 usec.
    
    When/if the busy-poller thread migrates to another cpu,
    local_clock() can be off by +/-2msec or more for small
    values of HZ, depending on the platform.
    
    Use ktimer_get_ns() to ensure deterministic behavior,
    which is the whole point of busy-polling.
    
    Fixes: 060212928670 ("net: add low latency socket poll")
    Fixes: 9a3c71aa8024 ("net: convert low latency sockets to sched_clock()")
    Fixes: 37089834528b ("sched, net: Fixup busy_loop_us_clock()")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Mina Almasry <almasrymina@google.com>
    Cc: Willem de Bruijn <willemb@google.com>
    Reviewed-by: Joe Damato <jdamato@fastly.com>
    Link: https://patch.msgid.link/20240827114916.223377-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mv88e6xxx: Fix out-of-bound access [+ + +]
Author: Joseph Huang <Joseph.Huang@garmin.com>
Date:   Mon Aug 19 19:52:50 2024 -0400

    net: dsa: mv88e6xxx: Fix out-of-bound access
    
    [ Upstream commit 528876d867a23b5198022baf2e388052ca67c952 ]
    
    If an ATU violation was caused by a CPU Load operation, the SPID could
    be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).
    
    Fixes: 75c05a74e745 ("net: dsa: mv88e6xxx: Fix counting of ATU violations")
    Signed-off-by: Joseph Huang <Joseph.Huang@garmin.com>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://patch.msgid.link/20240819235251.1331763-1-Joseph.Huang@garmin.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mv88e6xxx: read FID when handling ATU violations [+ + +]
Author: Hans J. Schultz <netdev@kapio-technology.com>
Date:   Fri Dec 9 19:28:15 2022 +0200

    net: dsa: mv88e6xxx: read FID when handling ATU violations
    
    [ Upstream commit 4bf24ad09bc0b05e97fb48b962b2c9246fc76727 ]
    
    When an ATU violation occurs, the switch uses the ATU FID register to
    report the FID of the MAC address that incurred the violation. It would
    be good for the driver to know the FID value for purposes such as
    logging and CPU-based authentication.
    
    Up until now, the driver has been calling the mv88e6xxx_g1_atu_op()
    function to read ATU violations, but that doesn't do exactly what we
    want, namely it calls mv88e6xxx_g1_atu_fid_write() with FID 0.
    (side note, the documentation for the ATU Get/Clear Violation command
    says that writes to the ATU FID register have no effect before the
    operation starts, it's only that we disregard the value that this
    register provides once the operation completes)
    
    So mv88e6xxx_g1_atu_fid_write() is not what we want, but rather
    mv88e6xxx_g1_atu_fid_read(). However, the latter doesn't exist, we need
    to write it.
    
    The remainder of mv88e6xxx_g1_atu_op() except for
    mv88e6xxx_g1_atu_fid_write() is still needed, namely to send a
    GET_CLR_VIOLATION command to the ATU. In principle we could have still
    kept calling mv88e6xxx_g1_atu_op(), but the MDIO writes to the ATU FID
    register are pointless, but in the interest of doing less CPU work per
    interrupt, write a new function called mv88e6xxx_g1_read_atu_violation()
    and call it.
    
    The FID will be the port default FID as set by mv88e6xxx_port_set_fid()
    if the VID from the packet cannot be found in the VTU. Otherwise it is
    the FID derived from the VTU entry associated with that VID.
    
    Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com>
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 528876d867a2 ("net: dsa: mv88e6xxx: Fix out-of-bound access")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: mv88e6xxx: replace ATU violation prints with trace points [+ + +]
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date:   Fri Dec 9 19:28:16 2022 +0200

    net: dsa: mv88e6xxx: replace ATU violation prints with trace points
    
    [ Upstream commit 8646384d80f3d3b4a66b3284dbbd8232d1b8799e ]
    
    In applications where the switch ports must perform 802.1X based
    authentication and are therefore locked, ATU violation interrupts are
    quite to be expected as part of normal operation. The problem is that
    they currently spam the kernel log, even if rate limited.
    
    Create a series of trace points, all derived from the same event class,
    which log these violations to the kernel's trace buffer, which is both
    much faster and much easier to ignore than printing to a serial console.
    
    New usage model:
    
    $ trace-cmd list | grep mv88e6xxx
    mv88e6xxx
    mv88e6xxx:mv88e6xxx_atu_full_violation
    mv88e6xxx:mv88e6xxx_atu_miss_violation
    mv88e6xxx:mv88e6xxx_atu_member_violation
    $ trace-cmd record -e mv88e6xxx sleep 10
    
    Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Reviewed-by: Saeed Mahameed <saeed@kernel.org>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 528876d867a2 ("net: dsa: mv88e6xxx: Fix out-of-bound access")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: vsc73xx: check busy flag in MDIO operations [+ + +]
Author: Pawel Dembicki <paweldembicki@gmail.com>
Date:   Fri Aug 9 21:38:04 2024 +0200

    net: dsa: vsc73xx: check busy flag in MDIO operations
    
    [ Upstream commit fa63c6434b6f6aaf9d8d599dc899bc0a074cc0ad ]
    
    The VSC73xx has a busy flag used during MDIO operations. It is raised
    when MDIO read/write operations are in progress. Without it, PHYs are
    misconfigured and bus operations do not work as expected.
    
    Fixes: 05bd97fc559d ("net: dsa: Add Vitesse VSC73xx DSA router driver")
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: vsc73xx: pass value in phy_write operation [+ + +]
Author: Pawel Dembicki <paweldembicki@gmail.com>
Date:   Fri Aug 9 21:38:03 2024 +0200

    net: dsa: vsc73xx: pass value in phy_write operation
    
    [ Upstream commit 5b9eebc2c7a5f0cc7950d918c1e8a4ad4bed5010 ]
    
    In the 'vsc73xx_phy_write' function, the register value is missing,
    and the phy write operation always sends zeros.
    
    This commit passes the value variable into the proper register.
    
    Fixes: 05bd97fc559d ("net: dsa: Add Vitesse VSC73xx DSA router driver")
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: dsa: vsc73xx: use read_poll_timeout instead delay loop [+ + +]
Author: Pawel Dembicki <paweldembicki@gmail.com>
Date:   Wed Apr 17 22:50:44 2024 +0200

    net: dsa: vsc73xx: use read_poll_timeout instead delay loop
    
    [ Upstream commit eb7e33d01db3aec128590391b2397384bab406b6 ]
    
    Switch the delay loop during the Arbiter empty check from
    vsc73xx_adjust_link() to use read_poll_timeout(). Functionally,
    one msleep() call is eliminated at the end of the loop in the timeout
    case.
    
    As Russell King suggested:
    
    "This [change] avoids the issue that on the last iteration, the code reads
    the register, tests it, finds the condition that's being waiting for is
    false, _then_ waits and end up printing the error message - that last
    wait is rather useless, and as the arbiter state isn't checked after
    waiting, it could be that we had success during the last wait."
    
    Suggested-by: Russell King <linux@armlinux.org.uk>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
    Link: https://lore.kernel.org/r/20240417205048.3542839-2-paweldembicki@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: fa63c6434b6f ("net: dsa: vsc73xx: check busy flag in MDIO operations")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: add checking for vf id of mailbox [+ + +]
Author: Jian Shen <shenjian15@huawei.com>
Date:   Thu Mar 7 09:01:15 2024 +0800

    net: hns3: add checking for vf id of mailbox
    
    [ Upstream commit 4e2969a0d6a7549bc0bc1ebc990588b622c4443d ]
    
    Add checking for vf id of mailbox, in order to avoid array
    out-of-bounds risk.
    
    Signed-off-by: Jian Shen <shenjian15@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Reviewed-by: Sunil Goutham <sgoutham@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: fix a deadlock problem when config TC during resetting [+ + +]
Author: Jie Wang <wangjie125@huawei.com>
Date:   Tue Aug 13 22:10:22 2024 +0800

    net: hns3: fix a deadlock problem when config TC during resetting
    
    [ Upstream commit be5e816d00a506719e9dbb1a9c861c5ced30a109 ]
    
    When config TC during the reset process, may cause a deadlock, the flow is
    as below:
                                 pf reset start
                                     │
                                     ▼
                                  ......
    setup tc                         │
        │                            ▼
        ▼                      DOWN: napi_disable()
    napi_disable()(skip)             │
        │                            │
        ▼                            ▼
      ......                      ......
        │                            │
        ▼                            │
    napi_enable()                    │
                                     ▼
                               UINIT: netif_napi_del()
                                     │
                                     ▼
                                  ......
                                     │
                                     ▼
                               INIT: netif_napi_add()
                                     │
                                     ▼
                                  ......                 global reset start
                                     │                      │
                                     ▼                      ▼
                               UP: napi_enable()(skip)    ......
                                     │                      │
                                     ▼                      ▼
                                  ......                 napi_disable()
    
    In reset process, the driver will DOWN the port and then UINIT, in this
    case, the setup tc process will UP the port before UINIT, so cause the
    problem. Adds a DOWN process in UINIT to fix it.
    
    Fixes: bb6b94a896d4 ("net: hns3: Add reset interface implementation in client")
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: fix wrong use of semaphore up [+ + +]
Author: Jie Wang <wangjie125@huawei.com>
Date:   Tue Aug 13 22:10:20 2024 +0800

    net: hns3: fix wrong use of semaphore up
    
    [ Upstream commit 8445d9d3c03101859663d34fda747f6a50947556 ]
    
    Currently, if hns3 PF or VF FLR reset failed after five times retry,
    the reset done process will directly release the semaphore
    which has already released in hclge_reset_prepare_general.
    This will cause down operation fail.
    
    So this patch fixes it by adding reset state judgement. The up operation is
    only called after successful PF FLR reset.
    
    Fixes: 8627bdedc435 ("net: hns3: refactor the precedure of PF FLR")
    Fixes: f28368bb4542 ("net: hns3: refactor the procedure of VF FLR")
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Jijie Shao <shaojijie@huawei.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mana: Fix doorbell out of order violation and avoid unnecessary doorbell rings [+ + +]
Author: Long Li <longli@microsoft.com>
Date:   Fri Aug 9 08:58:58 2024 -0700

    net: mana: Fix doorbell out of order violation and avoid unnecessary doorbell rings
    
    [ Upstream commit 58a63729c957621f1990c3494c702711188ca347 ]
    
    After napi_complete_done() is called when NAPI is polling in the current
    process context, another NAPI may be scheduled and start running in
    softirq on another CPU and may ring the doorbell before the current CPU
    does. When combined with unnecessary rings when there is no need to arm
    the CQ, it triggers error paths in the hardware.
    
    This patch fixes this by calling napi_complete_done() after doorbell
    rings. It limits the number of unnecessary rings when there is
    no need to arm. MANA hardware specifies that there must be one doorbell
    ring every 8 CQ wraparounds. This driver guarantees one doorbell ring as
    soon as the number of consumed CQEs exceeds 4 CQ wraparounds. In practical
    workloads, the 4 CQ wraparounds proves to be big enough that it rarely
    exceeds this limit before all the napi weight is consumed.
    
    To implement this, add a per-CQ counter cq->work_done_since_doorbell,
    and make sure the CQ is armed as soon as passing 4 wraparounds of the CQ.
    
    Cc: stable@vger.kernel.org
    Fixes: e1b5683ff62e ("net: mana: Move NAPI from EQ to CQ")
    Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
    Signed-off-by: Long Li <longli@microsoft.com>
    Link: https://patch.msgid.link/1723219138-29887-1-git-send-email-longli@linuxonhyperv.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: mana: Fix race of mana_hwc_post_rx_wqe and new hwc response [+ + +]
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date:   Wed Aug 21 13:42:29 2024 -0700

    net: mana: Fix race of mana_hwc_post_rx_wqe and new hwc response
    
    commit 8af174ea863c72f25ce31cee3baad8a301c0cf0f upstream.
    
    The mana_hwc_rx_event_handler() / mana_hwc_handle_resp() calls
    complete(&ctx->comp_event) before posting the wqe back. It's
    possible that other callers, like mana_create_txq(), start the
    next round of mana_hwc_send_request() before the posting of wqe.
    And if the HW is fast enough to respond, it can hit no_wqe error
    on the HW channel, then the response message is lost. The mana
    driver may fail to create queues and open, because of waiting for
    the HW response and timed out.
    Sample dmesg:
    [  528.610840] mana 39d4:00:02.0: HWC: Request timed out!
    [  528.614452] mana 39d4:00:02.0: Failed to send mana message: -110, 0x0
    [  528.618326] mana 39d4:00:02.0 enP14804s2: Failed to create WQ object: -110
    
    To fix it, move posting of rx wqe before complete(&ctx->comp_event).
    
    Cc: stable@vger.kernel.org
    Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
    Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
    Reviewed-by: Long Li <longli@microsoft.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: xilinx: axienet: Always disable promiscuous mode [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Thu Aug 22 11:40:55 2024 -0400

    net: xilinx: axienet: Always disable promiscuous mode
    
    [ Upstream commit 4ae738dfef2c0323752ab81786e2d298c9939321 ]
    
    If promiscuous mode is disabled when there are fewer than four multicast
    addresses, then it will not be reflected in the hardware. Fix this by
    always clearing the promiscuous mode flag even when we program multicast
    addresses.
    
    Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20240822154059.1066595-2-sean.anderson@linux.dev
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: xilinx: axienet: Fix dangling multicast addresses [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Thu Aug 22 11:40:56 2024 -0400

    net: xilinx: axienet: Fix dangling multicast addresses
    
    [ Upstream commit 797a68c9de0f5a5447baf4bd3bb9c10a3993435b ]
    
    If a multicast address is removed but there are still some multicast
    addresses, that address would remain programmed into the frame filter.
    Fix this by explicitly setting the enable bit for each filter.
    
    Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20240822154059.1066595-3-sean.anderson@linux.dev
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: net:rds: Fix possible deadlock in rds_message_put [+ + +]
Author: Allison Henderson <allison.henderson@oracle.com>
Date:   Thu Feb 8 19:28:54 2024 -0700

    net:rds: Fix possible deadlock in rds_message_put
    
    commit f1acf1ac84d2ae97b7889b87223c1064df850069 upstream.
    
    Functions rds_still_queued and rds_clear_recv_queue lock a given socket
    in order to safely iterate over the incoming rds messages. However
    calling rds_inc_put while under this lock creates a potential deadlock.
    rds_inc_put may eventually call rds_message_purge, which will lock
    m_rs_lock. This is the incorrect locking order since m_rs_lock is
    meant to be locked before the socket. To fix this, we move the message
    item to a local list or variable that wont need rs_recv_lock protection.
    Then we can safely call rds_inc_put on any item stored locally after
    rs_recv_lock is released.
    
    Fixes: bdbe6fbc6a2f ("RDS: recv.c")
    Reported-by: syzbot+f9db6ff27b9bfdcfeca0@syzkaller.appspotmail.com
    Reported-by: syzbot+dcd73ff9291e6d34b3ab@syzkaller.appspotmail.com
    Signed-off-by: Allison Henderson <allison.henderson@oracle.com>
    Link: https://lore.kernel.org/r/20240209022854.200292-1-allison.henderson@oracle.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netem: fix return value if duplicate enqueue fails [+ + +]
Author: Stephen Hemminger <stephen@networkplumber.org>
Date:   Mon Aug 19 10:56:45 2024 -0700

    netem: fix return value if duplicate enqueue fails
    
    [ Upstream commit c07ff8592d57ed258afee5a5e04991a48dbaf382 ]
    
    There is a bug in netem_enqueue() introduced by
    commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
    that can lead to a use-after-free.
    
    This commit made netem_enqueue() always return NET_XMIT_SUCCESS
    when a packet is duplicated, which can cause the parent qdisc's q.qlen
    to be mistakenly incremented. When this happens qlen_notify() may be
    skipped on the parent during destruction, leaving a dangling pointer
    for some classful qdiscs like DRR.
    
    There are two ways for the bug happen:
    
    - If the duplicated packet is dropped by rootq->enqueue() and then
      the original packet is also dropped.
    - If rootq->enqueue() sends the duplicated packet to a different qdisc
      and the original packet is dropped.
    
    In both cases NET_XMIT_SUCCESS is returned even though no packets
    are enqueued at the netem qdisc.
    
    The fix is to defer the enqueue of the duplicate packet until after
    the original packet has been guaranteed to return NET_XMIT_SUCCESS.
    
    Fixes: 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec")
    Reported-by: Budimir Markovic <markovicbudimir@gmail.com>
    Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20240819175753.5151-1-stephen@networkplumber.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: allow ipv6 fragments to arrive on different devices [+ + +]
Author: Tom Hughes <tom@compton.nu>
Date:   Tue Aug 6 12:40:52 2024 +0100

    netfilter: allow ipv6 fragments to arrive on different devices
    
    [ Upstream commit 3cd740b985963f874a1a094f1969e998b9d05554 ]
    
    Commit 264640fc2c5f4 ("ipv6: distinguish frag queues by device
    for multicast and link-local packets") modified the ipv6 fragment
    reassembly logic to distinguish frag queues by device for multicast
    and link-local packets but in fact only the main reassembly code
    limits the use of the device to those address types and the netfilter
    reassembly code uses the device for all packets.
    
    This means that if fragments of a packet arrive on different interfaces
    then netfilter will fail to reassemble them and the fragments will be
    expired without going any further through the filters.
    
    Fixes: 648700f76b03 ("inet: frags: use rhashtables for reassembly units")
    Signed-off-by: Tom Hughes <tom@compton.nu>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: flowtable: initialise extack before use [+ + +]
Author: Donald Hunter <donald.hunter@gmail.com>
Date:   Tue Aug 6 17:16:37 2024 +0100

    netfilter: flowtable: initialise extack before use
    
    [ Upstream commit e9767137308daf906496613fd879808a07f006a2 ]
    
    Fix missing initialisation of extack in flow offload.
    
    Fixes: c29f74e0df7a ("netfilter: nf_flow_table: hardware offload support")
    Signed-off-by: Donald Hunter <donald.hunter@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: flowtable: validate vlan header [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Aug 13 12:39:46 2024 +0200

    netfilter: flowtable: validate vlan header
    
    [ Upstream commit 6ea14ccb60c8ab829349979b22b58a941ec4a3ee ]
    
    Ensure there is sufficient room to access the protocol field of the
    VLAN header, validate it once before the flowtable lookup.
    
    =====================================================
    BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32
     nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32
     nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
     nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
     nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline]
     nf_ingress net/core/dev.c:5440 [inline]
    
    Fixes: 4cd91f7c290f ("netfilter: flowtable: add vlan support")
    Reported-by: syzbot+8407d9bb88cd4c6bf61a@syzkaller.appspotmail.com
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_queue: drop packets with cloned unconfirmed conntracks [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Wed Aug 7 21:28:41 2024 +0200

    netfilter: nf_queue: drop packets with cloned unconfirmed conntracks
    
    [ Upstream commit 7d8dc1c7be8d3509e8f5164dd5df64c8e34d7eeb ]
    
    Conntrack assumes an unconfirmed entry (not yet committed to global hash
    table) has a refcount of 1 and is not visible to other cores.
    
    With multicast forwarding this assumption breaks down because such
    skbs get cloned after being picked up, i.e.  ct->use refcount is > 1.
    
    Likewise, bridge netfilter will clone broad/mutlicast frames and
    all frames in case they need to be flood-forwarded during learning
    phase.
    
    For ip multicast forwarding or plain bridge flood-forward this will
    "work" because packets don't leave softirq and are implicitly
    serialized.
    
    With nfqueue this no longer holds true, the packets get queued
    and can be reinjected in arbitrary ways.
    
    Disable this feature, I see no other solution.
    
    After this patch, nfqueue cannot queue packets except the last
    multicast/broadcast packet.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_counter: Disable BH in nft_counter_offload_stats(). [+ + +]
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Aug 20 09:54:30 2024 +0200

    netfilter: nft_counter: Disable BH in nft_counter_offload_stats().
    
    [ Upstream commit 1eacdd71b3436b54d5fc8218c4bb0187d92a6892 ]
    
    The sequence counter nft_counter_seq is a per-CPU counter. There is no
    lock associated with it. nft_counter_do_eval() is using the same counter
    and disables BH which suggest that it can be invoked from a softirq.
    This in turn means that nft_counter_offload_stats(), which disables only
    preemption, can be interrupted by nft_counter_do_eval() leading to two
    writer for one seqcount_t.
    This can lead to loosing stats or reading statistics while they are
    updated.
    
    Disable BH during stats update in nft_counter_offload_stats() to ensure
    one writer at a time.
    
    Fixes: b72920f6e4a9d ("netfilter: nftables: counter hardware offload support")
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nft_counter: Synchronize nft_counter_reset() against reader. [+ + +]
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Aug 20 09:54:31 2024 +0200

    netfilter: nft_counter: Synchronize nft_counter_reset() against reader.
    
    [ Upstream commit a0b39e2dc7017ac667b70bdeee5293e410fab2fb ]
    
    nft_counter_reset() resets the counter by subtracting the previously
    retrieved value from the counter. This is a write operation on the
    counter and as such it requires to be performed with a write sequence of
    nft_counter_seq to serialize against its possible reader.
    
    Update the packets/ bytes within write-sequence of nft_counter_seq.
    
    Fixes: d84701ecbcd6a ("netfilter: nft_counter: rework atomic dump and reset")
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netlink: hold nlk->cb_mutex longer in __netlink_dump_start() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 22 10:50:13 2024 +0000

    netlink: hold nlk->cb_mutex longer in __netlink_dump_start()
    
    [ Upstream commit b5590270068c4324dac4a2b5a4a156e02e21339f ]
    
    __netlink_dump_start() releases nlk->cb_mutex right before
    calling netlink_dump() which grabs it again.
    
    This seems dangerous, even if KASAN did not bother yet.
    
    Add a @lock_taken parameter to netlink_dump() to let it
    grab the mutex if called from netlink_recvmsg() only.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfc: pn533: Add poll mod list filling check [+ + +]
Author: Aleksandr Mishin <amishin@t-argos.ru>
Date:   Tue Aug 27 11:48:22 2024 +0300

    nfc: pn533: Add poll mod list filling check
    
    [ Upstream commit febccb39255f9df35527b88c953b2e0deae50e53 ]
    
    In case of im_protocols value is 1 and tm_protocols value is 0 this
    combination successfully passes the check
    'if (!im_protocols && !tm_protocols)' in the nfc_start_poll().
    But then after pn533_poll_create_mod_list() call in pn533_start_poll()
    poll mod list will remain empty and dev->poll_mod_count will remain 0
    which lead to division by zero.
    
    Normally no im protocol has value 1 in the mask, so this combination is
    not expected by driver. But these protocol values actually come from
    userspace via Netlink interface (NFC_CMD_START_POLL operation). So a
    broken or malicious program may pass a message containing a "bad"
    combination of protocol parameter values so that dev->poll_mod_count
    is not incremented inside pn533_poll_create_mod_list(), thus leading
    to division by zero.
    Call trace looks like:
    nfc_genl_start_poll()
      nfc_start_poll()
        ->start_poll()
        pn533_start_poll()
    
    Add poll mod list filling check.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: dfccd0f58044 ("NFC: pn533: Add some polling entropy")
    Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://patch.msgid.link/20240827084822.18785-1-amishin@t-argos.ru
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFS: avoid infinite loop in pnfs_update_layout. [+ + +]
Author: NeilBrown <neilb@suse.de>
Date:   Wed Feb 28 11:24:53 2024 +1100

    NFS: avoid infinite loop in pnfs_update_layout.
    
    [ Upstream commit 2fdbc20036acda9e5694db74a032d3c605323005 ]
    
    If pnfsd_update_layout() is called on a file for which recovery has
    failed it will enter a tight infinite loop.
    
    NFS_LAYOUT_INVALID_STID will be set, nfs4_select_rw_stateid() will
    return -EIO, and nfs4_schedule_stateid_recovery() will do nothing, so
    nfs4_client_recover_expired_lease() will not wait.  So the code will
    loop indefinitely.
    
    Break the loop by testing the validity of the open stateid at the top of
    the loop.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfsd: expose /proc/net/sunrpc/nfsd in net namespaces [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 10:55:45 2024 -0400

    nfsd: expose /proc/net/sunrpc/nfsd in net namespaces
    
    [ Upstream commit 93483ac5fec62cc1de166051b219d953bb5e4ef4 ]
    
    We are running nfsd servers inside of containers with their own network
    namespace, and we want to monitor these services using the stats found
    in /proc.  However these are not exposed in the proc inside of the
    container, so we have to bind mount the host /proc into our containers
    to get at this information.
    
    Separate out the stat counters init and the proc registration, and move
    the proc registration into the pernet operations entry and exit points
    so that these stats can be exposed inside of network namespaces.
    
    This is an intermediate step, this just exposes the global counters in
    the network namespace.  Subsequent patches will move these counters into
    the per-network namespace container.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
NFSD: Fix frame size warning in svc_export_parse() [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Aug 21 10:55:38 2024 -0400

    NFSD: Fix frame size warning in svc_export_parse()
    
    [ Upstream commit 6939ace1f22681fface7841cdbf34d3204cc94b5 ]
    
    fs/nfsd/export.c: In function 'svc_export_parse':
    fs/nfsd/export.c:737:1: warning: the frame size of 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
        737 | }
    
    On my systems, svc_export_parse() has a stack frame of over 800
    bytes, not 1040, but nonetheless, it could do with some reduction.
    
    When a struct svc_export is on the stack, it's a temporary structure
    used as an argument, and not visible as an actual exported FS. No
    need to reserve space for export_stats in such cases.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202310012359.YEw5IrK6-lkp@intel.com/
    Cc: Amir Goldstein <amir73il@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Stable-dep-of: 4b14885411f7 ("nfsd: make all of the nfsd stats per-network namespace")
    [ cel: adjusted to apply to v5.15.y ]
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfsd: make all of the nfsd stats per-network namespace [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 10:55:46 2024 -0400

    nfsd: make all of the nfsd stats per-network namespace
    
    [ Upstream commit 4b14885411f74b2b0ce0eb2b39d0fffe54e5ca0d ]
    
    We have a global set of counters that we modify for all of the nfsd
    operations, but now that we're exposing these stats across all network
    namespaces we need to make the stats also be per-network namespace.  We
    already have some caching stats that are per-network namespace, so move
    these definitions into the same counter and then adjust all the helpers
    and users of these stats to provide the appropriate nfsd_net struct so
    that the stats are maintained for the per-network namespace objects.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    [ cel: adjusted to apply to v5.15.y ]
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfsd: make svc_stat per-network namespace instead of global [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 10:55:48 2024 -0400

    nfsd: make svc_stat per-network namespace instead of global
    
    [ Upstream commit 16fb9808ab2c99979f081987752abcbc5b092eac ]
    
    The final bit of stats that is global is the rpc svc_stat.  Move this
    into the nfsd_net struct and use that everywhere instead of the global
    struct.  Remove the unused global struct.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Wed Aug 21 10:55:32 2024 -0400

    nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net
    
    [ Upstream commit ed9ab7346e908496816cffdecd46932035f66e2e ]
    
    Commit f5f9d4a314da ("nfsd: move reply cache initialization into nfsd
    startup") moved the initialization of the reply cache into nfsd startup,
    but didn't account for the stats counters, which can be accessed before
    nfsd is ever started. The result can be a NULL pointer dereference when
    someone accesses /proc/fs/nfsd/reply_cache_stats while nfsd is still
    shut down.
    
    This is a regression and a user-triggerable oops in the right situation:
    
    - non-x86_64 arch
    - /proc/fs/nfsd is mounted in the namespace
    - nfsd is not started in the namespace
    - unprivileged user calls "cat /proc/fs/nfsd/reply_cache_stats"
    
    Although this is easy to trigger on some arches (like aarch64), on
    x86_64, calling this_cpu_ptr(NULL) evidently returns a pointer to the
    fixed_percpu_data. That struct looks just enough like a newly
    initialized percpu var to allow nfsd_reply_cache_stats_show to access
    it without Oopsing.
    
    Move the initialization of the per-net+per-cpu reply-cache counters
    back into nfsd_init_net, while leaving the rest of the reply cache
    allocations to be done at nfsd startup time.
    
    Kudos to Eirik who did most of the legwork to track this down.
    
    Cc: stable@vger.kernel.org # v6.3+
    Fixes: f5f9d4a314da ("nfsd: move reply cache initialization into nfsd startup")
    Reported-and-tested-by: Eirik Fuller <efuller@redhat.com>
    Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2215429
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Stable-dep-of: 4b14885411f7 ("nfsd: make all of the nfsd stats per-network namespace")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfsd: move reply cache initialization into nfsd startup [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Wed Aug 21 10:55:31 2024 -0400

    nfsd: move reply cache initialization into nfsd startup
    
    [ Upstream commit f5f9d4a314da88c0a5faa6d168bf69081b7a25ae ]
    
    There's no need to start the reply cache before nfsd is up and running,
    and doing so means that we register a shrinker for every net namespace
    instead of just the ones where nfsd is running.
    
    Move it to the per-net nfsd startup instead.
    
    Reported-by: Dai Ngo <dai.ngo@oracle.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Stable-dep-of: ed9ab7346e90 ("nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_net")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
NFSD: Refactor nfsd_reply_cache_free_locked() [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Aug 21 10:55:33 2024 -0400

    NFSD: Refactor nfsd_reply_cache_free_locked()
    
    [ Upstream commit 35308e7f0fc3942edc87d9c6dc78c4a096428957 ]
    
    To reduce contention on the bucket locks, we must avoid calling
    kfree() while each bucket lock is held.
    
    Start by refactoring nfsd_reply_cache_free_locked() into a helper
    that removes an entry from the bucket (and must therefore run under
    the lock) and a second helper that frees the entry (which does not
    need to hold the lock).
    
    For readability, rename the helpers nfsd_cacherep_<verb>.
    
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Stable-dep-of: a9507f6af145 ("NFSD: Replace nfsd_prune_bucket()")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

NFSD: Refactor the duplicate reply cache shrinker [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Aug 21 10:55:36 2024 -0400

    NFSD: Refactor the duplicate reply cache shrinker
    
    [ Upstream commit c135e1269f34dfdea4bd94c11060c83a3c0b3c12 ]
    
    Avoid holding the bucket lock while freeing cache entries. This
    change also caps the number of entries that are freed when the
    shrinker calls to reduce the shrinker's impact on the cache's
    effectiveness.
    
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfsd: remove nfsd_stats, make th_cnt a global counter [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 10:55:47 2024 -0400

    nfsd: remove nfsd_stats, make th_cnt a global counter
    
    [ Upstream commit e41ee44cc6a473b1f414031782c3b4283d7f3e5f ]
    
    This is the last global stat, take it out of the nfsd_stats struct and
    make it a global part of nfsd, report it the same as always.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfsd: rename NFSD_NET_* to NFSD_STATS_* [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 10:55:44 2024 -0400

    nfsd: rename NFSD_NET_* to NFSD_STATS_*
    
    [ Upstream commit d98416cc2154053950610bb6880911e3dcbdf8c5 ]
    
    We're going to merge the stats all into per network namespace in
    subsequent patches, rename these nn counters to be consistent with the
    rest of the stats.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
NFSD: Rename nfsd_reply_cache_alloc() [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Aug 21 10:55:34 2024 -0400

    NFSD: Rename nfsd_reply_cache_alloc()
    
    [ Upstream commit ff0d169329768c1102b7b07eebe5a9839aa1c143 ]
    
    For readability, rename to match the other helpers.
    
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Stable-dep-of: 4b14885411f7 ("nfsd: make all of the nfsd stats per-network namespace")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

NFSD: Replace nfsd_prune_bucket() [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Aug 21 10:55:35 2024 -0400

    NFSD: Replace nfsd_prune_bucket()
    
    [ Upstream commit a9507f6af1450ed26a4a36d979af518f5bb21e5d ]
    
    Enable nfsd_prune_bucket() to drop the bucket lock while calling
    kfree(). Use the same pattern that Jeff recently introduced in the
    NFSD filecache.
    
    A few percpu operations are moved outside the lock since they
    temporarily disable local IRQs which is expensive and does not
    need to be done while the lock is held.
    
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Stable-dep-of: c135e1269f34 ("NFSD: Refactor the duplicate reply cache shrinker")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

NFSD: Rewrite synopsis of nfsd_percpu_counters_init() [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Wed Aug 21 10:55:37 2024 -0400

    NFSD: Rewrite synopsis of nfsd_percpu_counters_init()
    
    [ Upstream commit 5ec39944f874e1ecc09f624a70dfaa8ac3bf9d08 ]
    
    In function ‘export_stats_init’,
        inlined from ‘svc_export_alloc’ at fs/nfsd/export.c:866:6:
    fs/nfsd/export.c:337:16: warning: ‘nfsd_percpu_counters_init’ accessing 40 bytes in a region of size 0 [-Wstringop-overflow=]
      337 |         return nfsd_percpu_counters_init(&stats->counter, EXP_STATS_COUNTERS_NUM);
          |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    fs/nfsd/export.c:337:16: note: referencing argument 1 of type ‘struct percpu_counter[0]’
    fs/nfsd/stats.h: In function ‘svc_export_alloc’:
    fs/nfsd/stats.h:40:5: note: in a call to function ‘nfsd_percpu_counters_init’
       40 | int nfsd_percpu_counters_init(struct percpu_counter counters[], int num);
          |     ^~~~~~~~~~~~~~~~~~~~~~~~~
    
    Cc: Amir Goldstein <amir73il@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Stable-dep-of: 93483ac5fec6 ("nfsd: expose /proc/net/sunrpc/nfsd in net namespaces")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfsd: stop setting ->pg_stats for unused stats [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 10:55:40 2024 -0400

    nfsd: stop setting ->pg_stats for unused stats
    
    [ Upstream commit a2214ed588fb3c5b9824a21cff870482510372bb ]
    
    A lot of places are setting a blank svc_stats in ->pg_stats and never
    utilizing these stats.  Remove all of these extra structs as we're not
    reporting these stats anywhere.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nvmet-rdma: fix possible bad dereference when freeing rsps [+ + +]
Author: Sagi Grimberg <sagi@grimberg.me>
Date:   Wed May 8 10:53:06 2024 +0300

    nvmet-rdma: fix possible bad dereference when freeing rsps
    
    [ Upstream commit 73964c1d07c054376f1b32a62548571795159148 ]
    
    It is possible that the host connected and saw a cm established
    event and started sending nvme capsules on the qp, however the
    ctrl did not yet see an established event. This is why the
    rsp_wait_list exists (for async handling of these cmds, we move
    them to a pending list).
    
    Furthermore, it is possible that the ctrl cm times out, resulting
    in a connect-error cm event. in this case we hit a bad deref [1]
    because in nvmet_rdma_free_rsps we assume that all the responses
    are in the free list.
    
    We are freeing the cmds array anyways, so don't even bother to
    remove the rsp from the free_list. It is also guaranteed that we
    are not racing anything when we are releasing the queue so no
    other context accessing this array should be running.
    
    [1]:
    --
    Workqueue: nvmet-free-wq nvmet_rdma_free_queue_work [nvmet_rdma]
    [...]
    pc : nvmet_rdma_free_rsps+0x78/0xb8 [nvmet_rdma]
    lr : nvmet_rdma_free_queue_work+0x88/0x120 [nvmet_rdma]
     Call trace:
     nvmet_rdma_free_rsps+0x78/0xb8 [nvmet_rdma]
     nvmet_rdma_free_queue_work+0x88/0x120 [nvmet_rdma]
     process_one_work+0x1ec/0x4a0
     worker_thread+0x48/0x490
     kthread+0x158/0x160
     ret_from_fork+0x10/0x18
    --
    
    Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet-tcp: do not continue for invalid icreq [+ + +]
Author: Hannes Reinecke <hare@suse.de>
Date:   Fri Mar 8 08:11:05 2024 +0100

    nvmet-tcp: do not continue for invalid icreq
    
    [ Upstream commit 0889d13b9e1cbef49e802ae09f3b516911ad82a1 ]
    
    When the length check for an icreq sqe fails we should not
    continue processing but rather return immediately as all
    other contents of that sqe cannot be relied on.
    
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmet-trace: avoid dereferencing pointer too early [+ + +]
Author: Daniel Wagner <dwagner@suse.de>
Date:   Mon Dec 18 16:30:51 2023 +0100

    nvmet-trace: avoid dereferencing pointer too early
    
    [ Upstream commit 0e716cec6fb11a14c220ee17c404b67962e902f7 ]
    
    The first command issued from the host to the target is the fabrics
    connect command. At this point, neither the target queue nor the
    controller have been allocated. But we already try to trace this command
    in nvmet_req_init.
    
    Reported by KASAN.
    
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Daniel Wagner <dwagner@suse.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
openrisc: Call setup_memory() earlier in the init sequence [+ + +]
Author: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
Date:   Fri Feb 9 16:29:30 2024 -0800

    openrisc: Call setup_memory() earlier in the init sequence
    
    [ Upstream commit 7b432bf376c9c198a7ff48f1ed14a14c0ffbe1fe ]
    
    The unflatten_and_copy_device_tree() function contains a call to
    memblock_alloc(). This means that memblock is allocating memory before
    any of the reserved memory regions are set aside in the setup_memory()
    function which calls early_init_fdt_scan_reserved_mem(). Therefore,
    there is a possibility for memblock to allocate from any of the
    reserved memory regions.
    
    Hence, move the call to setup_memory() to be earlier in the init
    sequence so that the reserved memory regions are set aside before any
    allocations are done using memblock.
    
    Signed-off-by: Oreoluwa Babatunde <quic_obabatun@quicinc.com>
    Signed-off-by: Stafford Horne <shorne@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
parisc: Use irq_enter_rcu() to fix warning at kernel/context_tracking.c:367 [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Tue Nov 28 23:16:00 2023 +0100

    parisc: Use irq_enter_rcu() to fix warning at kernel/context_tracking.c:367
    
    [ Upstream commit 73cb4a2d8d7e0259f94046116727084f21e4599f ]
    
    Use irq*_rcu() functions to fix this kernel warning:
    
     WARNING: CPU: 0 PID: 0 at kernel/context_tracking.c:367 ct_irq_enter+0xa0/0xd0
     Modules linked in:
     CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.7.0-rc3-64bit+ #1037
     Hardware name: 9000/785/C3700
    
     IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000412cd758 00000000412cd75c
      IIR: 03ffe01f    ISR: 0000000000000000  IOR: 0000000043c20c20
      CPU:        0   CR30: 0000000041caa000 CR31: 0000000000000000
      ORIG_R28: 0000000000000005
      IAOQ[0]: ct_irq_enter+0xa0/0xd0
      IAOQ[1]: ct_irq_enter+0xa4/0xd0
      RP(r2): irq_enter+0x34/0x68
     Backtrace:
      [<000000004034a3ec>] irq_enter+0x34/0x68
      [<000000004030dc48>] do_cpu_irq_mask+0xc0/0x450
      [<0000000040303070>] intr_return+0x0/0xc
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phy: xilinx: add runtime PM support [+ + +]
Author: Piyush Mehta <piyush.mehta@amd.com>
Date:   Tue Jun 13 19:32:49 2023 +0530

    phy: xilinx: add runtime PM support
    
    [ Upstream commit b3db66f624468ab4a0385586bc7f4221e477d6b2 ]
    
    Added Runtime power management support to the xilinx phy driver and using
    DEFINE_RUNTIME_DEV_PM_OPS new macros allows the compiler to remove the
    unused dev_pm_ops structure and related functions if !CONFIG_PM without
    the need to mark the functions __maybe_unused.
    
    Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
    Link: https://lore.kernel.org/r/20230613140250.3018947-2-piyush.mehta@amd.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Stable-dep-of: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: xilinx: phy-zynqmp: dynamic clock support for power-save [+ + +]
Author: Piyush Mehta <piyush.mehta@amd.com>
Date:   Tue Jun 13 19:32:50 2023 +0530

    phy: xilinx: phy-zynqmp: dynamic clock support for power-save
    
    [ Upstream commit 25d70083351318b44ae699d92c042dcb18a738ea ]
    
    Enabling clock for all the lanes consumes power even PHY is active or
    inactive. To resolve this, enable/disable clocks in phy_init/phy_exit.
    
    By default clock is disabled for all the lanes. Whenever phy_init called
    from USB, SATA, or display driver, etc. It enabled the required clock
    for requested lane. On phy_exit cycle, it disabled clock for the active
    PHYs.
    
    During the suspend/resume cycle, each USB/ SATA/ display driver called
    phy_exit/phy_init individually. It disabled clock on exit, and enabled
    on initialization for the active PHYs.
    
    Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
    Link: https://lore.kernel.org/r/20230613140250.3018947-3-piyush.mehta@amd.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Stable-dep-of: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume [+ + +]
Author: Piyush Mehta <piyush.mehta@amd.com>
Date:   Mon Aug 5 11:29:07 2024 +0530

    phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume
    
    [ Upstream commit 5af9b304bc6010723c02f74de0bfd24ff19b1a10 ]
    
    On a few Kria KR260 Robotics Starter Kit the PS-GEM SGMII linkup is not
    happening after the resume. This is because serdes registers are reset
    when FPD is off (in suspend state) and needs to be reprogrammed in the
    resume path with the same default initialization as done in the first
    stage bootloader psu_init routine.
    
    To address the failure introduce a set of serdes registers to be saved in
    the suspend path and then restore it on resume.
    
    Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
    Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
    Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Link: https://lore.kernel.org/r/1722837547-2578381-1-git-send-email-radhey.shyam.pandey@amd.com
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

phy: zynqmp: Enable reference clock correctly [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Fri Jun 28 16:55:36 2024 -0400

    phy: zynqmp: Enable reference clock correctly
    
    commit 687d6bccb28238fcfa65f7c1badfdfeac498c428 upstream.
    
    Lanes can use other lanes' reference clocks, as determined by refclk.
    Use refclk to determine the clock to enable/disable instead of always
    using the lane's own reference clock. This ensures the clock selected in
    xpsgtr_configure_pll is the one enabled.
    
    For the other half of the equation, always program REF_CLK_SEL even when
    we are selecting the lane's own clock. This ensures that Linux's idea of
    the reference clock matches the hardware. We use the "local" clock mux
    for this instead of going through the ref clock network.
    
    Fixes: 25d700833513 ("phy: xilinx: phy-zynqmp: dynamic clock support for power-save")
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Link: https://lore.kernel.org/r/20240628205540.3098010-2-sean.anderson@linux.dev
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pinctrl: rockchip: correct RK3328 iomux width flag for GPIO2-B pins [+ + +]
Author: Huang-Huang Bao <i@eh5.me>
Date:   Tue Jul 9 18:54:28 2024 +0800

    pinctrl: rockchip: correct RK3328 iomux width flag for GPIO2-B pins
    
    commit 128f71fe014fc91efa1407ce549f94a9a9f1072c upstream.
    
    The base iomux offsets for each GPIO pin line are accumulatively
    calculated based off iomux width flag in rockchip_pinctrl_get_soc_data.
    If the iomux width flag is one of IOMUX_WIDTH_4BIT, IOMUX_WIDTH_3BIT or
    IOMUX_WIDTH_2BIT, the base offset for next pin line would increase by 8
    bytes, otherwise it would increase by 4 bytes.
    
    Despite most of GPIO2-B iomux have 2-bit data width, which can be fit
    into 4 bytes space with write mask, it actually take 8 bytes width for
    whole GPIO2-B line.
    
    Commit e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328
    GPIO2-B pins") wrongly set iomux width flag to 0, causing all base
    iomux offset for line after GPIO2-B to be calculated wrong. Fix the
    iomux width flag to IOMUX_WIDTH_2BIT so the offset after GPIO2-B is
    correctly increased by 8, matching the actual width of GPIO2-B iomux.
    
    Fixes: e8448a6c817c ("pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins")
    Cc: stable@vger.kernel.org
    Reported-by: Richard Kojedzinszky <richard@kojedz.in>
    Closes: https://lore.kernel.org/linux-rockchip/4f29b743202397d60edfb3c725537415@kojedz.in/
    Tested-by: Richard Kojedzinszky <richard@kojedz.in>
    Signed-off-by: Huang-Huang Bao <i@eh5.me>
    Reviewed-by: Heiko Stuebner <heiko@sntech.de>
    Tested-by: Daniel Golle <daniel@makrotopia.org>
    Tested-by: Trevor Woerner <twoerner@gmail.com>
    Link: https://lore.kernel.org/20240709105428.1176375-1-i@eh5.me
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pinctrl: single: fix potential NULL dereference in pcs_get_function() [+ + +]
Author: Ma Ke <make24@iscas.ac.cn>
Date:   Thu Aug 8 12:13:55 2024 +0800

    pinctrl: single: fix potential NULL dereference in pcs_get_function()
    
    commit 1c38a62f15e595346a1106025722869e87ffe044 upstream.
    
    pinmux_generic_get_function() can return NULL and the pointer 'function'
    was dereferenced without checking against NULL. Add checking of pointer
    'function' in pcs_get_function().
    
    Found by code review.
    
    Cc: stable@vger.kernel.org
    Fixes: 571aec4df5b7 ("pinctrl: single: Use generic pinmux helpers for managing functions")
    Signed-off-by: Ma Ke <make24@iscas.ac.cn>
    Link: https://lore.kernel.org/20240808041355.2766009-1-make24@iscas.ac.cn
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
platform/surface: aggregator: Fix warning when controller is destroyed in probe [+ + +]
Author: Maximilian Luz <luzmaximilian@gmail.com>
Date:   Sun Aug 11 14:46:44 2024 +0200

    platform/surface: aggregator: Fix warning when controller is destroyed in probe
    
    [ Upstream commit bc923d594db21bee0ead128eb4bb78f7e77467a4 ]
    
    There is a small window in ssam_serial_hub_probe() where the controller
    is initialized but has not been started yet. Specifically, between
    ssam_controller_init() and ssam_controller_start(). Any failure in this
    window, for example caused by a failure of serdev_device_open(),
    currently results in an incorrect warning being emitted.
    
    In particular, any failure in this window results in the controller
    being destroyed via ssam_controller_destroy(). This function checks the
    state of the controller and, in an attempt to validate that the
    controller has been cleanly shut down before we try and deallocate any
    resources, emits a warning if that state is not SSAM_CONTROLLER_STOPPED.
    
    However, since we have only just initialized the controller and have not
    yet started it, its state is SSAM_CONTROLLER_INITIALIZED. Note that this
    is the only point at which the controller has this state, as it will
    change after we start the controller with ssam_controller_start() and
    never revert back. Further, at this point no communication has taken
    place and the sender and receiver threads have not been started yet (and
    we may not even have an open serdev device either).
    
    Therefore, it is perfectly safe to call ssam_controller_destroy() with a
    state of SSAM_CONTROLLER_INITIALIZED. This, however, means that the
    warning currently being emitted is incorrect. Fix it by extending the
    check.
    
    Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem")
    Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
    Link: https://lore.kernel.org/r/20240811124645.246016-1-luzmaximilian@gmail.com
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: lg-laptop: fix %s null argument warning [+ + +]
Author: Gergo Koteles <soyer@irl.hu>
Date:   Wed Apr 3 16:34:27 2024 +0200

    platform/x86: lg-laptop: fix %s null argument warning
    
    [ Upstream commit e71c8481692582c70cdfd0996c20cdcc71e425d3 ]
    
    W=1 warns about null argument to kprintf:
    warning: ‘%s’ directive argument is null [-Wformat-overflow=]
    pr_info("product: %s  year: %d\n", product, year);
    
    Use "unknown" instead of NULL.
    
    Signed-off-by: Gergo Koteles <soyer@irl.hu>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Link: https://lore.kernel.org/r/33d40e976f08f82b9227d0ecae38c787fcc0c0b2.1712154684.git.soyer@irl.hu
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PM: core: Add EXPORT[_GPL]_SIMPLE_DEV_PM_OPS macros [+ + +]
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Fri Jan 7 18:17:20 2022 +0000

    PM: core: Add EXPORT[_GPL]_SIMPLE_DEV_PM_OPS macros
    
    [ Upstream commit 0ae101fdd3297b7165755340e05386f1e1379709 ]
    
    These macros are defined conditionally, according to CONFIG_PM:
    - if CONFIG_PM is enabled, these macros resolve to
      DEFINE_SIMPLE_DEV_PM_OPS(), and the dev_pm_ops symbol will be
      exported.
    
    - if CONFIG_PM is disabled, these macros will result in a dummy static
      dev_pm_ops to be created with the __maybe_unused flag. The dev_pm_ops
      will then be discarded by the compiler, along with the provided
      callback functions if they are not used anywhere else.
    
    In the second case, the symbol is not exported, which should be
    perfectly fine - users of the symbol should all use the pm_ptr() or
    pm_sleep_ptr() macro, so the dev_pm_ops marked as "extern" in the
    client's code will never be accessed.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PM: core: Remove DEFINE_UNIVERSAL_DEV_PM_OPS() macro [+ + +]
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Fri Jan 7 18:17:18 2022 +0000

    PM: core: Remove DEFINE_UNIVERSAL_DEV_PM_OPS() macro
    
    [ Upstream commit 3f4b32511a77bc5a05cfbf26fec94c4e1b1cf46a ]
    
    The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks
    for both runtime PM and system sleep, which is very likely to be a
    mistake, as a system sleep can be triggered while a given device is
    already PM-suspended, which would cause the suspend callback to be
    called twice.
    
    The amount of users of UNIVERSAL_DEV_PM_OPS() is also tiny (16
    occurences) compared to the number of places where
    SET_SYSTEM_SLEEP_PM_OPS() is used with pm_runtime_force_suspend() and
    pm_runtime_force_resume(), which makes me think that none of these cases
    are actually valid.
    
    As the new macro DEFINE_UNIVERSAL_DEV_PM_OPS() which was introduced to
    replace UNIVERSAL_DEV_PM_OPS() is currently unused, remove it before
    someone starts to use it in yet another invalid case.
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PM: runtime: Add DEFINE_RUNTIME_DEV_PM_OPS() macro [+ + +]
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Fri Jan 7 18:17:21 2022 +0000

    PM: runtime: Add DEFINE_RUNTIME_DEV_PM_OPS() macro
    
    [ Upstream commit 9d8619190031af0a314bee865262d8975473e4dd ]
    
    A lot of drivers create a dev_pm_ops struct with the system sleep
    suspend/resume callbacks set to pm_runtime_force_suspend() and
    pm_runtime_force_resume().
    
    These drivers can now use the DEFINE_RUNTIME_DEV_PM_OPS() macro, which
    will use pm_runtime_force_{suspend,resume}() as the system sleep
    callbacks, while having the same dead code removal characteristic that
    is already provided by DEFINE_SIMPLE_DEV_PM_OPS().
    
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/boot: Handle allocation failure in simple_realloc() [+ + +]
Author: Li zeming <zeming@nfschina.com>
Date:   Mon Dec 19 10:18:16 2022 +0800

    powerpc/boot: Handle allocation failure in simple_realloc()
    
    [ Upstream commit 69b0194ccec033c208b071e019032c1919c2822d ]
    
    simple_malloc() will return NULL when there is not enough memory left.
    Check pointer 'new' before using it to copy the old data.
    
    Signed-off-by: Li zeming <zeming@nfschina.com>
    [mpe: Reword subject, use change log from Christophe]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20221219021816.3012-1-zeming@nfschina.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/boot: Only free if realloc() succeeds [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Feb 29 22:51:49 2024 +1100

    powerpc/boot: Only free if realloc() succeeds
    
    [ Upstream commit f2d5bccaca3e8c09c9b9c8485375f7bdbb2631d2 ]
    
    simple_realloc() frees the original buffer (ptr) even if the
    reallocation failed.
    
    Fix it to behave like standard realloc() and only free the original
    buffer if the reallocation succeeded.
    
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240229115149.749264-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/xics: Check return value of kasprintf in icp_native_map_one_cpu [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Wed Nov 22 11:06:51 2023 +0800

    powerpc/xics: Check return value of kasprintf in icp_native_map_one_cpu
    
    [ Upstream commit 45b1ba7e5d1f6881050d558baf9bc74a2ae13930 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure. Ensure the allocation was successful
    by checking the pointer validity.
    
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231122030651.3818-1-chentao@kylinos.cn
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
quota: Remove BUG_ON from dqget() [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Fri Oct 20 13:34:08 2023 +0200

    quota: Remove BUG_ON from dqget()
    
    [ Upstream commit 249f374eb9b6b969c64212dd860cc1439674c4a8 ]
    
    dqget() checks whether dquot->dq_sb is set when returning it using
    BUG_ON. Firstly this doesn't work as an invalidation check for quite
    some time (we release dquot with dq_sb set these days), secondly using
    BUG_ON is quite harsh. Use WARN_ON_ONCE and check whether dquot is still
    hashed instead.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/rtrs: Fix the problem of variable not initialized fully [+ + +]
Author: Zhu Yanjun <yanjun.zhu@linux.dev>
Date:   Tue Sep 19 10:08:06 2023 +0800

    RDMA/rtrs: Fix the problem of variable not initialized fully
    
    [ Upstream commit c5930a1aa08aafe6ffe15b5d28fe875f88f6ac86 ]
    
    No functionality change. The variable which is not initialized fully
    will introduce potential risks.
    
    Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
    Link: https://lore.kernel.org/r/20230919020806.534183-1-yanjun.zhu@intel.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "drm/amd/display: Validate hw_points_num before using it" [+ + +]
Author: Alex Hung <alex.hung@amd.com>
Date:   Wed Oct 11 13:18:38 2023 -0600

    Revert "drm/amd/display: Validate hw_points_num before using it"
    
    commit 8f4bdbc8e99db6ec9cb0520748e49a2f2d7d1727 upstream.
    
    This reverts commit 58c3b3341cea4f75dc8c003b89f8a6dd8ec55e50.
    
    [WHY & HOW]
    The writeback series cause a regression in thunderbolt display.
    
    Signed-off-by: Alex Hung <alex.hung@amd.com>
    Reviewed-by: Harry Wentland <harry.wentland@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "MIPS: Loongson64: reset: Prioritise firmware service" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Aug 30 13:02:51 2024 +0200

    Revert "MIPS: Loongson64: reset: Prioritise firmware service"
    
    This reverts commit 77011a1d7a1a973d1657d06b658ce20f94172827 which is
    commit 4e7ca0b57f3bc09ba3e4ab86bf6b7c35134bfd04 upstream.
    
    Turns out to break the 5.15.y build, it should not have been backported
    that far.
    
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Cc: Jiaxun Yang <jiaxun.yang@flygoat.com>
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Link: https://lore.kernel.org/r/135ef4fd-4fc9-40b4-b188-8e64946f47c4@roeck-us.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/cio: rename bitmap_size() -> idset_bitmap_size() [+ + +]
Author: Alexander Lobakin <aleksander.lobakin@intel.com>
Date:   Wed Mar 27 16:23:45 2024 +0100

    s390/cio: rename bitmap_size() -> idset_bitmap_size()
    
    commit c1023f5634b9bfcbfff0dc200245309e3cde9b54 upstream.
    
    bitmap_size() is a pretty generic name and one may want to use it for
    a generic bitmap API function. At the same time, its logic is not
    "generic", i.e. it's not just `nbits -> size of bitmap in bytes`
    converter as it would be expected from its name.
    Add the prefix 'idset_' used throughout the file where the function
    resides.
    
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Acked-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/dasd: fix error recovery leading to data corruption on ESE devices [+ + +]
Author: Stefan Haberland <sth@linux.ibm.com>
Date:   Mon Aug 12 14:57:33 2024 +0200

    s390/dasd: fix error recovery leading to data corruption on ESE devices
    
    commit 7db4042336580dfd75cb5faa82c12cd51098c90b upstream.
    
    Extent Space Efficient (ESE) or thin provisioned volumes need to be
    formatted on demand during usual IO processing.
    
    The dasd_ese_needs_format function checks for error codes that signal
    the non existence of a proper track format.
    
    The check for incorrect length is to imprecise since other error cases
    leading to transport of insufficient data also have this flag set.
    This might lead to data corruption in certain error cases for example
    during a storage server warmstart.
    
    Fix by removing the check for incorrect length and replacing by
    explicitly checking for invalid track format in transport mode.
    
    Also remove the check for file protected since this is not a valid
    ESE handling case.
    
    Cc: stable@vger.kernel.org # 5.3+
    Fixes: 5e2b17e712cf ("s390/dasd: Add dynamic formatting support for ESE volumes")
    Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
    Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240812125733.126431-3-sth@linux.ibm.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/iucv: fix receive buffer virtual vs physical address confusion [+ + +]
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date:   Fri Feb 16 13:13:26 2024 +0100

    s390/iucv: fix receive buffer virtual vs physical address confusion
    
    [ Upstream commit 4e8477aeb46dfe74e829c06ea588dd00ba20c8cc ]
    
    Fix IUCV_IPBUFLST-type buffers virtual vs physical address confusion.
    This does not fix a bug since virtual and physical address spaces are
    currently the same.
    
    Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/smp,mcck: fix early IPI handling [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Tue Sep 5 15:49:37 2023 +0200

    s390/smp,mcck: fix early IPI handling
    
    [ Upstream commit 4a1725281fc5b0009944b1c0e1d2c1dc311a09ec ]
    
    Both the external call as well as the emergency signal submask bits in
    control register 0 are set before any interrupt handler is registered.
    
    Change the order and first register the interrupt handler and only then
    enable the interrupts by setting the corresponding bits in control
    register 0.
    
    This prevents that the second part of the machine check handler for
    early machine check handling is not executed: the machine check handler
    sends an IPI to the CPU it runs on. If the corresponding interrupts are
    enabled, but no interrupt handler is present, the interrupt is ignored.
    
    Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
    Acked-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/uv: Panic for set and remove shared access UVC errors [+ + +]
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>
Date:   Thu Aug 1 13:25:48 2024 +0200

    s390/uv: Panic for set and remove shared access UVC errors
    
    [ Upstream commit cff59d8631e1409ffdd22d9d717e15810181b32c ]
    
    The return value uv_set_shared() and uv_remove_shared() (which are
    wrappers around the share() function) is not always checked. The system
    integrity of a protected guest depends on the Share and Unshare UVCs
    being successful. This means that any caller that fails to check the
    return value will compromise the security of the protected guest.
    
    No code path that would lead to such violation of the security
    guarantees is currently exercised, since all the areas that are shared
    never get unshared during the lifetime of the system. This might
    change and become an issue in the future.
    
    The Share and Unshare UVCs can only fail in case of hypervisor
    misbehaviour (either a bug or malicious behaviour). In such cases there
    is no reasonable way forward, and the system needs to panic.
    
    This patch replaces the return at the end of the share() function with
    a panic, to guarantee system integrity.
    
    Fixes: 5abb9351dfd9 ("s390/uv: introduce guest side ultravisor code")
    Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
    Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
    Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
    Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240801112548.85303-1-imbrenda@linux.ibm.com
    Message-ID: <20240801112548.85303-1-imbrenda@linux.ibm.com>
    [frankja@linux.ibm.com: Fixed up patch subject]
    Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: aacraid: Fix double-free on probe failure [+ + +]
Author: Ben Hutchings <benh@debian.org>
Date:   Thu Aug 22 00:51:42 2024 +0200

    scsi: aacraid: Fix double-free on probe failure
    
    [ Upstream commit 919ddf8336f0b84c0453bac583808c9f165a85c2 ]
    
    aac_probe_one() calls hardware-specific init functions through the
    aac_driver_ident::init pointer, all of which eventually call down to
    aac_init_adapter().
    
    If aac_init_adapter() fails after allocating memory for aac_dev::queues,
    it frees the memory but does not clear that member.
    
    After the hardware-specific init function returns an error,
    aac_probe_one() goes down an error path that frees the memory pointed to
    by aac_dev::queues, resulting.in a double-free.
    
    Reported-by: Michael Gordon <m.gordon.zelenoborsky@gmail.com>
    Link: https://bugs.debian.org/1075855
    Fixes: 8e0c5ebde82b ("[SCSI] aacraid: Newer adapter communication iterface support")
    Signed-off-by: Ben Hutchings <benh@debian.org>
    Link: https://lore.kernel.org/r/ZsZvfqlQMveoL5KQ@decadent.org.uk
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: core: Fix the return value of scsi_logical_block_count() [+ + +]
Author: Chaotian Jing <chaotian.jing@mediatek.com>
Date:   Tue Aug 13 13:34:10 2024 +0800

    scsi: core: Fix the return value of scsi_logical_block_count()
    
    commit f03e94f23b04c2b71c0044c1534921b3975ef10c upstream.
    
    scsi_logical_block_count() should return the block count of a given SCSI
    command. The original implementation ended up shifting twice, leading to an
    incorrect count being returned. Fix the conversion between bytes and
    logical blocks.
    
    Cc: stable@vger.kernel.org
    Fixes: 6a20e21ae1e2 ("scsi: core: Add helper to return number of logical blocks in a request")
    Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
    Link: https://lore.kernel.org/r/20240813053534.7720-1-chaotian.jing@mediatek.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: lpfc: Initialize status local variable in lpfc_sli4_repost_sgl_list() [+ + +]
Author: Justin Tee <justin.tee@broadcom.com>
Date:   Wed Jan 31 10:50:56 2024 -0800

    scsi: lpfc: Initialize status local variable in lpfc_sli4_repost_sgl_list()
    
    [ Upstream commit 3d0f9342ae200aa1ddc4d6e7a573c6f8f068d994 ]
    
    A static code analyzer tool indicates that the local variable called status
    in the lpfc_sli4_repost_sgl_list() routine could be used to print garbage
    uninitialized values in the routine's log message.
    
    Fix by initializing to zero.
    
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Link: https://lore.kernel.org/r/20240131185112.149731-2-justintee8345@gmail.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: spi: Fix sshdr use [+ + +]
Author: Mike Christie <michael.christie@oracle.com>
Date:   Wed Oct 4 16:00:07 2023 -0500

    scsi: spi: Fix sshdr use
    
    [ Upstream commit 0b149cee836aa53989ea089af1cb9d90d7c6ac9e ]
    
    If scsi_execute_cmd returns < 0, it doesn't initialize the sshdr, so we
    shouldn't access the sshdr. If it returns 0, then the cmd executed
    successfully, so there is no need to check the sshdr. This has us access
    the sshdr when we get a return value > 0.
    
    Signed-off-by: Mike Christie <michael.christie@oracle.com>
    Link: https://lore.kernel.org/r/20231004210013.5601-7-michael.christie@oracle.com
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: John Garry <john.g.garry@oracle.com>
    Reviewed-by: Martin Wilck <mwilck@suse.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selinux: fix potential counting error in avc_add_xperms_decision() [+ + +]
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date:   Tue Aug 6 14:51:13 2024 +0800

    selinux: fix potential counting error in avc_add_xperms_decision()
    
    commit 379d9af3f3da2da1bbfa67baf1820c72a080d1f1 upstream.
    
    The count increases only when a node is successfully added to
    the linked list.
    
    Cc: stable@vger.kernel.org
    Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls")
    Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
    Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
soc: qcom: cmd-db: Map shared memory as WC, not WB [+ + +]
Author: Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Date:   Thu Jul 18 11:33:23 2024 +0530

    soc: qcom: cmd-db: Map shared memory as WC, not WB
    
    commit f9bb896eab221618927ae6a2f1d566567999839d upstream.
    
    Linux does not write into cmd-db region. This region of memory is write
    protected by XPU. XPU may sometime falsely detect clean cache eviction
    as "write" into the write protected region leading to secure interrupt
    which causes an endless loop somewhere in Trust Zone.
    
    The only reason it is working right now is because Qualcomm Hypervisor
    maps the same region as Non-Cacheable memory in Stage 2 translation
    tables. The issue manifests if we want to use another hypervisor (like
    Xen or KVM), which does not know anything about those specific mappings.
    
    Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC
    removes dependency on correct mappings in Stage 2 tables. This patch
    fixes the issue by updating the mapping to MEMREMAP_WC.
    
    I tested this on SA8155P with Xen.
    
    Fixes: 312416d9171a ("drivers: qcom: add command DB driver")
    Cc: stable@vger.kernel.org # 5.4+
    Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
    Tested-by: Nikita Travkin <nikita@trvn.ru> # sc7180 WoA in EL2
    Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
    Tested-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com>
    Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
    Link: https://lore.kernel.org/r/20240718-cmd_db_uncached-v2-1-f6cf53164c90@quicinc.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
soundwire: stream: fix programming slave ports for non-continous port maps [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Jul 29 16:01:57 2024 +0200

    soundwire: stream: fix programming slave ports for non-continous port maps
    
    commit ab8d66d132bc8f1992d3eb6cab8d32dda6733c84 upstream.
    
    Two bitmasks in 'struct sdw_slave_prop' - 'source_ports' and
    'sink_ports' - define which ports to program in
    sdw_program_slave_port_params().  The masks are used to get the
    appropriate data port properties ('struct sdw_get_slave_dpn_prop') from
    an array.
    
    Bitmasks can be non-continuous or can start from index different than 0,
    thus when looking for matching port property for given port, we must
    iterate over mask bits, not from 0 up to number of ports.
    
    This fixes allocation and programming slave ports, when a source or sink
    masks start from further index.
    
    Fixes: f8101c74aa54 ("soundwire: Add Master and Slave port programming")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20240729140157.326450-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ssb: Fix division by zero issue in ssb_calc_clock_rate [+ + +]
Author: Rand Deeb <rand.sec96@gmail.com>
Date:   Tue Sep 5 02:23:46 2023 +0300

    ssb: Fix division by zero issue in ssb_calc_clock_rate
    
    [ Upstream commit e0b5127fa134fe0284d58877b6b3133939c8b3ce ]
    
    In ssb_calc_clock_rate(), there is a potential issue where the value of
    m1 could be zero due to initialization using clkfactor_f6_resolv(). This
    situation raised concerns about the possibility of a division by zero
    error.
    
    We fixed it by following the suggestions provided by Larry Finger
    <Larry.Finger@lwfinger.net> and Michael Büsch <m@bues.ch>. The fix
    involves returning a value of 1 instead of 0 in clkfactor_f6_resolv().
    This modification ensures the proper functioning of the code and
    eliminates the risk of division by zero errors.
    
    Signed-off-by: Rand Deeb <rand.sec96@gmail.com>
    Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
    Acked-by: Michael Büsch <m@bues.ch>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230904232346.34991-1-rand.sec96@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
staging: iio: resolver: ad2s1210: fix use before initialization [+ + +]
Author: David Lechner <dlechner@baylibre.com>
Date:   Fri Sep 29 12:23:07 2023 -0500

    staging: iio: resolver: ad2s1210: fix use before initialization
    
    [ Upstream commit 7fe2d05cee46b1c4d9f1efaeab08cc31a0dfff60 ]
    
    This fixes a use before initialization in ad2s1210_probe(). The
    ad2s1210_setup_gpios() function uses st->sdev but it was being called
    before this field was initialized.
    
    Signed-off-by: David Lechner <dlechner@baylibre.com>
    Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-2-fa4364281745@baylibre.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

staging: ks7010: disable bh on tx_dev_lock [+ + +]
Author: Chengfeng Ye <dg573847474@gmail.com>
Date:   Tue Sep 26 16:13:23 2023 +0000

    staging: ks7010: disable bh on tx_dev_lock
    
    [ Upstream commit 058cbee52ccd7be77e373d31a4f14670cfd32018 ]
    
    As &priv->tx_dev.tx_dev_lock is also acquired by xmit callback which
    could be call from timer under softirq context, use spin_lock_bh()
    on it to prevent potential deadlock.
    
    hostif_sme_work()
    --> hostif_sme_set_pmksa()
    --> hostif_mib_set_request()
    --> ks_wlan_hw_tx()
    --> spin_lock(&priv->tx_dev.tx_dev_lock)
    
    ks_wlan_start_xmit()
    --> hostif_data_request()
    --> ks_wlan_hw_tx()
    --> spin_lock(&priv->tx_dev.tx_dev_lock)
    
    Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
    Link: https://lore.kernel.org/r/20230926161323.41928-1-dg573847474@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sunrpc: don't change ->sv_stats if it doesn't exist [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 10:55:39 2024 -0400

    sunrpc: don't change ->sv_stats if it doesn't exist
    
    [ Upstream commit ab42f4d9a26f1723dcfd6c93fcf768032b2bb5e7 ]
    
    We check for the existence of ->sv_stats elsewhere except in the core
    processing code.  It appears that only nfsd actual exports these values
    anywhere, everybody else just has a write only copy of sv_stats in their
    svc_program.  Add a check for ->sv_stats before every adjustment to
    allow us to eliminate the stats struct from all the users who don't
    report the stats.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    [ cel: adjusted to apply to v5.15.y ]
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sunrpc: pass in the sv_stats struct through svc_create_pooled [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 10:55:41 2024 -0400

    sunrpc: pass in the sv_stats struct through svc_create_pooled
    
    [ Upstream commit f094323867668d50124886ad884b665de7319537 ]
    
    Since only one service actually reports the rpc stats there's not much
    of a reason to have a pointer to it in the svc_program struct.  Adjust
    the svc_create_pooled function to take the sv_stats as an argument and
    pass the struct through there as desired instead of getting it from the
    svc_program->pg_stats.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    [ cel: adjusted to apply to v5.15.y ]
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sunrpc: remove ->pg_stats from svc_program [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 10:55:42 2024 -0400

    sunrpc: remove ->pg_stats from svc_program
    
    [ Upstream commit 3f6ef182f144dcc9a4d942f97b6a8ed969f13c95 ]
    
    Now that this isn't used anywhere, remove it.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    [ cel: adjusted to apply to v5.15.y ]
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

sunrpc: use the struct net as the svc proc private [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Wed Aug 21 10:55:43 2024 -0400

    sunrpc: use the struct net as the svc proc private
    
    [ Upstream commit 418b9687dece5bd763c09b5c27a801a7e3387be9 ]
    
    nfsd is the only thing using this helper, and it doesn't use the private
    currently.  When we switch to per-network namespace stats we will need
    the struct net * in order to get to the nfsd_net.  Use the net as the
    proc private so we can utilize this when we make the switch over.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tc-testing: don't access non-existent variable on exception [+ + +]
Author: Simon Horman <horms@kernel.org>
Date:   Thu Aug 15 16:37:13 2024 +0100

    tc-testing: don't access non-existent variable on exception
    
    [ Upstream commit a0c9fe5eecc97680323ee83780ea3eaf440ba1b7 ]
    
    Since commit 255c1c7279ab ("tc-testing: Allow test cases to be skipped")
    the variable test_ordinal doesn't exist in call_pre_case().
    So it should not be accessed when an exception occurs.
    
    This resolves the following splat:
    
      ...
      During handling of the above exception, another exception occurred:
    
      Traceback (most recent call last):
        File ".../tdc.py", line 1028, in <module>
          main()
        File ".../tdc.py", line 1022, in main
          set_operation_mode(pm, parser, args, remaining)
        File ".../tdc.py", line 966, in set_operation_mode
          catresults = test_runner_serial(pm, args, alltests)
        File ".../tdc.py", line 642, in test_runner_serial
          (index, tsr) = test_runner(pm, args, alltests)
        File ".../tdc.py", line 536, in test_runner
          res = run_one_test(pm, args, index, tidx)
        File ".../tdc.py", line 419, in run_one_test
          pm.call_pre_case(tidx)
        File ".../tdc.py", line 146, in call_pre_case
          print('test_ordinal is {}'.format(test_ordinal))
      NameError: name 'test_ordinal' is not defined
    
    Fixes: 255c1c7279ab ("tc-testing: Allow test cases to be skipped")
    Signed-off-by: Simon Horman <horms@kernel.org>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Link: https://patch.msgid.link/20240815-tdc-test-ordinal-v1-1-0255c122a427@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thunderbolt: Mark XDomain as unplugged when router is removed [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Thu Jun 13 15:05:03 2024 +0300

    thunderbolt: Mark XDomain as unplugged when router is removed
    
    commit e2006140ad2e01a02ed0aff49cc2ae3ceeb11f8d upstream.
    
    I noticed that when we do discrete host router NVM upgrade and it gets
    hot-removed from the PCIe side as a result of NVM firmware authentication,
    if there is another host connected with enabled paths we hang in tearing
    them down. This is due to fact that the Thunderbolt networking driver
    also tries to cleanup the paths and ends up blocking in
    tb_disconnect_xdomain_paths() waiting for the domain lock.
    
    However, at this point we already cleaned the paths in tb_stop() so
    there is really no need for tb_disconnect_xdomain_paths() to do that
    anymore. Furthermore it already checks if the XDomain is unplugged and
    bails out early so take advantage of that and mark the XDomain as
    unplugged when we remove the parent router.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tools: move alignment-related macros to new [+ + +]
Author: Alexander Lobakin <aleksander.lobakin@intel.com>
Date:   Wed Mar 27 16:23:48 2024 +0100

    tools: move alignment-related macros to new <linux/align.h>
    
    commit 10a04ff09bcc39e0044190ffe9f00f998f13647c upstream.
    
    Currently, tools have *ALIGN*() macros scattered across the unrelated
    headers, as there are only 3 of them and they were added separately
    each time on an as-needed basis.
    Anyway, let's make it more consistent with the kernel headers and allow
    using those macros outside of the mentioned headers. Create
    <linux/align.h> inside the tools/ folder and include it where needed.
    
    Signed-off-by: Yury Norov <yury.norov@gmail.com>
    Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: cdnsp: fix for Link TRB with TC [+ + +]
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Wed Aug 21 06:07:42 2024 +0000

    usb: cdnsp: fix for Link TRB with TC
    
    commit 740f2e2791b98e47288b3814c83a3f566518fed2 upstream.
    
    Stop Endpoint command on LINK TRB with TC bit set to 1 causes that
    internal cycle bit can have incorrect state after command complete.
    In consequence empty transfer ring can be incorrectly detected
    when EP is resumed.
    NOP TRB before LINK TRB avoid such scenario. Stop Endpoint command
    is then on NOP TRB and internal cycle bit is not changed and have
    correct value.
    
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    cc: <stable@vger.kernel.org>
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Reviewed-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/PH7PR07MB953878279F375CCCE6C6F40FDD8E2@PH7PR07MB9538.namprd07.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: cdnsp: fix incorrect index in cdnsp_get_hw_deq function [+ + +]
Author: Pawel Laszczak <pawell@cadence.com>
Date:   Tue Aug 20 08:21:19 2024 +0000

    usb: cdnsp: fix incorrect index in cdnsp_get_hw_deq function
    
    commit 0497a356d3c498221eb0c1edc1e8985816092f12 upstream.
    
    Patch fixes the incorrect "stream_id" table index instead of
    "ep_index" used in cdnsp_get_hw_deq function.
    
    Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
    cc: stable@vger.kernel.org
    Signed-off-by: Pawel Laszczak <pawell@cadence.com>
    Reviewed-by: Peter Chen <peter.chen@kernel.org>
    Link: https://lore.kernel.org/r/PH7PR07MB95381F2182688811D5C711CEDD8D2@PH7PR07MB9538.namprd07.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: core: sysfs: Unmerge @usb3_hardware_lpm_attr_group in remove_power_attributes() [+ + +]
Author: Zijun Hu <quic_zijuhu@quicinc.com>
Date:   Tue Aug 20 19:01:27 2024 +0800

    usb: core: sysfs: Unmerge @usb3_hardware_lpm_attr_group in remove_power_attributes()
    
    commit 3a8839bbb86da7968a792123ed2296d063871a52 upstream.
    
    Device attribute group @usb3_hardware_lpm_attr_group is merged by
    add_power_attributes(), but it is not unmerged explicitly, fixed by
    unmerging it in remove_power_attributes().
    
    Fixes: 655fe4effe0f ("usbcore: add sysfs support to xHCI usb3 hardware LPM")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
    Link: https://lore.kernel.org/r/20240820-sysfs_fix-v2-1-a9441487077e@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: core: Prevent USB core invalid event buffer address access [+ + +]
Author: Selvarasu Ganesan <selvarasu.g@samsung.com>
Date:   Thu Aug 15 12:18:31 2024 +0530

    usb: dwc3: core: Prevent USB core invalid event buffer address access
    
    commit 14e497183df28c006603cc67fd3797a537eef7b9 upstream.
    
    This commit addresses an issue where the USB core could access an
    invalid event buffer address during runtime suspend, potentially causing
    SMMU faults and other memory issues in Exynos platforms. The problem
    arises from the following sequence.
            1. In dwc3_gadget_suspend, there is a chance of a timeout when
            moving the USB core to the halt state after clearing the
            run/stop bit by software.
            2. In dwc3_core_exit, the event buffer is cleared regardless of
            the USB core's status, which may lead to an SMMU faults and
            other memory issues. if the USB core tries to access the event
            buffer address.
    
    To prevent this hardware quirk on Exynos platforms, this commit ensures
    that the event buffer address is not cleared by software  when the USB
    core is active during runtime suspend by checking its status before
    clearing the buffer address.
    
    Cc: stable <stable@kernel.org>
    Signed-off-by: Selvarasu Ganesan <selvarasu.g@samsung.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240815064836.1491-1-selvarasu.g@samsung.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: core: Skip setting event buffers for host only controllers [+ + +]
Author: Krishna Kurapati <quic_kriskura@quicinc.com>
Date:   Sat Apr 20 10:18:55 2024 +0530

    usb: dwc3: core: Skip setting event buffers for host only controllers
    
    [ Upstream commit 89d7f962994604a3e3d480832788d06179abefc5 ]
    
    On some SoC's like SA8295P where the tertiary controller is host-only
    capable, GEVTADDRHI/LO, GEVTSIZ, GEVTCOUNT registers are not accessible.
    Trying to access them leads to a crash.
    
    For DRD/Peripheral supported controllers, event buffer setup is done
    again in gadget_pullup. Skip setup or cleanup of event buffers if
    controller is host-only capable.
    
    Suggested-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Reviewed-by: Bjorn Andersson <andersson@kernel.org>
    Tested-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20240420044901.884098-4-quic_kriskura@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: dwc3: omap: add missing depopulate in probe error path [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Aug 16 09:54:08 2024 +0200

    usb: dwc3: omap: add missing depopulate in probe error path
    
    commit 2aa765a43817ec8add990f83c8e54a9a5d87aa9c upstream.
    
    Depopulate device in probe error paths to fix leak of children
    resources.
    
    Fixes: ee249b455494 ("usb: dwc3: omap: remove IRQ_NOAUTOEN used with shared irq")
    Cc: stable@vger.kernel.org
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
    Link: https://lore.kernel.org/r/20240816075409.23080-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: st: add missing depopulate in probe error path [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Aug 14 11:39:57 2024 +0200

    usb: dwc3: st: add missing depopulate in probe error path
    
    commit cd4897bfd14f6a5388b21ba45a066541a0425199 upstream.
    
    Depopulate device in probe error paths to fix leak of children
    resources.
    
    Fixes: f83fca0707c6 ("usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Link: https://lore.kernel.org/r/20240814093957.37940-2-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc3: st: fix probed platform device ref count on probe error path [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Wed Aug 14 11:39:56 2024 +0200

    usb: dwc3: st: fix probed platform device ref count on probe error path
    
    commit ddfcfeba891064b88bb844208b43bef2ef970f0c upstream.
    
    The probe function never performs any paltform device allocation, thus
    error path "undo_platform_dev_alloc" is entirely bogus.  It drops the
    reference count from the platform device being probed.  If error path is
    triggered, this will lead to unbalanced device reference counts and
    premature release of device resources, thus possible use-after-free when
    releasing remaining devm-managed resources.
    
    Fixes: f83fca0707c6 ("usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC")
    Cc: stable@vger.kernel.org
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
    Link: https://lore.kernel.org/r/20240814093957.37940-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: fsl: Increase size of name buffer for endpoints [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Feb 23 18:33:16 2024 +0100

    usb: gadget: fsl: Increase size of name buffer for endpoints
    
    [ Upstream commit 87850f6cc20911e35eafcbc1d56b0d649ae9162d ]
    
    This fixes a W=1 warning about sprintf writing up to 16 bytes into a
    buffer of size 14. There is no practical relevance because there are not
    more than 32 endpoints.
    
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Link: https://lore.kernel.org/r/6754df25c56aae04f8110594fad2cd2452b1862a.1708709120.git.u.kleine-koenig@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
USB: serial: option: add MeiG Smart SRM825L [+ + +]
Author: ZHANG Yuntian <yt@radxa.com>
Date:   Sat Aug 3 15:46:07 2024 +0800

    USB: serial: option: add MeiG Smart SRM825L
    
    commit 9a471de516c35219d1722c13367191ce1f120fe9 upstream.
    
    Add support for MeiG Smart SRM825L which is based on Qualcomm 315 chip.
    
    T:  Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
    D:  Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
    P:  Vendor=2dee ProdID=4d22 Rev= 4.14
    S:  Manufacturer=MEIG
    S:  Product=LTE-A Module
    S:  SerialNumber=6f345e48
    C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=896mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    E:  Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
    
    Signed-off-by: ZHANG Yuntian <yt@radxa.com>
    Link: https://lore.kernel.org/0041DFA5200EFB1B+20240803074619.563116-1-yt@radxa.com/
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vfs: Don't evict inode under the inode lru traversing context [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Fri Aug 9 11:16:28 2024 +0800

    vfs: Don't evict inode under the inode lru traversing context
    
    commit 2a0629834cd82f05d424bbc193374f9a43d1f87d upstream.
    
    The inode reclaiming process(See function prune_icache_sb) collects all
    reclaimable inodes and mark them with I_FREEING flag at first, at that
    time, other processes will be stuck if they try getting these inodes
    (See function find_inode_fast), then the reclaiming process destroy the
    inodes by function dispose_list(). Some filesystems(eg. ext4 with
    ea_inode feature, ubifs with xattr) may do inode lookup in the inode
    evicting callback function, if the inode lookup is operated under the
    inode lru traversing context, deadlock problems may happen.
    
    Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
            if ea_inode feature is enabled, the lookup process will be stuck
            under the evicting context like this:
    
     1. File A has inode i_reg and an ea inode i_ea
     2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea
     3. Then, following three processes running like this:
    
        PA                              PB
     echo 2 > /proc/sys/vm/drop_caches
      shrink_slab
       prune_dcache_sb
       // i_reg is added into lru, lru->i_ea->i_reg
       prune_icache_sb
        list_lru_walk_one
         inode_lru_isolate
          i_ea->i_state |= I_FREEING // set inode state
         inode_lru_isolate
          __iget(i_reg)
          spin_unlock(&i_reg->i_lock)
          spin_unlock(lru_lock)
                                         rm file A
                                          i_reg->nlink = 0
          iput(i_reg) // i_reg->nlink is 0, do evict
           ext4_evict_inode
            ext4_xattr_delete_inode
             ext4_xattr_inode_dec_ref_all
              ext4_xattr_inode_iget
               ext4_iget(i_ea->i_ino)
                iget_locked
                 find_inode_fast
                  __wait_on_freeing_inode(i_ea) ----→ AA deadlock
        dispose_list // cannot be executed by prune_icache_sb
         wake_up_bit(&i_ea->i_state)
    
    Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
            deleting process holds BASEHD's wbuf->io_mutex while getting the
            xattr inode, which could race with inode reclaiming process(The
            reclaiming process could try locking BASEHD's wbuf->io_mutex in
            inode evicting function), then an ABBA deadlock problem would
            happen as following:
    
     1. File A has inode ia and a xattr(with inode ixa), regular file B has
        inode ib and a xattr.
     2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa
     3. Then, following three processes running like this:
    
            PA                PB                        PC
                    echo 2 > /proc/sys/vm/drop_caches
                     shrink_slab
                      prune_dcache_sb
                      // ib and ia are added into lru, lru->ixa->ib->ia
                      prune_icache_sb
                       list_lru_walk_one
                        inode_lru_isolate
                         ixa->i_state |= I_FREEING // set inode state
                        inode_lru_isolate
                         __iget(ib)
                         spin_unlock(&ib->i_lock)
                         spin_unlock(lru_lock)
                                                       rm file B
                                                        ib->nlink = 0
     rm file A
      iput(ia)
       ubifs_evict_inode(ia)
        ubifs_jnl_delete_inode(ia)
         ubifs_jnl_write_inode(ia)
          make_reservation(BASEHD) // Lock wbuf->io_mutex
          ubifs_iget(ixa->i_ino)
           iget_locked
            find_inode_fast
             __wait_on_freeing_inode(ixa)
              |          iput(ib) // ib->nlink is 0, do evict
              |           ubifs_evict_inode
              |            ubifs_jnl_delete_inode(ib)
              ↓             ubifs_jnl_write_inode
         ABBA deadlock ←-----make_reservation(BASEHD)
                       dispose_list // cannot be executed by prune_icache_sb
                        wake_up_bit(&ixa->i_state)
    
    Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
    to pin the inode in memory while inode_lru_isolate() reclaims its pages
    instead of using ordinary inode reference. This way inode deletion
    cannot be triggered from inode_lru_isolate() thus avoiding the deadlock.
    evict() is made to wait for I_LRU_ISOLATING to be cleared before
    proceeding with inode cleanup.
    
    Link: https://lore.kernel.org/all/37c29c42-7685-d1f0-067d-63582ffac405@huaweicloud.com/
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219022
    Fixes: e50e5129f384 ("ext4: xattr-in-inode support")
    Fixes: 7959cf3a7506 ("ubifs: journal: Handle xattrs like files")
    Cc: stable@vger.kernel.org
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Link: https://lore.kernel.org/r/20240809031628.1069873-1-chengzhihao@huaweicloud.com
    Reviewed-by: Jan Kara <jack@suse.cz>
    Suggested-by: Jan Kara <jack@suse.cz>
    Suggested-by: Mateusz Guzik <mjguzik@gmail.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
virtiofs: forbid newlines in tags [+ + +]
Author: Stefan Hajnoczi <stefanha@redhat.com>
Date:   Mon Feb 12 19:11:47 2024 -0500

    virtiofs: forbid newlines in tags
    
    [ Upstream commit 40488cc16f7ea0d193a4e248f0d809c25cc377db ]
    
    Newlines in virtiofs tags are awkward for users and potential vectors
    for string injection attacks.
    
    Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
    Reviewed-by: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: cfg80211: check wiphy mutex is held for wdev mutex [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon Aug 28 13:59:56 2023 +0200

    wifi: cfg80211: check wiphy mutex is held for wdev mutex
    
    [ Upstream commit 1474bc87fe57deac726cc10203f73daa6c3212f7 ]
    
    This might seem pretty pointless rather than changing the locking
    immediately, but it seems safer to run for a while with checks and
    the old locking scheme, and then remove the wdev lock later.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cw1200: Avoid processing an invalid TIM IE [+ + +]
Author: Jeff Johnson <quic_jjohnson@quicinc.com>
Date:   Thu Aug 31 11:22:57 2023 -0700

    wifi: cw1200: Avoid processing an invalid TIM IE
    
    [ Upstream commit b7bcea9c27b3d87b54075735c870500123582145 ]
    
    While converting struct ieee80211_tim_ie::virtual_map to be a flexible
    array it was observed that the TIM IE processing in cw1200_rx_cb()
    could potentially process a malformed IE in a manner that could result
    in a buffer over-read. Add logic to verify that the TIM IE length is
    large enough to hold a valid TIM payload before processing it.
    
    Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230831-ieee80211_tim_ie-v3-1-e10ff584ab5d@quicinc.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: abort scan when rfkill on but device enabled [+ + +]
Author: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Date:   Wed Oct 4 12:36:28 2023 +0300

    wifi: iwlwifi: abort scan when rfkill on but device enabled
    
    [ Upstream commit 3c6a0b1f0add72e7f522bc9145222b86d0a7712a ]
    
    In RFKILL we first set the RFKILL bit, then we abort scan
    (if one exists) by waiting for the notification from FW
    and notifying mac80211. And then we stop the device.
    But in case we have a scan ongoing in the period of time between
    rfkill on and before the device is stopped - we will not wait for the
    FW notification because of the iwl_mvm_is_radio_killed() condition,
    and then the scan_status and uid_status are misconfigured,
    (scan_status is cleared but uid_status not)
    and when the notification suddenly arrives (before stopping the device)
    we will get into the assert about scan_status and uid_status mismatch.
    Fix this by waiting for FW notif when rfkill is on but the device isn't
    disabled yet.
    
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231004123422.c43b69aa2c77.Icc7b5efb47974d6f499156ff7510b786e177993b@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: fw: Fix debugfs command sending [+ + +]
Author: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Date:   Wed Oct 4 12:36:32 2023 +0300

    wifi: iwlwifi: fw: Fix debugfs command sending
    
    [ Upstream commit 048449fc666d736a1a17d950fde0b5c5c8fd10cc ]
    
    During debugfs command handling transport function is used directly,
    this bypasses the locking used by runtime operation function
    and leads to a kernel warning when two commands are
    sent in parallel.
    
    Fix it by using runtime operations function when sending
    debugfs command.
    
    Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Link: https://lore.kernel.org/r/20231004123422.4f80ac90658a.Ia1dfa1195c919f3002fe08db3eefbd2bfa921bbf@changeid
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: fix BA session teardown race [+ + +]
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Aug 29 20:16:11 2023 +0200

    wifi: mac80211: fix BA session teardown race
    
    [ Upstream commit 05f136220d17839eb7c155f015ace9152f603225 ]
    
    As previously reported by Alexander, whose commit 69403bad97aa
    ("wifi: mac80211: sdata can be NULL during AMPDU start") I'm
    reverting as part of this commit, there's a race between station
    destruction and aggregation setup, where the aggregation setup
    can happen while the station is being removed and queue the work
    after ieee80211_sta_tear_down_BA_sessions() has already run in
    __sta_info_destroy_part1(), and thus the worker will run with a
    now freed station. In his case, this manifested in a NULL sdata
    pointer, but really there's no guarantee whatsoever.
    
    The real issue seems to be that it's possible at all to have a
    situation where this occurs - we want to stop the BA sessions
    when doing _part1, but we cannot be sure, and WLAN_STA_BLOCK_BA
    isn't necessarily effective since we don't know that the setup
    isn't concurrently running and already got past the check.
    
    Simply call ieee80211_sta_tear_down_BA_sessions() again in the
    second part of station destruction, since at that point really
    nothing else can hold a reference to the station any more.
    
    Also revert the sdata checks since those are just misleading at
    this point.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mwifiex: duplicate static structs used in driver instances [+ + +]
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Fri Aug 9 10:11:33 2024 +0200

    wifi: mwifiex: duplicate static structs used in driver instances
    
    commit 27ec3c57fcadb43c79ed05b2ea31bc18c72d798a upstream.
    
    mwifiex_band_2ghz and mwifiex_band_5ghz are statically allocated, but
    used and modified in driver instances. Duplicate them before using
    them in driver instances so that different driver instances do not
    influence each other.
    
    This was observed on a board which has one PCIe and one SDIO mwifiex
    adapter. It blew up in mwifiex_setup_ht_caps(). This was called with
    the statically allocated struct which is modified in this function.
    
    Cc: stable@vger.kernel.org
    Fixes: d6bffe8bb520 ("mwifiex: support for creation of AP interface")
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Acked-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://patch.msgid.link/20240809-mwifiex-duplicate-static-structs-v1-1-6837b903b1a4@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86: Increase brk randomness entropy for 64-bit systems [+ + +]
Author: Kees Cook <kees@kernel.org>
Date:   Fri Feb 16 22:25:43 2024 -0800

    x86: Increase brk randomness entropy for 64-bit systems
    
    [ Upstream commit 44c76825d6eefee9eb7ce06c38e1a6632ac7eb7d ]
    
    In commit c1d171a00294 ("x86: randomize brk"), arch_randomize_brk() was
    defined to use a 32MB range (13 bits of entropy), but was never increased
    when moving to 64-bit. The default arch_randomize_brk() uses 32MB for
    32-bit tasks, and 1GB (18 bits of entropy) for 64-bit tasks.
    
    Update x86_64 to match the entropy used by arm64 and other 64-bit
    architectures.
    
    Reported-by: y0un9n132@gmail.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Jiri Kosina <jkosina@suse.com>
    Closes: https://lore.kernel.org/linux-hardening/CA+2EKTVLvc8hDZc+2Yhwmus=dzOUG5E4gV7ayCbu0MPJTZzWkw@mail.gmail.com/
    Link: https://lore.kernel.org/r/20240217062545.1631668-1-keescook@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Thu Aug 15 17:11:17 2024 +0300

    xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration
    
    commit af8e119f52e9c13e556be9e03f27957554a84656 upstream.
    
    re-enumerating full-speed devices after a failed address device command
    can trigger a NULL pointer dereference.
    
    Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size
    value during enumeration. Usb core calls usb_ep0_reinit() in this case,
    which ends up calling xhci_configure_endpoint().
    
    On Panther point xHC the xhci_configure_endpoint() function will
    additionally check and reserve bandwidth in software. Other hosts do
    this in hardware
    
    If xHC address device command fails then a new xhci_virt_device structure
    is allocated as part of re-enabling the slot, but the bandwidth table
    pointers are not set up properly here.
    This triggers the NULL pointer dereference the next time usb_ep0_reinit()
    is called and xhci_configure_endpoint() tries to check and reserve
    bandwidth
    
    [46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd
    [46710.713699] usb 3-1: Device not responding to setup address.
    [46710.917684] usb 3-1: Device not responding to setup address.
    [46711.125536] usb 3-1: device not accepting address 5, error -71
    [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008
    [46711.125600] #PF: supervisor read access in kernel mode
    [46711.125603] #PF: error_code(0x0000) - not-present page
    [46711.125606] PGD 0 P4D 0
    [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI
    [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1
    [46711.125620] Hardware name: Gigabyte Technology Co., Ltd.
    [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore]
    [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c
    
    Fix this by making sure bandwidth table pointers are set up correctly
    after a failed address device command, and additionally by avoiding
    checking for bandwidth in cases like this where no actual endpoints are
    added or removed, i.e. only context for default control endpoint 0 is
    evaluated.
    
    Reported-by: Karel Balej <balejk@matfyz.cz>
    Closes: https://lore.kernel.org/linux-usb/D3CKQQAETH47.1MUO22RTCH2O3@matfyz.cz/
    Cc: stable@vger.kernel.org
    Fixes: 651aaf36a7d7 ("usb: xhci: Handle USB transaction error on address command")
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20240815141117.2702314-2-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>