Changelog in Linux kernel 4.19.321

 
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: 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>

 
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>

 
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_core: Fix not handling link timeouts propertly [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Mon Sep 26 15:44:42 2022 -0700

    Bluetooth: hci_core: Fix not handling link timeouts propertly
    
    [ Upstream commit 116523c8fac05d1d26f748fee7919a4ec5df67ea ]
    
    Change that introduced the use of __check_timeout did not account for
    link types properly, it always assumes ACL_LINK is used thus causing
    hdev->acl_last_tx to be used even in case of LE_LINK and then again
    uses ACL_LINK with hci_link_tx_to.
    
    To fix this __check_timeout now takes the link type as parameter and
    then procedure to use the right last_tx based on the link type and pass
    it to hci_link_tx_to.
    
    Fixes: 1b1d29e51499 ("Bluetooth: Make use of __check_timeout on hci_sched_le")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Tested-by: David Beinder <david@beinder.at>
    Stable-dep-of: 932021a11805 ("Bluetooth: hci_core: Fix LE quote calculation")
    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: Make use of __check_timeout on hci_sched_le [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Wed Jan 15 13:02:18 2020 -0800

    Bluetooth: Make use of __check_timeout on hci_sched_le
    
    [ Upstream commit 1b1d29e5149990e44634b2e681de71effd463591 ]
    
    This reuse __check_timeout on hci_sched_le following the same logic
    used hci_sched_acl.
    
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Stable-dep-of: 932021a11805 ("Bluetooth: hci_core: Fix LE quote calculation")
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
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: 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>

 
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>

 
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
    
    commit 1e1fd567d32fcf7544c6e09e0e5bc6c650da6e23 upstream.
    
    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: 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/fb-helper: set x/yres_virtual in drm_fb_helper_check_var [+ + +]
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 4 21:40:36 2023 +0200

    drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
    
    commit 1935f0deb6116dd785ea64d8035eab0ff441255b upstream.
    
    Drivers are supposed to fix this up if needed if they don't outright
    reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
    sizes in fb_set_var()").
    
    Reported-by: syzbot+20dcf81733d43ddff661@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb008888bf06cefc
    Cc: stable@vger.kernel.org # v5.4+
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: Javier Martinez Canillas <javierm@redhat.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230404194038.472803-1-daniel.vetter@ffwll.ch
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
drm/msm: use drm_debug_enabled() to check for debug categories [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Sep 24 15:59:02 2019 +0300

    drm/msm: use drm_debug_enabled() to check for debug categories
    
    [ Upstream commit d8db0b36d888b6a5eb392f112dc156e694de2369 ]
    
    Allow better abstraction of the drm_debug global variable in the
    future. No functional changes.
    
    v2: Move unlikely() to drm_debug_enabled()
    
    Cc: Rob Clark <robdclark@gmail.com>
    Cc: Sean Paul <sean@poorly.run>
    Cc: linux-arm-msm@vger.kernel.org
    Cc: freedreno@lists.freedesktop.org
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/c7142cdebb5f6fed527272b333cd6c43c0aa68ec.1569329774.git.jani.nikula@intel.com
    Stable-dep-of: df24373435f5 ("drm/msm/dpu: don't play tricks with debug macros")
    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>

 
fbcon: Prevent that screen size is smaller than font size [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Thu Aug 29 18:14:03 2024 +0200

    fbcon: Prevent that screen size is smaller than font size
    
    commit e64242caef18b4a5840b0e7a9bff37abd4f4f933 upstream.
    
    We need to prevent that users configure a screen size which is smaller than the
    currently selected font size. Otherwise rendering chars on the screen will
    access memory outside the graphics memory region.
    
    This patch adds a new function fbcon_modechange_possible() which
    implements this check and which later may be extended with other checks
    if necessary.  The new function is called from the FBIOPUT_VSCREENINFO
    ioctl handler in fbmem.c, which will return -EINVAL if userspace asked
    for a too small screen size.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: stable@vger.kernel.org # v5.4+
    Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fbmem: Check virtual screen sizes in fb_set_var() [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Thu Aug 29 18:14:04 2024 +0200

    fbmem: Check virtual screen sizes in fb_set_var()
    
    commit 6c11df58fd1ac0aefcb3b227f72769272b939e56 upstream.
    
    Verify that the fbdev or drm driver correctly adjusted the virtual
    screen sizes. On failure report the failing driver and reject the screen
    size change.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Cc: stable@vger.kernel.org # v5.4+
    Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
filelock: Correct the filelock owner in fcntl_setlk/fcntl_setlk64 [+ + +]
Author: Long Li <leo.lilong@huawei.com>
Date:   Fri Aug 16 13:08:48 2024 +0800

    filelock: Correct the filelock owner in fcntl_setlk/fcntl_setlk64
    
    The locks_remove_posix() function in fcntl_setlk/fcntl_setlk64 is designed
    to reliably remove locks when an fcntl/close race is detected. However, it
    was passing in the wrong filelock owner, it looks like a mistake and
    resulting in a failure to remove locks. More critically, if the lock
    removal fails, it could lead to a uaf issue while traversing the locks.
    
    This problem occurs only in the 4.19/5.4 stable version.
    
    Fixes: a561145f3ae9 ("filelock: Fix fcntl/close race recovery compat path")
    Fixes: d30ff3304083 ("filelock: Remove locks reliably when fcntl/close race is detected")
    Cc: stable@vger.kernel.org
    Signed-off-by: Long Li <leo.lilong@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: 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: 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: 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>

 
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>

 
ida: Fix crash in ida_free when the bitmap is empty [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Thu Dec 21 16:53:57 2023 +0000

    ida: Fix crash in ida_free when the bitmap is empty
    
    commit af73483f4e8b6f5c68c9aa63257bdd929a9c194a upstream.
    
    The IDA usually detects double-frees, but that detection failed to
    consider the case when there are no nearby IDs allocated and so we have a
    NULL bitmap rather than simply having a clear bit.  Add some tests to the
    test-suite to be sure we don't inadvertently reintroduce this problem.
    Unfortunately they're quite noisy so include a message to disregard
    the warnings.
    
    Reported-by: Zhenghan Wang <wzhmmmmm@gmail.com>
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
ipc: remove memcg accounting for sops objects in do_semtimedop() [+ + +]
Author: Vasily Averin <vasily.averin@linux.dev>
Date:   Sat Sep 11 10:40:08 2021 +0300

    ipc: remove memcg accounting for sops objects in do_semtimedop()
    
    commit 6a4746ba06191e23d30230738e94334b26590a8a upstream.
    
    Linus proposes to revert an accounting for sops objects in
    do_semtimedop() because it's really just a temporary buffer
    for a single semtimedop() system call.
    
    This object can consume up to 2 pages, syscall is sleeping
    one, size and duration can be controlled by user, and this
    allocation can be repeated by many thread at the same time.
    
    However Shakeel Butt pointed that there are much more popular
    objects with the same life time and similar memory
    consumption, the accounting of which was decided to be
    rejected for performance reasons.
    
    Considering at least 2 pages for task_struct and 2 pages for
    the kernel stack, a back of the envelope calculation gives a
    footprint amplification of <1.5 so this temporal buffer can be
    safely ignored.
    
    The factor would IMO be interesting if it was >> 2 (from the
    PoV of excessive (ab)use, fine-grained accounting seems to be
    currently unfeasible due to performance impact).
    
    Link: https://lore.kernel.org/lkml/90e254df-0dfe-f080-011e-b7c53ee7fd20@virtuozzo.com/
    Fixes: 18319498fdd4 ("memcg: enable accounting of ipc resources")
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Reviewed-by: Michal Koutný <mkoutny@suse.com>
    Acked-by: Shakeel Butt <shakeelb@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

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

    Linux 4.19.321
    
    Link: https://lore.kernel.org/r/20240901160803.673617007@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    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: 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: uvcvideo: Fix integer overflow calculating timestamp [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Mon Jun 10 19:17:49 2024 +0000

    media: uvcvideo: Fix integer overflow calculating timestamp
    
    commit 8676a5e796fa18f55897ca36a94b2adf7f73ebd1 upstream.
    
    The function uvc_video_clock_update() supports a single SOF overflow. Or
    in other words, the maximum difference between the first ant the last
    timestamp can be 4096 ticks or 4.096 seconds.
    
    This results in a maximum value for y2 of: 0x12FBECA00, that overflows
    32bits.
    y2 = (u32)ktime_to_ns(ktime_sub(last->host_time, first->host_time)) + y1;
    
    Extend the size of y2 to u64 to support all its values.
    
    Without this patch:
     # yavta -s 1920x1080 -f YUYV -t 1/5 -c /dev/video0
    Device /dev/v4l/by-id/usb-Shine-Optics_Integrated_Camera_0001-video-index0 opened.
    Device `Integrated Camera: Integrated C' on `usb-0000:00:14.0-6' (driver 'uvcvideo') supports video, capture, without mplanes.
    Video format set: YUYV (56595559) 1920x1080 (stride 3840) field none buffer size 4147200
    Video format: YUYV (56595559) 1920x1080 (stride 3840) field none buffer size 4147200
    Current frame rate: 1/5
    Setting frame rate to: 1/5
    Frame rate set: 1/5
    8 buffers requested.
    length: 4147200 offset: 0 timestamp type/source: mono/SoE
    Buffer 0/0 mapped at address 0x7947ea94c000.
    length: 4147200 offset: 4149248 timestamp type/source: mono/SoE
    Buffer 1/0 mapped at address 0x7947ea557000.
    length: 4147200 offset: 8298496 timestamp type/source: mono/SoE
    Buffer 2/0 mapped at address 0x7947ea162000.
    length: 4147200 offset: 12447744 timestamp type/source: mono/SoE
    Buffer 3/0 mapped at address 0x7947e9d6d000.
    length: 4147200 offset: 16596992 timestamp type/source: mono/SoE
    Buffer 4/0 mapped at address 0x7947e9978000.
    length: 4147200 offset: 20746240 timestamp type/source: mono/SoE
    Buffer 5/0 mapped at address 0x7947e9583000.
    length: 4147200 offset: 24895488 timestamp type/source: mono/SoE
    Buffer 6/0 mapped at address 0x7947e918e000.
    length: 4147200 offset: 29044736 timestamp type/source: mono/SoE
    Buffer 7/0 mapped at address 0x7947e8d99000.
    0 (0) [-] none 0 4147200 B 507.554210 508.874282 242.836 fps ts mono/SoE
    1 (1) [-] none 2 4147200 B 508.886298 509.074289 0.751 fps ts mono/SoE
    2 (2) [-] none 3 4147200 B 509.076362 509.274307 5.261 fps ts mono/SoE
    3 (3) [-] none 4 4147200 B 509.276371 509.474336 5.000 fps ts mono/SoE
    4 (4) [-] none 5 4147200 B 509.476394 509.674394 4.999 fps ts mono/SoE
    5 (5) [-] none 6 4147200 B 509.676506 509.874345 4.997 fps ts mono/SoE
    6 (6) [-] none 7 4147200 B 509.876430 510.074370 5.002 fps ts mono/SoE
    7 (7) [-] none 8 4147200 B 510.076434 510.274365 5.000 fps ts mono/SoE
    8 (0) [-] none 9 4147200 B 510.276421 510.474333 5.000 fps ts mono/SoE
    9 (1) [-] none 10 4147200 B 510.476391 510.674429 5.001 fps ts mono/SoE
    10 (2) [-] none 11 4147200 B 510.676434 510.874283 4.999 fps ts mono/SoE
    11 (3) [-] none 12 4147200 B 510.886264 511.074349 4.766 fps ts mono/SoE
    12 (4) [-] none 13 4147200 B 511.070577 511.274304 5.426 fps ts mono/SoE
    13 (5) [-] none 14 4147200 B 511.286249 511.474301 4.637 fps ts mono/SoE
    14 (6) [-] none 15 4147200 B 511.470542 511.674251 5.426 fps ts mono/SoE
    15 (7) [-] none 16 4147200 B 511.672651 511.874337 4.948 fps ts mono/SoE
    16 (0) [-] none 17 4147200 B 511.873988 512.074462 4.967 fps ts mono/SoE
    17 (1) [-] none 18 4147200 B 512.075982 512.278296 4.951 fps ts mono/SoE
    18 (2) [-] none 19 4147200 B 512.282631 512.482423 4.839 fps ts mono/SoE
    19 (3) [-] none 20 4147200 B 518.986637 512.686333 0.149 fps ts mono/SoE
    20 (4) [-] none 21 4147200 B 518.342709 512.886386 -1.553 fps ts mono/SoE
    21 (5) [-] none 22 4147200 B 517.909812 513.090360 -2.310 fps ts mono/SoE
    22 (6) [-] none 23 4147200 B 517.590775 513.294454 -3.134 fps ts mono/SoE
    23 (7) [-] none 24 4147200 B 513.298465 513.494335 -0.233 fps ts mono/SoE
    24 (0) [-] none 25 4147200 B 513.510273 513.698375 4.721 fps ts mono/SoE
    25 (1) [-] none 26 4147200 B 513.698904 513.902327 5.301 fps ts mono/SoE
    26 (2) [-] none 27 4147200 B 513.895971 514.102348 5.074 fps ts mono/SoE
    27 (3) [-] none 28 4147200 B 514.099091 514.306337 4.923 fps ts mono/SoE
    28 (4) [-] none 29 4147200 B 514.310348 514.510567 4.734 fps ts mono/SoE
    29 (5) [-] none 30 4147200 B 514.509295 514.710367 5.026 fps ts mono/SoE
    30 (6) [-] none 31 4147200 B 521.532513 514.914398 0.142 fps ts mono/SoE
    31 (7) [-] none 32 4147200 B 520.885277 515.118385 -1.545 fps ts mono/SoE
    32 (0) [-] none 33 4147200 B 520.411140 515.318336 -2.109 fps ts mono/SoE
    33 (1) [-] none 34 4147200 B 515.325425 515.522278 -0.197 fps ts mono/SoE
    34 (2) [-] none 35 4147200 B 515.538276 515.726423 4.698 fps ts mono/SoE
    35 (3) [-] none 36 4147200 B 515.720767 515.930373 5.480 fps ts mono/SoE
    
    Cc: stable@vger.kernel.org
    Fixes: 66847ef013cc ("[media] uvcvideo: Add UVC timestamps support")
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Link: https://lore.kernel.org/r/20240610-hwtimestamp-followup-v1-2-f9eaed7be7f0@chromium.org
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
memcg: enable accounting of ipc resources [+ + +]
Author: Vasily Averin <vasily.averin@linux.dev>
Date:   Thu Sep 2 14:55:31 2021 -0700

    memcg: enable accounting of ipc resources
    
    commit 18319498fdd4cdf8c1c2c48cd432863b1f915d6f upstream.
    
    When user creates IPC objects it forces kernel to allocate memory for
    these long-living objects.
    
    It makes sense to account them to restrict the host's memory consumption
    from inside the memcg-limited container.
    
    This patch enables accounting for IPC shared memory segments, messages
    semaphores and semaphore's undo lists.
    
    Link: https://lkml.kernel.org/r/d6507b06-4df6-78f8-6c54-3ae86e3b5339@virtuozzo.com
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Reviewed-by: Shakeel Butt <shakeelb@google.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Andrei Vagin <avagin@gmail.com>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Dmitry Safonov <0x7f454c46@gmail.com>
    Cc: "Eric W. Biederman" <ebiederm@xmission.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "J. Bruce Fields" <bfields@fieldses.org>
    Cc: Jeff Layton <jlayton@kernel.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Jiri Slaby <jirislaby@kernel.org>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Kirill Tkhai <ktkhai@virtuozzo.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Serge Hallyn <serge@hallyn.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Yutian Yang <nglaive@gmail.com>
    Cc: Zefan Li <lizefan.x@bytedance.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com>
    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>

 
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>

 
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: 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: 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: prevent mss overflow in skb_segment() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Dec 12 16:46:21 2023 +0000

    net: prevent mss overflow in skb_segment()
    
    commit 23d05d563b7e7b0314e65c8e882bc27eac2da8e7 upstream.
    
    Once again syzbot is able to crash the kernel in skb_segment() [1]
    
    GSO_BY_FRAGS is a forbidden value, but unfortunately the following
    computation in skb_segment() can reach it quite easily :
    
            mss = mss * partial_segs;
    
    65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
    a bad final result.
    
    Make sure to limit segmentation so that the new mss value is smaller
    than GSO_BY_FRAGS.
    
    [1]
    
    general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
    CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
    RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
    Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
    RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
    RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
    RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
    R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
    R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
    FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109
    ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120
    skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
    __skb_gso_segment+0x339/0x710 net/core/gso.c:124
    skb_gso_segment include/net/gso.h:83 [inline]
    validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626
    __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338
    dev_queue_xmit include/linux/netdevice.h:3134 [inline]
    packet_xmit+0x257/0x380 net/packet/af_packet.c:276
    packet_snd net/packet/af_packet.c:3087 [inline]
    packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119
    sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg+0xd5/0x180 net/socket.c:745
    __sys_sendto+0x255/0x340 net/socket.c:2190
    __do_sys_sendto net/socket.c:2202 [inline]
    __se_sys_sendto net/socket.c:2198 [inline]
    __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
    do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b
    RIP: 0033:0x7f8692032aa9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9
    RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003
    RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480
    R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003
    </TASK>
    Modules linked in:
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
    Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00
    RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
    RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
    RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
    R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
    R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
    FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Fixes: 3953c46c3ac7 ("sk_buff: allow segmenting based on frag sizes")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20231212164621.4131800-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Hugo SIMELIERE <hsimeliere.opensource@witekio.com>
    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>

 
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>

 
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>

 
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>

 
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>

 
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>

 
overflow.h: Add flex_array_size() helper [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Mon Jun 8 20:22:33 2020 -0500

    overflow.h: Add flex_array_size() helper
    
    commit b19d57d0f3cc6f1022edf94daf1d70506a09e3c2 upstream.
    
    Add flex_array_size() helper for the calculation of the size, in bytes,
    of a flexible array member contained within an enclosing structure.
    
    Example of usage:
    
    struct something {
            size_t count;
            struct foo items[];
    };
    
    struct something *instance;
    
    instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL);
    instance->count = count;
    memcpy(instance->items, src, flex_array_size(instance, items, instance->count));
    
    The helper returns SIZE_MAX on overflow instead of wrapping around.
    
    Additionally replaces parameter "n" with "count" in struct_size() helper
    for greater clarity and unification.
    
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Link: https://lore.kernel.org/r/20200609012233.GA3371@embeddedor
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
overflow: Implement size_t saturating arithmetic helpers [+ + +]
Author: Kees Cook <kees@kernel.org>
Date:   Sat Sep 18 15:17:53 2021 -0700

    overflow: Implement size_t saturating arithmetic helpers
    
    commit e1be43d9b5d0d1310dbd90185a8e5c7145dde40f upstream.
    
    In order to perform more open-coded replacements of common allocation
    size arithmetic, the kernel needs saturating (SIZE_MAX) helpers for
    multiplication, addition, and subtraction. For example, it is common in
    allocators, especially on realloc, to add to an existing size:
    
        p = krealloc(map->patch,
                     sizeof(struct reg_sequence) * (map->patch_regs + num_regs),
                     GFP_KERNEL);
    
    There is no existing saturating replacement for this calculation, and
    just leaving the addition open coded inside array_size() could
    potentially overflow as well. For example, an overflow in an expression
    for a size_t argument might wrap to zero:
    
        array_size(anything, something_at_size_max + 1) == 0
    
    Introduce size_mul(), size_add(), and size_sub() helpers that
    implicitly promote arguments to size_t and saturated calculations for
    use in allocations. With these helpers it is also possible to redefine
    array_size(), array3_size(), flex_array_size(), and struct_size() in
    terms of the new helpers.
    
    As with the check_*_overflow() helpers, the new helpers use __must_check,
    though what is really desired is a way to make sure that assignment is
    only to a size_t lvalue. Without this, it's still possible to introduce
    overflow/underflow via type conversion (i.e. from size_t to int).
    Enforcing this will currently need to be left to static analysis or
    future use of -Wconversion.
    
    Additionally update the overflow unit tests to force runtime evaluation
    for the pathological cases.
    
    Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Jason Gunthorpe <jgg@ziepe.ca>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Leon Romanovsky <leon@kernel.org>
    Cc: Keith Busch <kbusch@kernel.org>
    Cc: Len Baker <len.baker@gmx.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
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>

 
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>

 
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/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>

 
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: 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: mpt3sas: Avoid IOMMU page faults on REPORT ZONES [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Fri Jul 19 16:39:12 2024 +0900

    scsi: mpt3sas: Avoid IOMMU page faults on REPORT ZONES
    
    commit 82dbb57ac8d06dfe8227ba9ab11a49de2b475ae5 upstream.
    
    Some firmware versions of the 9600 series SAS HBA byte-swap the REPORT
    ZONES command reply buffer from ATA-ZAC devices by directly accessing the
    buffer in the host memory. This does not respect the default command DMA
    direction and causes IOMMU page faults on architectures with an IOMMU
    enforcing write-only mappings for DMA_FROM_DEVICE DMA driection (e.g. AMD
    hosts).
    
    scsi 18:0:0:0: Direct-Access-ZBC ATA      WDC  WSH722020AL W870 PQ: 0 ANSI: 6
    scsi 18:0:0:0: SATA: handle(0x0027), sas_addr(0x300062b2083e7c40), phy(0), device_name(0x5000cca29dc35e11)
    scsi 18:0:0:0: enclosure logical id (0x300062b208097c40), slot(0)
    scsi 18:0:0:0: enclosure level(0x0000), connector name( C0.0)
    scsi 18:0:0:0: atapi(n), ncq(y), asyn_notify(n), smart(y), fua(y), sw_preserve(y)
    scsi 18:0:0:0: qdepth(32), tagged(1), scsi_level(7), cmd_que(1)
    sd 18:0:0:0: Attached scsi generic sg2 type 20
    sd 18:0:0:0: [sdc] Host-managed zoned block device
    mpt3sas 0000:41:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0xfff9b200 flags=0x0050]
    mpt3sas 0000:41:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0021 address=0xfff9b300 flags=0x0050]
    mpt3sas_cm0: mpt3sas_ctl_pre_reset_handler: Releasing the trace buffer due to adapter reset.
    mpt3sas_cm0 fault info from func: mpt3sas_base_make_ioc_ready
    mpt3sas_cm0: fault_state(0x2666)!
    mpt3sas_cm0: sending diag reset !!
    mpt3sas_cm0: diag reset: SUCCESS
    sd 18:0:0:0: [sdc] REPORT ZONES start lba 0 failed
    sd 18:0:0:0: [sdc] REPORT ZONES: Result: hostbyte=DID_RESET driverbyte=DRIVER_OK
    sd 18:0:0:0: [sdc] 0 4096-byte logical blocks: (0 B/0 B)
    
    Avoid such issue by always mapping the buffer of REPORT ZONES commands
    using DMA_BIDIRECTIONAL (read+write IOMMU mapping). This is done by
    introducing the helper function _base_scsi_dma_map() and using this helper
    in _base_build_sg_scmd() and _base_build_sg_scmd_ieee() instead of calling
    directly scsi_dma_map().
    
    Fixes: 471ef9d4e498 ("mpt3sas: Build MPI SGL LIST on GEN2 HBAs and IEEE SGL LIST on GEN3 HBAs")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Link: https://lore.kernel.org/r/20240719073913.179559-3-dlemoal@kernel.org
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
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: 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>

 
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: 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: 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>

 
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: 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>

 
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>