Changelog in Linux kernel 5.15.173

 
9p: Avoid creating multiple slab caches with the same name [+ + +]
Author: Pedro Falcato <pedro.falcato@gmail.com>
Date:   Wed Aug 7 10:47:25 2024 +0100

    9p: Avoid creating multiple slab caches with the same name
    
    [ Upstream commit 79efebae4afc2221fa814c3cae001bede66ab259 ]
    
    In the spirit of [1], avoid creating multiple slab caches with the same
    name. Instead, add the dev_name into the mix.
    
    [1]: https://lore.kernel.org/all/20240807090746.2146479-1-pedro.falcato@gmail.com/
    
    Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
    Reported-by: syzbot+3c5d43e97993e1fa612b@syzkaller.appspotmail.com
    Message-ID: <20240807094725.2193423-1-pedro.falcato@gmail.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
9p: fix slab cache name creation for real [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Oct 21 11:57:38 2024 -0700

    9p: fix slab cache name creation for real
    
    commit a360f311f57a36e96d88fa8086b749159714dcd2 upstream.
    
    This was attempted by using the dev_name in the slab cache name, but as
    Omar Sandoval pointed out, that can be an arbitrary string, eg something
    like "/dev/root".  Which in turn trips verify_dirent_name(), which fails
    if a filename contains a slash.
    
    So just make it use a sequence counter, and make it an atomic_t to avoid
    any possible races or locking issues.
    
    Reported-and-tested-by: Omar Sandoval <osandov@fb.com>
    Link: https://lore.kernel.org/all/ZxafcO8KWMlXaeWE@telecaster.dhcp.thefacebook.com/
    Fixes: 79efebae4afc ("9p: Avoid creating multiple slab caches with the same name")
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Cc: Dominique Martinet <asmadeus@codewreck.org>
    Cc: Thorsten Leemhuis <regressions@leemhuis.info>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
block: Fix elevator_get_default() checking for NULL q->tag_set [+ + +]
Author: SurajSonawane2415 <surajsonawane0215@gmail.com>
Date:   Mon Oct 7 16:44:16 2024 +0530

    block: Fix elevator_get_default() checking for NULL q->tag_set
    
    [ Upstream commit b402328a24ee7193a8ab84277c0c90ae16768126 ]
    
    elevator_get_default() and elv_support_iosched() both check for whether
    or not q->tag_set is non-NULL, however it's not possible for them to be
    NULL. This messes up some static checkers, as the checking of tag_set
    isn't consistent.
    
    Remove the checks, which both simplifies the logic and avoids checker
    errors.
    
    Signed-off-by: SurajSonawane2415 <surajsonawane0215@gmail.com>
    Link: https://lore.kernel.org/r/20241007111416.13814-1-surajsonawane0215@gmail.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: use kvzmalloc to allocate BPF verifier environment [+ + +]
Author: Rik van Riel <riel@surriel.com>
Date:   Tue Oct 8 17:07:35 2024 -0400

    bpf: use kvzmalloc to allocate BPF verifier environment
    
    [ Upstream commit 434247637c66e1be2bc71a9987d4c3f0d8672387 ]
    
    The kzmalloc call in bpf_check can fail when memory is very fragmented,
    which in turn can lead to an OOM kill.
    
    Use kvzmalloc to fall back to vmalloc when memory is too fragmented to
    allocate an order 3 sized bpf verifier environment.
    
    Admittedly this is not a very common case, and only happens on systems
    where memory has already been squeezed close to the limit, but this does
    not seem like much of a hot path, and it's a simple enough fix.
    
    Signed-off-by: Rik van Riel <riel@surriel.com>
    Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
    Link: https://lore.kernel.org/r/20241008170735.16766766@imladris.surriel.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: marvell/cesa - Disable hash algorithms [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Wed Oct 9 16:38:48 2024 +0800

    crypto: marvell/cesa - Disable hash algorithms
    
    [ Upstream commit e845d2399a00f866f287e0cefbd4fc7d8ef0d2f7 ]
    
    Disable cesa hash algorithms by lowering the priority because they
    appear to be broken when invoked in parallel.  This allows them to
    still be tested for debugging purposes.
    
    Reported-by: Klaus Kudielka <klaus.kudielka@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/vmwgfx: Limit display layout ioctl array size to VMWGFX_NUM_DISPLAY_UNITS [+ + +]
Author: Ian Forbes <ian.forbes@broadcom.com>
Date:   Thu Aug 8 15:06:34 2024 -0500

    drm/vmwgfx: Limit display layout ioctl array size to VMWGFX_NUM_DISPLAY_UNITS
    
    [ Upstream commit 28a5dfd4f615539fb22fb6d5c219c199c14e6eb6 ]
    
    Currently the array size is only limited by the largest kmalloc size which
    is incorrect. This change will also return a more specific error message
    than ENOMEM to userspace.
    
    Signed-off-by: Ian Forbes <ian.forbes@broadcom.com>
    Reviewed-by: Zack Rusin <zack.rusin@broadcom.com>
    Reviewed-by: Martin Krastev <martin.krastev@broadcom.com>
    Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240808200634.1074083-1-ian.forbes@broadcom.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs: Fix uninitialized value issue in from_kuid and from_kgid [+ + +]
Author: Alessandro Zanni <alessandro.zanni87@gmail.com>
Date:   Thu Oct 17 14:05:51 2024 +0200

    fs: Fix uninitialized value issue in from_kuid and from_kgid
    
    [ Upstream commit 15f34347481648a567db67fb473c23befb796af5 ]
    
    ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in
    a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set.
    
    Initialize all fields of newattrs to avoid uninitialized variables, by
    checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.
    
    Reported-by: syzbot+6c55f725d1bdc8c52058@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=6c55f725d1bdc8c52058
    Signed-off-by: Alessandro Zanni <alessandro.zanni87@gmail.com>
    Link: https://lore.kernel.org/r/20241017120553.55331-1-alessandro.zanni87@gmail.com
    Reviewed-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu Oct 10 11:45:12 2024 +0200

    HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard
    
    [ Upstream commit 51268879eb2bfc563a91cdce69362d9dbf707e7e ]
    
    The Thinkpad X1 Tablet Gen 3 keyboard has the same Lenovo specific quirks
    as the original  Thinkpad X1 Tablet keyboard.
    
    Add the PID for the "Thinkpad X1 Tablet Gen 3 keyboard" to the hid-lenovo
    driver to fix the FnLock, Mute and media buttons not working.
    
    Suggested-by: Izhar Firdaus <izhar@fedoraproject.org>
    Closes https://bugzilla.redhat.com/show_bug.cgi?id=2315395
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad [+ + +]
Author: WangYuli <wangyuli@uniontech.com>
Date:   Mon Oct 7 12:08:03 2024 +0800

    HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad
    
    [ Upstream commit 7a5ab8071114344f62a8b1e64ed3452a77257d76 ]
    
    The behavior of HONOR MagicBook Art 14 touchpad is not consistent
    after reboots, as sometimes it reports itself as a touchpad, and
    sometimes as a mouse.
    
    Similarly to GLO-GXXX it is possible to call MT_QUIRK_FORCE_GET_FEATURE as a
    workaround to force set feature in mt_set_input_mode() for such special touchpad
    device.
    
    [jkosina@suse.com: reword changelog a little bit]
    Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/1040
    Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
    Signed-off-by: WangYuli <wangyuli@uniontech.com>
    Reviewed-by: Benjamin Tissoires <bentiss@kernel.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad [+ + +]
Author: Kenneth Albanowski <kenalba@chromium.org>
Date:   Fri Oct 4 10:24:29 2024 -0700

    HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad
    
    [ Upstream commit 526748b925185e95f1415900ee13c2469d4b64cc ]
    
    The Logitech Casa Touchpad does not reliably send touch release signals
    when communicating through the Logitech Bolt wireless-to-USB receiver.
    
    Adjusting the device class to add MT_QUIRK_NOT_SEEN_MEANS_UP to make
    sure that no touches become stuck, MT_QUIRK_FORCE_MULTI_INPUT is not
    needed, but harmless.
    
    Linux does not have information on which devices are connected to the
    Bolt receiver, so we have to enable this for the entire device.
    
    Signed-off-by: Kenneth Albanowski <kenalba@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: multitouch: Add support for B2402FVA track point [+ + +]
Author: Stefan Blum <stefanblum2004@gmail.com>
Date:   Sun Oct 6 10:12:23 2024 +0200

    HID: multitouch: Add support for B2402FVA track point
    
    [ Upstream commit 1a5cbb526ec4b885177d06a8bc04f38da7dbb1d9 ]
    
    By default the track point does not work on the Asus Expertbook B2402FVA.
    
    From libinput record i got the ID of the track point device:
      evdev:
        # Name: ASUE1201:00 04F3:32AE
        # ID: bus 0x18 vendor 0x4f3 product 0x32ae version 0x100
    
    I found that the track point is functional, when i set the
    MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU class for the reported device.
    
    Signed-off-by: Stefan Blum <stefan.blum@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring: fix possible deadlock in io_register_iowq_max_workers() [+ + +]
Author: Hagar Hemdan <hagarhem@amazon.com>
Date:   Tue Jun 4 13:05:27 2024 +0000

    io_uring: fix possible deadlock in io_register_iowq_max_workers()
    
    commit 73254a297c2dd094abec7c9efee32455ae875bdf upstream.
    
    The io_register_iowq_max_workers() function calls io_put_sq_data(),
    which acquires the sqd->lock without releasing the uring_lock.
    Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock
    before acquiring sqd->lock"), this can lead to a potential deadlock
    situation.
    
    To resolve this issue, the uring_lock is released before calling
    io_put_sq_data(), and then it is re-acquired after the function call.
    
    This change ensures that the locks are acquired in the correct
    order, preventing the possibility of a deadlock.
    
    Suggested-by: Maximilian Heyne <mheyne@amazon.de>
    Signed-off-by: Hagar Hemdan <hagarhem@amazon.com>
    Link: https://lore.kernel.org/r/20240604130527.3597-1-hagarhem@amazon.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
irqchip/ocelot: Fix trigger register address [+ + +]
Author: Sergey Matsievskiy <matsievskiysv@gmail.com>
Date:   Wed Sep 25 21:44:15 2024 +0300

    irqchip/ocelot: Fix trigger register address
    
    [ Upstream commit 9e9c4666abb5bb444dac37e2d7eb5250c8d52a45 ]
    
    Controllers, supported by this driver, have two sets of registers:
    
     * (main) interrupt registers control peripheral interrupt sources.
    
     * device interrupt registers configure per-device (network interface)
       interrupts and act as an extra stage before the main interrupt
       registers.
    
    In the driver unmask code, device trigger registers are used in the mask
    calculation of the main interrupt sticky register, mixing two kinds of
    registers.
    
    Use the main interrupt trigger register instead.
    
    Signed-off-by: Sergey Matsievskiy <matsievskiysv@gmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/all/20240925184416.54204-2-matsievskiysv@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.15.173 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Nov 17 15:06:26 2024 +0100

    Linux 5.15.173
    
    Link: https://lore.kernel.org/r/20241115063722.599985562@linuxfoundation.org
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: SeongJae Park <sj@kernel.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Hardik Garg <hargar@linux.microsoft.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
md/raid10: improve code of mrdev in raid10_sync_request [+ + +]
Author: Li Nan <linan122@huawei.com>
Date:   Sat May 27 15:22:16 2023 +0800

    md/raid10: improve code of mrdev in raid10_sync_request
    
    commit 59f8f0b54c8ffb4521f6bbd1cb6f4dfa5022e75e upstream.
    
    'need_recover' and 'mrdev' are equivalent in raid10_sync_request(), and
    inc mrdev->nr_pending is unreasonable if don't need recovery. Replace
    'need_recover' with 'mrdev', and only inc nr_pending when needed.
    
    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/20230527072218.2365857-3-linan666@huaweicloud.com
    Cc: Hagar Gamal Halim <hagarhem@amazon.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/memory: add non-anonymous page check in the copy_present_page() [+ + +]
Author: Yuanzheng Song <songyuanzheng@huawei.com>
Date:   Wed Nov 13 17:31:19 2024 +0100

    mm/memory: add non-anonymous page check in the copy_present_page()
    
    The vma->anon_vma of the child process may be NULL because
    the entire vma does not contain anonymous pages. In this
    case, a BUG will occur when the copy_present_page() passes
    a copy of a non-anonymous page of that vma to the
    page_add_new_anon_rmap() to set up new anonymous rmap.
    
    ------------[ cut here ]------------
    kernel BUG at mm/rmap.c:1052!
    Internal error: Oops - BUG: 0 [#1] SMP
    Modules linked in:
    CPU: 4 PID: 4652 Comm: test Not tainted 5.15.75 #1
    Hardware name: linux,dummy-virt (DT)
    pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : __page_set_anon_rmap+0xc0/0xe8
    lr : __page_set_anon_rmap+0xc0/0xe8
    sp : ffff80000e773860
    x29: ffff80000e773860 x28: fffffc13cf006ec0 x27: ffff04f3ccd68000
    x26: ffff04f3c5c33248 x25: 0000000010100073 x24: ffff04f3c53c0a80
    x23: 0000000020000000 x22: 0000000000000001 x21: 0000000020000000
    x20: fffffc13cf006ec0 x19: 0000000000000000 x18: 0000000000000000
    x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
    x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
    x11: 0000000000000000 x10: 0000000000000000 x9 : ffffdddc5581377c
    x8 : 0000000000000000 x7 : 0000000000000011 x6 : ffff2717a8433000
    x5 : ffff80000e773810 x4 : ffffdddc55400000 x3 : 0000000000000000
    x2 : ffffdddc56b20000 x1 : ffff04f3c9a48040 x0 : 0000000000000000
    Call trace:
     __page_set_anon_rmap+0xc0/0xe8
     page_add_new_anon_rmap+0x13c/0x200
     copy_pte_range+0x6b8/0x1018
     copy_page_range+0x3a8/0x5e0
     dup_mmap+0x3a0/0x6e8
     dup_mm+0x78/0x140
     copy_process+0x1528/0x1b08
     kernel_clone+0xac/0x610
     __do_sys_clone+0x78/0xb0
     __arm64_sys_clone+0x30/0x40
     invoke_syscall+0x68/0x170
     el0_svc_common.constprop.0+0x80/0x250
     do_el0_svc+0x48/0xb8
     el0_svc+0x48/0x1a8
     el0t_64_sync_handler+0xb0/0xb8
     el0t_64_sync+0x1a0/0x1a4
    Code: 97f899f4 f9400273 17ffffeb 97f899f1 (d4210000)
    ---[ end trace dc65e5edd0f362fa ]---
    Kernel panic - not syncing: Oops - BUG: Fatal exception
    SMP: stopping secondary CPUs
    Kernel Offset: 0x5ddc4d400000 from 0xffff800008000000
    PHYS_OFFSET: 0xfffffb0c80000000
    CPU features: 0x44000cf1,00000806
    Memory Limit: none
    ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]---
    
    This problem has been fixed by the commit <fb3d824d1a46>
    ("mm/rmap: split page_dup_rmap() into page_dup_file_rmap()
    and page_try_dup_anon_rmap()"), but still exists in the
    linux-5.15.y branch.
    
    This patch is not applicable to this version because
    of the large version differences. Therefore, fix it by
    adding non-anonymous page check in the copy_present_page().
    
    Cc: stable@vger.kernel.org
    Fixes: 70e806e4e645 ("mm: Do early cow for pinned pages during fork() for ptes")
    Signed-off-by: Yuanzheng Song <songyuanzheng@huawei.com>
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: krealloc: Fix MTE false alarm in __do_krealloc [+ + +]
Author: Qun-Wei Lin <qun-wei.lin@mediatek.com>
Date:   Fri Oct 25 16:58:11 2024 +0800

    mm: krealloc: Fix MTE false alarm in __do_krealloc
    
    commit 704573851b51808b45dae2d62059d1d8189138a2 upstream.
    
    This patch addresses an issue introduced by commit 1a83a716ec233 ("mm:
    krealloc: consider spare memory for __GFP_ZERO") which causes MTE
    (Memory Tagging Extension) to falsely report a slab-out-of-bounds error.
    
    The problem occurs when zeroing out spare memory in __do_krealloc. The
    original code only considered software-based KASAN and did not account
    for MTE. It does not reset the KASAN tag before calling memset, leading
    to a mismatch between the pointer tag and the memory tag, resulting
    in a false positive.
    
    Example of the error:
    ==================================================================
    swapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188
    swapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1
    swapper/0: Pointer tag: [f4], memory tag: [fe]
    swapper/0:
    swapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.
    swapper/0: Hardware name: MT6991(ENG) (DT)
    swapper/0: Call trace:
    swapper/0:  dump_backtrace+0xfc/0x17c
    swapper/0:  show_stack+0x18/0x28
    swapper/0:  dump_stack_lvl+0x40/0xa0
    swapper/0:  print_report+0x1b8/0x71c
    swapper/0:  kasan_report+0xec/0x14c
    swapper/0:  __do_kernel_fault+0x60/0x29c
    swapper/0:  do_bad_area+0x30/0xdc
    swapper/0:  do_tag_check_fault+0x20/0x34
    swapper/0:  do_mem_abort+0x58/0x104
    swapper/0:  el1_abort+0x3c/0x5c
    swapper/0:  el1h_64_sync_handler+0x80/0xcc
    swapper/0:  el1h_64_sync+0x68/0x6c
    swapper/0:  __memset+0x84/0x188
    swapper/0:  btf_populate_kfunc_set+0x280/0x3d8
    swapper/0:  __register_btf_kfunc_id_set+0x43c/0x468
    swapper/0:  register_btf_kfunc_id_set+0x48/0x60
    swapper/0:  register_nf_nat_bpf+0x1c/0x40
    swapper/0:  nf_nat_init+0xc0/0x128
    swapper/0:  do_one_initcall+0x184/0x464
    swapper/0:  do_initcall_level+0xdc/0x1b0
    swapper/0:  do_initcalls+0x70/0xc0
    swapper/0:  do_basic_setup+0x1c/0x28
    swapper/0:  kernel_init_freeable+0x144/0x1b8
    swapper/0:  kernel_init+0x20/0x1a8
    swapper/0:  ret_from_fork+0x10/0x20
    ==================================================================
    
    Fixes: 1a83a716ec233 ("mm: krealloc: consider spare memory for __GFP_ZERO")
    Signed-off-by: Qun-Wei Lin <qun-wei.lin@mediatek.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition [+ + +]
Author: Reinhard Speyerer <rspmn@arcor.de>
Date:   Fri Oct 18 22:52:55 2024 +0200

    net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition
    
    [ Upstream commit 64761c980cbf71fb7a532a8c7299907ea972a88c ]
    
    Add Fibocom FG132 0x0112 composition:
    
    T:  Bus=03 Lev=02 Prnt=06 Port=01 Cnt=02 Dev#= 10 Spd=12   MxCh= 0
    D:  Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=2cb7 ProdID=0112 Rev= 5.15
    S:  Manufacturer=Fibocom Wireless Inc.
    S:  Product=Fibocom Module
    S:  SerialNumber=xxxxxxxx
    C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS=  64 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=  64 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=86(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    
    Signed-off-by: Reinhard Speyerer <rspmn@arcor.de>
    
    Link: https://patch.msgid.link/ZxLKp5YZDy-OM0-e@arcor.de
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/powernv: Free name on error in opal_event_init() [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri Sep 20 19:35:20 2024 +1000

    powerpc/powernv: Free name on error in opal_event_init()
    
    [ Upstream commit cf8989d20d64ad702a6210c11a0347ebf3852aa7 ]
    
    In opal_event_init() if request_irq() fails name is not freed, leading
    to a memory leak. The code only runs at boot time, there's no way for a
    user to trigger it, so there's no security impact.
    
    Fix the leak by freeing name in the error path.
    
    Reported-by: 2639161967 <2639161967@qq.com>
    Closes: https://lore.kernel.org/linuxppc-dev/87wmjp3wig.fsf@mail.lhotse
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://patch.msgid.link/20240920093520.67997-1-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML [+ + +]
Author: Julian Vetter <jvetter@kalrayinc.com>
Date:   Thu Oct 10 14:46:01 2024 +0200

    sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML
    
    [ Upstream commit ad6639f143a0b42d7fb110ad14f5949f7c218890 ]
    
    When building for the UM arch and neither INDIRECT_IOMEM=y, nor
    HAS_IOMEM=y is selected, it will fall back to the implementations from
    asm-generic/io.h for IO memcpy. But these fall-back functions just do a
    memcpy. So, instead of depending on UML, add dependency on 'HAS_IOMEM ||
    INDIRECT_IOMEM'.
    
    Reviewed-by: Yann Sionneau <ysionneau@kalrayinc.com>
    Signed-off-by: Julian Vetter <jvetter@kalrayinc.com>
    Link: https://patch.msgid.link/20241010124601.700528-1-jvetter@kalrayinc.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udf: Allocate name buffer in directory iterator on heap [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Dec 20 12:38:45 2022 +0100

    udf: Allocate name buffer in directory iterator on heap
    
    commit 0aba4860b0d0216a1a300484ff536171894d49d8 upstream.
    
    Currently we allocate name buffer in directory iterators (struct
    udf_fileident_iter) on stack. These structures are relatively large
    (some 360 bytes on 64-bit architectures). For udf_rename() which needs
    to keep three of these structures in parallel the stack usage becomes
    rather heavy - 1536 bytes in total. Allocate the name buffer in the
    iterator from heap to avoid excessive stack usage.
    
    Link: https://lore.kernel.org/all/202212200558.lK9x1KW0-lkp@intel.com
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    [Add extra include linux/slab.h]
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

udf: Avoid directory type conversion failure due to ENOMEM [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Thu Feb 9 10:33:09 2023 +0100

    udf: Avoid directory type conversion failure due to ENOMEM
    
    commit df97f64dfa317a5485daf247b6c043a584ef95f9 upstream.
    
    When converting directory from in-ICB to normal format, the last
    iteration through the directory fixing up directory enteries can fail
    due to ENOMEM. We do not expect this iteration to fail since the
    directory is already verified to be correct and it is difficult to undo
    the conversion at this point. So just use GFP_NOFAIL to make sure the
    small allocation cannot fail.
    
    Reported-by: syzbot+111eaa994ff74f8d440f@syzkaller.appspotmail.com
    Fixes: 0aba4860b0d0 ("udf: Allocate name buffer in directory iterator on heap")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vDPA/ifcvf: Fix pci_read_config_byte() return code handling [+ + +]
Author: Yuan Can <yuancan@huawei.com>
Date:   Thu Oct 17 09:38:12 2024 +0800

    vDPA/ifcvf: Fix pci_read_config_byte() return code handling
    
    [ Upstream commit 7f8825b2a78ac392d3fbb3a2e65e56d9e39d75e9 ]
    
    ifcvf_init_hw() uses pci_read_config_byte() that returns
    PCIBIOS_* codes. The error handling, however, assumes the codes are
    normal errnos because it checks for < 0.
    Convert the error check to plain non-zero check.
    
    Fixes: 5a2414bc454e ("virtio: Intel IFC VF driver for VDPA")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Message-Id: <20241017013812.129952-1-yuancan@huawei.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Acked-by: Zhu Lingshan <lingshan.zhu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>