commit 2d21f73b2f16f51608c8d8b1726df270229a5006
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Dec 20 15:41:26 2023 +0100

    Linux 5.4.265
    
    Link: https://lore.kernel.org/r/20231218135042.748715259@linuxfoundation.org
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c70542f32af39ac3bac34322b818e6bab69d3e6
Author: Naveen N Rao <naveen@kernel.org>
Date:   Fri Dec 15 16:44:33 2023 +0530

    powerpc/ftrace: Fix stack teardown in ftrace_no_trace
    
    commit 4b3338aaa74d7d4ec5b6734dc298f0db94ec83d2 upstream.
    
    Commit 41a506ef71eb ("powerpc/ftrace: Create a dummy stackframe to fix
    stack unwind") added use of a new stack frame on ftrace entry to fix
    stack unwind. However, the commit missed updating the offset used while
    tearing down the ftrace stack when ftrace is disabled. Fix the same.
    
    In addition, the commit missed saving the correct stack pointer in
    pt_regs. Update the same.
    
    Fixes: 41a506ef71eb ("powerpc/ftrace: Create a dummy stackframe to fix stack unwind")
    Cc: stable@vger.kernel.org # v6.5+
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20231130065947.2188860-1-naveen@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e1867b482b4422941be632e31eaf33dad98e825
Author: Naveen N Rao <naveen@kernel.org>
Date:   Fri Dec 15 16:44:32 2023 +0530

    powerpc/ftrace: Create a dummy stackframe to fix stack unwind
    
    commit 41a506ef71eb38d94fe133f565c87c3e06ccc072 upstream.
    
    With ppc64 -mprofile-kernel and ppc32 -pg, profiling instructions to
    call into ftrace are emitted right at function entry. The instruction
    sequence used is minimal to reduce overhead. Crucially, a stackframe is
    not created for the function being traced. This breaks stack unwinding
    since the function being traced does not have a stackframe for itself.
    As such, it never shows up in the backtrace:
    
    /sys/kernel/debug/tracing # echo 1 > /proc/sys/kernel/stack_tracer_enabled
    /sys/kernel/debug/tracing # cat stack_trace
            Depth    Size   Location    (17 entries)
            -----    ----   --------
      0)     4144      32   ftrace_call+0x4/0x44
      1)     4112     432   get_page_from_freelist+0x26c/0x1ad0
      2)     3680     496   __alloc_pages+0x290/0x1280
      3)     3184     336   __folio_alloc+0x34/0x90
      4)     2848     176   vma_alloc_folio+0xd8/0x540
      5)     2672     272   __handle_mm_fault+0x700/0x1cc0
      6)     2400     208   handle_mm_fault+0xf0/0x3f0
      7)     2192      80   ___do_page_fault+0x3e4/0xbe0
      8)     2112     160   do_page_fault+0x30/0xc0
      9)     1952     256   data_access_common_virt+0x210/0x220
     10)     1696     400   0xc00000000f16b100
     11)     1296     384   load_elf_binary+0x804/0x1b80
     12)      912     208   bprm_execve+0x2d8/0x7e0
     13)      704      64   do_execveat_common+0x1d0/0x2f0
     14)      640     160   sys_execve+0x54/0x70
     15)      480      64   system_call_exception+0x138/0x350
     16)      416     416   system_call_common+0x160/0x2c4
    
    Fix this by having ftrace create a dummy stackframe for the function
    being traced. With this, backtraces now capture the function being
    traced:
    
    /sys/kernel/debug/tracing # cat stack_trace
            Depth    Size   Location    (17 entries)
            -----    ----   --------
      0)     3888      32   _raw_spin_trylock+0x8/0x70
      1)     3856     576   get_page_from_freelist+0x26c/0x1ad0
      2)     3280      64   __alloc_pages+0x290/0x1280
      3)     3216     336   __folio_alloc+0x34/0x90
      4)     2880     176   vma_alloc_folio+0xd8/0x540
      5)     2704     416   __handle_mm_fault+0x700/0x1cc0
      6)     2288      96   handle_mm_fault+0xf0/0x3f0
      7)     2192      48   ___do_page_fault+0x3e4/0xbe0
      8)     2144     192   do_page_fault+0x30/0xc0
      9)     1952     608   data_access_common_virt+0x210/0x220
     10)     1344      16   0xc0000000334bbb50
     11)     1328     416   load_elf_binary+0x804/0x1b80
     12)      912      64   bprm_execve+0x2d8/0x7e0
     13)      848     176   do_execveat_common+0x1d0/0x2f0
     14)      672     192   sys_execve+0x54/0x70
     15)      480      64   system_call_exception+0x138/0x350
     16)      416     416   system_call_common+0x160/0x2c4
    
    This results in two additional stores in the ftrace entry code, but
    produces reliable backtraces.
    
    Fixes: 153086644fd1 ("powerpc/ftrace: Add support for -mprofile-kernel ftrace ABI")
    Cc: stable@vger.kernel.org
    Signed-off-by: Naveen N Rao <naveen@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20230621051349.759567-1-naveen@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9395c04666cca2815d8a63494e16869bfbe247fb
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Fri Nov 3 10:47:17 2023 +0200

    mmc: block: Be sure to wait while busy in CQE error recovery
    
    commit c616696a902987352426fdaeec1b0b3240949e6b upstream.
    
    STOP command does not guarantee to wait while busy, but subsequent command
    MMC_CMDQ_TASK_MGMT to discard the queue will fail if the card is busy, so
    be sure to wait by employing mmc_poll_for_busy().
    
    Fixes: 72a5af554df8 ("mmc: core: Add support for handling CQE requests")
    Cc: stable@vger.kernel.org
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Reviewed-by: Christian Loehle <christian.loehle@arm.com>
    Link: https://lore.kernel.org/r/20231103084720.6886-4-adrian.hunter@intel.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Tested-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b8b2c5d767590661ae7a230b0186b904b36ef44
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Sun Dec 10 22:12:50 2023 -0500

    ring-buffer: Fix memory leak of free page
    
    commit 17d801758157bec93f26faaf5ff1a8b9a552d67a upstream.
    
    Reading the ring buffer does a swap of a sub-buffer within the ring buffer
    with a empty sub-buffer. This allows the reader to have full access to the
    content of the sub-buffer that was swapped out without having to worry
    about contention with the writer.
    
    The readers call ring_buffer_alloc_read_page() to allocate a page that
    will be used to swap with the ring buffer. When the code is finished with
    the reader page, it calls ring_buffer_free_read_page(). Instead of freeing
    the page, it stores it as a spare. Then next call to
    ring_buffer_alloc_read_page() will return this spare instead of calling
    into the memory management system to allocate a new page.
    
    Unfortunately, on freeing of the ring buffer, this spare page is not
    freed, and causes a memory leak.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20231210221250.7b9cc83c@rorschach.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Fixes: 73a757e63114d ("ring-buffer: Return reader page back into existing ring buffer")
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3459c9aa6495f96628aa750816f3dd9ef3df1eb4
Author: Florent Revest <revest@chromium.org>
Date:   Wed Dec 6 13:37:18 2023 +0100

    team: Fix use-after-free when an option instance allocation fails
    
    commit c12296bbecc488623b7d1932080e394d08f3226b upstream.
    
    In __team_options_register, team_options are allocated and appended to
    the team's option_list.
    If one option instance allocation fails, the "inst_rollback" cleanup
    path frees the previously allocated options but doesn't remove them from
    the team's option_list.
    This leaves dangling pointers that can be dereferenced later by other
    parts of the team driver that iterate over options.
    
    This patch fixes the cleanup path to remove the dangling pointers from
    the list.
    
    As far as I can tell, this uaf doesn't have much security implications
    since it would be fairly hard to exploit (an attacker would need to make
    the allocation of that specific small object fail) but it's still nice
    to fix.
    
    Cc: stable@vger.kernel.org
    Fixes: 80f7c6683fe0 ("team: add support for per-port options")
    Signed-off-by: Florent Revest <revest@chromium.org>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
    Link: https://lore.kernel.org/r/20231206123719.1963153-1-revest@chromium.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 363a67ef3adaa5132299c91d5312c06db8d9b8a7
Author: James Houghton <jthoughton@google.com>
Date:   Mon Dec 4 17:26:46 2023 +0000

    arm64: mm: Always make sw-dirty PTEs hw-dirty in pte_modify
    
    commit 3c0696076aad60a2f04c019761921954579e1b0e upstream.
    
    It is currently possible for a userspace application to enter an
    infinite page fault loop when using HugeTLB pages implemented with
    contiguous PTEs when HAFDBS is not available. This happens because:
    
    1. The kernel may sometimes write PTEs that are sw-dirty but hw-clean
       (PTE_DIRTY | PTE_RDONLY | PTE_WRITE).
    
    2. If, during a write, the CPU uses a sw-dirty, hw-clean PTE in handling
       the memory access on a system without HAFDBS, we will get a page
       fault.
    
    3. HugeTLB will check if it needs to update the dirty bits on the PTE.
       For contiguous PTEs, it will check to see if the pgprot bits need
       updating. In this case, HugeTLB wants to write a sequence of
       sw-dirty, hw-dirty PTEs, but it finds that all the PTEs it is about
       to overwrite are all pte_dirty() (pte_sw_dirty() => pte_dirty()),
       so it thinks no update is necessary.
    
    We can get the kernel to write a sw-dirty, hw-clean PTE with the
    following steps (showing the relevant VMA flags and pgprot bits):
    
    i.   Create a valid, writable contiguous PTE.
           VMA vmflags:     VM_SHARED | VM_READ | VM_WRITE
           VMA pgprot bits: PTE_RDONLY | PTE_WRITE
           PTE pgprot bits: PTE_DIRTY | PTE_WRITE
    
    ii.  mprotect the VMA to PROT_NONE.
           VMA vmflags:     VM_SHARED
           VMA pgprot bits: PTE_RDONLY
           PTE pgprot bits: PTE_DIRTY | PTE_RDONLY
    
    iii. mprotect the VMA back to PROT_READ | PROT_WRITE.
           VMA vmflags:     VM_SHARED | VM_READ | VM_WRITE
           VMA pgprot bits: PTE_RDONLY | PTE_WRITE
           PTE pgprot bits: PTE_DIRTY | PTE_WRITE | PTE_RDONLY
    
    Make it impossible to create a writeable sw-dirty, hw-clean PTE with
    pte_modify(). Such a PTE should be impossible to create, and there may
    be places that assume that pte_dirty() implies pte_hw_dirty().
    
    Signed-off-by: James Houghton <jthoughton@google.com>
    Fixes: 031e6e6b4e12 ("arm64: hugetlb: Avoid unnecessary clearing in huge_ptep_set_access_flags")
    Cc: <stable@vger.kernel.org>
    Acked-by: Will Deacon <will@kernel.org>
    Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
    Link: https://lore.kernel.org/r/20231204172646.2541916-3-jthoughton@google.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de8ada02369ed588542fafd86059f956bd080ca2
Author: Baokun Li <libaokun1@huawei.com>
Date:   Mon Nov 27 14:33:13 2023 +0800

    ext4: prevent the normalized size from exceeding EXT_MAX_BLOCKS
    
    commit 2dcf5fde6dffb312a4bfb8ef940cea2d1f402e32 upstream.
    
    For files with logical blocks close to EXT_MAX_BLOCKS, the file size
    predicted in ext4_mb_normalize_request() may exceed EXT_MAX_BLOCKS.
    This can cause some blocks to be preallocated that will not be used.
    And after [Fixes], the following issue may be triggered:
    
    =========================================================
     kernel BUG at fs/ext4/mballoc.c:4653!
     Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
     CPU: 1 PID: 2357 Comm: xfs_io 6.7.0-rc2-00195-g0f5cc96c367f
     Hardware name: linux,dummy-virt (DT)
     pc : ext4_mb_use_inode_pa+0x148/0x208
     lr : ext4_mb_use_inode_pa+0x98/0x208
     Call trace:
      ext4_mb_use_inode_pa+0x148/0x208
      ext4_mb_new_inode_pa+0x240/0x4a8
      ext4_mb_use_best_found+0x1d4/0x208
      ext4_mb_try_best_found+0xc8/0x110
      ext4_mb_regular_allocator+0x11c/0xf48
      ext4_mb_new_blocks+0x790/0xaa8
      ext4_ext_map_blocks+0x7cc/0xd20
      ext4_map_blocks+0x170/0x600
      ext4_iomap_begin+0x1c0/0x348
    =========================================================
    
    Here is a calculation when adjusting ac_b_ex in ext4_mb_new_inode_pa():
    
            ex.fe_logical = orig_goal_end - EXT4_C2B(sbi, ex.fe_len);
            if (ac->ac_o_ex.fe_logical >= ex.fe_logical)
                    goto adjust_bex;
    
    The problem is that when orig_goal_end is subtracted from ac_b_ex.fe_len
    it is still greater than EXT_MAX_BLOCKS, which causes ex.fe_logical to
    overflow to a very small value, which ultimately triggers a BUG_ON in
    ext4_mb_new_inode_pa() because pa->pa_free < len.
    
    The last logical block of an actual write request does not exceed
    EXT_MAX_BLOCKS, so in ext4_mb_normalize_request() also avoids normalizing
    the last logical block to exceed EXT_MAX_BLOCKS to avoid the above issue.
    
    The test case in [Link] can reproduce the above issue with 64k block size.
    
    Link: https://patchwork.kernel.org/project/fstests/list/?series=804003
    Cc:  <stable@kernel.org> # 6.4
    Fixes: 93cdf49f6eca ("ext4: Fix best extent lstart adjustment logic in ext4_mb_new_inode_pa()")
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20231127063313.3734294-1-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f451d6784ba6e676b8233c2a7dcc542d95c6b44f
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Nov 24 19:01:36 2023 +0100

    soundwire: stream: fix NULL pointer dereference for multi_link
    
    commit e199bf52ffda8f98f129728d57244a9cd9ad5623 upstream.
    
    If bus is marked as multi_link, but number of masters in the stream is
    not higher than bus->hw_sync_min_links (bus->multi_link && m_rt_count >=
    bus->hw_sync_min_links), bank switching should not happen.  The first
    part of do_bank_switch() code properly takes these conditions into
    account, but second part (sdw_ml_sync_bank_switch()) relies purely on
    bus->multi_link property.  This is not balanced and leads to NULL
    pointer dereference:
    
      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
      ...
      Call trace:
       wait_for_completion_timeout+0x124/0x1f0
       do_bank_switch+0x370/0x6f8
       sdw_prepare_stream+0x2d0/0x438
       qcom_snd_sdw_prepare+0xa0/0x118
       sm8450_snd_prepare+0x128/0x148
       snd_soc_link_prepare+0x5c/0xe8
       __soc_pcm_prepare+0x28/0x1ec
       dpcm_be_dai_prepare+0x1e0/0x2c0
       dpcm_fe_dai_prepare+0x108/0x28c
       snd_pcm_do_prepare+0x44/0x68
       snd_pcm_action_single+0x54/0xc0
       snd_pcm_action_nonatomic+0xe4/0xec
       snd_pcm_prepare+0xc4/0x114
       snd_pcm_common_ioctl+0x1154/0x1cc0
       snd_pcm_ioctl+0x54/0x74
    
    Fixes: ce6e74d008ff ("soundwire: Add support for multi link bank switch")
    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/20231124180136.390621-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 404902216b888b44cf822ed95fda7a7f26b72136
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri Dec 15 11:24:50 2023 +0000

    perf: Fix perf_event_validate_size() lockdep splat
    
    commit 7e2c1e4b34f07d9aa8937fab88359d4a0fce468e upstream.
    
    When lockdep is enabled, the for_each_sibling_event(sibling, event)
    macro checks that event->ctx->mutex is held. When creating a new group
    leader event, we call perf_event_validate_size() on a partially
    initialized event where event->ctx is NULL, and so when
    for_each_sibling_event() attempts to check event->ctx->mutex, we get a
    splat, as reported by Lucas De Marchi:
    
      WARNING: CPU: 8 PID: 1471 at kernel/events/core.c:1950 __do_sys_perf_event_open+0xf37/0x1080
    
    This only happens for a new event which is its own group_leader, and in
    this case there cannot be any sibling events. Thus it's safe to skip the
    check for siblings, which avoids having to make invasive and ugly
    changes to for_each_sibling_event().
    
    Avoid the splat by bailing out early when the new event is its own
    group_leader.
    
    Fixes: 382c27f4ed28f803 ("perf: Fix perf_event_validate_size()")
    Closes: https://lore.kernel.org/lkml/20231214000620.3081018-1-lucas.demarchi@intel.com/
    Closes: https://lore.kernel.org/lkml/ZXpm6gQ%2Fd59jGsuW@xpf.sh.intel.com/
    Reported-by: Lucas De Marchi <lucas.demarchi@intel.com>
    Reported-by: Pengfei Xu <pengfei.xu@intel.com>
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20231215112450.3972309-1-mark.rutland@arm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4109d9a855f23748a11b97edf230028ba2c59505
Author: Denis Benato <benato.denis96@gmail.com>
Date:   Fri Nov 17 14:15:55 2023 +1300

    HID: hid-asus: add const to read-only outgoing usb buffer
    
    [ Upstream commit 06ae5afce8cc1f7621cc5c7751e449ce20d68af7 ]
    
    In the function asus_kbd_set_report the parameter buf is read-only
    as it gets copied in a memory portion suitable for USB transfer,
    but the parameter is not marked as const: add the missing const and mark
    const immutable buffers passed to that function.
    
    Signed-off-by: Denis Benato <benato.denis96@gmail.com>
    Signed-off-by: Luke D. Jones <luke@ljones.dev>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1fc4091991c50b3433ae840707cb878fc359611a
Author: Lech Perczak <lech.perczak@gmail.com>
Date:   Sat Nov 18 00:19:18 2023 +0100

    net: usb: qmi_wwan: claim interface 4 for ZTE MF290
    
    [ Upstream commit 99360d9620f09fb8bc15548d855011bbb198c680 ]
    
    Interface 4 is used by for QMI interface in stock firmware of MF28D, the
    router which uses MF290 modem. Rebind it to qmi_wwan after freeing it up
    from option driver.
    The proper configuration is:
    
    Interface mapping is:
    0: QCDM, 1: (unknown), 2: AT (PCUI), 2: AT (Modem), 4: QMI
    
    T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=19d2 ProdID=0189 Rev= 0.00
    S:  Manufacturer=ZTE, Incorporated
    S:  Product=ZTE LTE Technologies MSM
    C:* #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
    
    Cc: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
    Link: https://lore.kernel.org/r/20231117231918.100278-3-lech.perczak@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 88ceaf8e2c61b0744387db7c401f4fb13e1f58f5
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Nov 9 22:22:13 2023 -0800

    asm-generic: qspinlock: fix queued_spin_value_unlocked() implementation
    
    [ Upstream commit 125b0bb95dd6bec81b806b997a4ccb026eeecf8f ]
    
    We really don't want to do atomic_read() or anything like that, since we
    already have the value, not the lock.  The whole point of this is that
    we've loaded the lock from memory, and we want to check whether the
    value we loaded was a locked one or not.
    
    The main use of this is the lockref code, which loads both the lock and
    the reference count in one atomic operation, and then works on that
    combined value.  With the atomic_read(), the compiler would pointlessly
    spill the value to the stack, in order to then be able to read it back
    "atomically".
    
    This is the qspinlock version of commit c6f4a9002252 ("asm-generic:
    ticket-lock: Optimize arch_spin_value_unlocked()") which fixed this same
    bug for ticket locks.
    
    Cc: Guo Ren <guoren@kernel.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Waiman Long <longman@redhat.com>
    Link: https://lore.kernel.org/all/CAHk-=whNRv0v6kQiV5QO6DJhjH4KEL36vWQ6Re8Csrnh4zbRkQ@mail.gmail.com/
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 91175d6fe505823e0890a377527a1d5a645811e5
Author: Aoba K <nexp_0x17@outlook.com>
Date:   Tue Nov 21 20:23:11 2023 +0800

    HID: multitouch: Add quirk for HONOR GLO-GXXX touchpad
    
    [ Upstream commit 9ffccb691adb854e7b7f3ee57fbbda12ff70533f ]
    
    Honor MagicBook 13 2023 has a touchpad which do not switch to the multitouch
    mode until the input mode feature is written by the host.  The touchpad do
    report the input mode at touchpad(3), while itself working under mouse mode. As
    a workaround, it is possible to call MT_QUIRE_FORCE_GET_FEATURE to force set
    feature in mt_set_input_mode for such device.
    
    The touchpad reports as BLTP7853, which cannot retrive any useful manufacture
    information on the internel by this string at present.  As the serial number of
    the laptop is GLO-G52, while DMI info reports the laptop serial number as
    GLO-GXXX, this workaround should applied to all models which has the GLO-GXXX.
    
    Signed-off-by: Aoba K <nexp_0x17@outlook.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1f94c0d60d819656f3f0eb3c024d77669ca0baa7
Author: Denis Benato <benato.denis96@gmail.com>
Date:   Fri Nov 17 14:15:56 2023 +1300

    HID: hid-asus: reset the backlight brightness level on resume
    
    [ Upstream commit 546edbd26cff7ae990e480a59150e801a06f77b1 ]
    
    Some devices managed by this driver automatically set brightness to 0
    before entering a suspended state and reset it back to a default
    brightness level after the resume:
    this has the effect of having the kernel report wrong brightness
    status after a sleep, and on some devices (like the Asus RC71L) that
    brightness is the intensity of LEDs directly facing the user.
    
    Fix the above issue by setting back brightness to the level it had
    before entering a sleep state.
    
    Signed-off-by: Denis Benato <benato.denis96@gmail.com>
    Signed-off-by: Luke D. Jones <luke@ljones.dev>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e9a3cd3dcf3f86d59a7dfceefefeca8223dfe41d
Author: Oliver Neukum <oneukum@suse.com>
Date:   Tue Nov 14 15:54:30 2023 +0100

    HID: add ALWAYS_POLL quirk for Apple kb
    
    [ Upstream commit c55092187d9ad7b2f8f5a8645286fa03997d442f ]
    
    These devices disconnect if suspended without remote wakeup. They can operate
    with the standard driver.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 395ad0baa4c16fbf9c7af93526d3cdc08ed6c470
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Mon Nov 20 17:07:56 2023 +0200

    platform/x86: intel_telemetry: Fix kernel doc descriptions
    
    [ Upstream commit a6584711e64d9d12ab79a450ec3628fd35e4f476 ]
    
    LKP found issues with a kernel doc in the driver:
    
    core.c:116: warning: Function parameter or member 'ioss_evtconfig' not described in 'telemetry_update_events'
    core.c:188: warning: Function parameter or member 'ioss_evtconfig' not described in 'telemetry_get_eventconfig'
    
    It looks like it were copy'n'paste typos when these descriptions
    had been introduced. Fix the typos.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202310070743.WALmRGSY-lkp@intel.com/
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20231120150756.1661425-1-andriy.shevchenko@linux.intel.com
    Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit af509912cd7c8b38e27ec3295bf9b530c1a4671d
Author: Coly Li <colyli@suse.de>
Date:   Mon Nov 20 13:25:03 2023 +0800

    bcache: avoid NULL checking to c->root in run_cache_set()
    
    [ Upstream commit 3eba5e0b2422aec3c9e79822029599961fdcab97 ]
    
    In run_cache_set() after c->root returned from bch_btree_node_get(), it
    is checked by IS_ERR_OR_NULL(). Indeed it is unncessary to check NULL
    because bch_btree_node_get() will not return NULL pointer to caller.
    
    This patch replaces IS_ERR_OR_NULL() by IS_ERR() for the above reason.
    
    Signed-off-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20231120052503.6122-11-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 356ae9de79b7d9801b572134b729ad09957945b4
Author: Coly Li <colyli@suse.de>
Date:   Mon Nov 20 13:25:02 2023 +0800

    bcache: add code comments for bch_btree_node_get() and __bch_btree_node_alloc()
    
    [ Upstream commit 31f5b956a197d4ec25c8a07cb3a2ab69d0c0b82f ]
    
    This patch adds code comments to bch_btree_node_get() and
    __bch_btree_node_alloc() that NULL pointer will not be returned and it
    is unnecessary to check NULL pointer by the callers of these routines.
    
    Signed-off-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20231120052503.6122-10-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ca4b00c6cb3d89535e579f8dc4dbc38044c5e7d0
Author: Coly Li <colyli@suse.de>
Date:   Mon Nov 20 13:24:54 2023 +0800

    bcache: avoid oversize memory allocation by small stripe_size
    
    [ Upstream commit baf8fb7e0e5ec54ea0839f0c534f2cdcd79bea9c ]
    
    Arraies bcache->stripe_sectors_dirty and bcache->full_dirty_stripes are
    used for dirty data writeback, their sizes are decided by backing device
    capacity and stripe size. Larger backing device capacity or smaller
    stripe size make these two arraies occupies more dynamic memory space.
    
    Currently bcache->stripe_size is directly inherited from
    queue->limits.io_opt of underlying storage device. For normal hard
    drives, its limits.io_opt is 0, and bcache sets the corresponding
    stripe_size to 1TB (1<<31 sectors), it works fine 10+ years. But for
    devices do declare value for queue->limits.io_opt, small stripe_size
    (comparing to 1TB) becomes an issue for oversize memory allocations of
    bcache->stripe_sectors_dirty and bcache->full_dirty_stripes, while the
    capacity of hard drives gets much larger in recent decade.
    
    For example a raid5 array assembled by three 20TB hardrives, the raid
    device capacity is 40TB with typical 512KB limits.io_opt. After the math
    calculation in bcache code, these two arraies will occupy 400MB dynamic
    memory. Even worse Andrea Tomassetti reports that a 4KB limits.io_opt is
    declared on a new 2TB hard drive, then these two arraies request 2GB and
    512MB dynamic memory from kzalloc(). The result is that bcache device
    always fails to initialize on his system.
    
    To avoid the oversize memory allocation, bcache->stripe_size should not
    directly inherited by queue->limits.io_opt from the underlying device.
    This patch defines BCH_MIN_STRIPE_SZ (4MB) as minimal bcache stripe size
    and set bcache device's stripe size against the declared limits.io_opt
    value from the underlying storage device,
    - If the declared limits.io_opt > BCH_MIN_STRIPE_SZ, bcache device will
      set its stripe size directly by this limits.io_opt value.
    - If the declared limits.io_opt < BCH_MIN_STRIPE_SZ, bcache device will
      set its stripe size by a value multiplying limits.io_opt and euqal or
      large than BCH_MIN_STRIPE_SZ.
    
    Then the minimal stripe size of a bcache device will always be >= 4MB.
    For a 40TB raid5 device with 512KB limits.io_opt, memory occupied by
    bcache->stripe_sectors_dirty and bcache->full_dirty_stripes will be 50MB
    in total. For a 2TB hard drive with 4KB limits.io_opt, memory occupied
    by these two arraies will be 2.5MB in total.
    
    Such mount of memory allocated for bcache->stripe_sectors_dirty and
    bcache->full_dirty_stripes is reasonable for most of storage devices.
    
    Reported-by: Andrea Tomassetti <andrea.tomassetti-opensource@devo.com>
    Signed-off-by: Coly Li <colyli@suse.de>
    Reviewed-by: Eric Wheeler <bcache@lists.ewheeler.net>
    Link: https://lore.kernel.org/r/20231120052503.6122-2-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e1d811cbc3dec74fd3f3bca867083f526b518a11
Author: Ming Lei <ming.lei@redhat.com>
Date:   Fri Nov 17 10:35:22 2023 +0800

    blk-throttle: fix lockdep warning of "cgroup_mutex or RCU read lock required!"
    
    [ Upstream commit 27b13e209ddca5979847a1b57890e0372c1edcee ]
    
    Inside blkg_for_each_descendant_pre(), both
    css_for_each_descendant_pre() and blkg_lookup() requires RCU read lock,
    and either cgroup_assert_mutex_or_rcu_locked() or rcu_read_lock_held()
    is called.
    
    Fix the warning by adding rcu read lock.
    
    Reported-by: Changhui Zhong <czhong@redhat.com>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20231117023527.3188627-2-ming.lei@redhat.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 84f2e5b3e70f08fce3cb1ff73414631c5e490204
Author: Oliver Neukum <oneukum@suse.com>
Date:   Wed Nov 15 11:08:57 2023 +0100

    usb: aqc111: check packet for fixup for true limit
    
    [ Upstream commit ccab434e674ca95d483788b1895a70c21b7f016a ]
    
    If a device sends a packet that is inbetween 0
    and sizeof(u64) the value passed to skb_trim()
    as length will wrap around ending up as some very
    large value.
    
    The driver will then proceed to parse the header
    located at that position, which will either oops or
    process some random value.
    
    The fix is to check against sizeof(u64) rather than
    0, which the driver currently does. The issue exists
    since the introduction of the driver.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 619a34066614d841f654ac5f4ac17749909dc473
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Thu Dec 14 09:08:56 2023 -0600

    Revert "PCI: acpiphp: Reassign resources on bridge if necessary"
    
    commit 5df12742b7e3aae2594a30a9d14d5d6e9e7699f4 upstream.
    
    This reverts commit 40613da52b13fb21c5566f10b287e0ca8c12c4e9 and the
    subsequent fix to it:
    
      cc22522fd55e ("PCI: acpiphp: Use pci_assign_unassigned_bridge_resources() only for non-root bus")
    
    40613da52b13 fixed a problem where hot-adding a device with large BARs
    failed if the bridge windows programmed by firmware were not large enough.
    
    cc22522fd55e ("PCI: acpiphp: Use pci_assign_unassigned_bridge_resources()
    only for non-root bus") fixed a problem with 40613da52b13: an ACPI hot-add
    of a device on a PCI root bus (common in the virt world) or firmware
    sending ACPI Bus Check to non-existent Root Ports (e.g., on Dell Inspiron
    7352/0W6WV0) caused a NULL pointer dereference and suspend/resume hangs.
    
    Unfortunately the combination of 40613da52b13 and cc22522fd55e caused other
    problems:
    
      - Fiona reported that hot-add of SCSI disks in QEMU virtual machine fails
        sometimes.
    
      - Dongli reported a similar problem with hot-add of SCSI disks.
    
      - Jonathan reported a console freeze during boot on bare metal due to an
        error in radeon GPU initialization.
    
    Revert both patches to avoid adding these problems.  This means we will
    again see the problems with hot-adding devices with large BARs and the NULL
    pointer dereferences and suspend/resume issues that 40613da52b13 and
    cc22522fd55e were intended to fix.
    
    Fixes: 40613da52b13 ("PCI: acpiphp: Reassign resources on bridge if necessary")
    Fixes: cc22522fd55e ("PCI: acpiphp: Use pci_assign_unassigned_bridge_resources() only for non-root bus")
    Reported-by: Fiona Ebner <f.ebner@proxmox.com>
    Closes: https://lore.kernel.org/r/9eb669c0-d8f2-431d-a700-6da13053ae54@proxmox.com
    Reported-by: Dongli Zhang <dongli.zhang@oracle.com>
    Closes: https://lore.kernel.org/r/3c4a446a-b167-11b8-f36f-d3c1b49b42e9@oracle.com
    Reported-by: Jonathan Woithe <jwoithe@just42.net>
    Closes: https://lore.kernel.org/r/ZXpaNCLiDM+Kv38H@marvin.atrad.com.au
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Igor Mammedov <imammedo@redhat.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 371dbce60a46c21a8b9d56dfdc9a3089ccd08d2f
Author: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Date:   Fri Dec 8 15:21:27 2023 +0200

    ALSA: hda/hdmi: add force-connect quirks for ASUSTeK Z170 variants
    
    commit 924f5ca2975b2993ee81a7ecc3c809943a70f334 upstream.
    
    On ASUSTeK Z170M PLUS and Z170 PRO GAMING systems, the display codec
    pins are not registered properly without the force-connect quirk. The
    codec will report only one pin as having external connectivity, but i915
    finds all three connectors on the system, so the two drivers are not
    in sync.
    
    Issue found with DRM igt-gpu-tools test kms_hdmi_inject@inject-audio.
    
    Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9801
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Jani Saarinen <jani.saarinen@intel.com>
    Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20231208132127.2438067-3-kai.vehmanen@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be7676b03aed89d4ba63ee23c515b5c93a96bf6f
Author: Jens Axboe <axboe@kernel.dk>
Date:   Fri Dec 15 13:24:10 2023 -0700

    cred: switch to using atomic_long_t
    
    commit f8fa5d76925991976b3e7076f9d1052515ec1fca upstream.
    
    There are multiple ways to grab references to credentials, and the only
    protection we have against overflowing it is the memory required to do
    so.
    
    With memory sizes only moving in one direction, let's bump the reference
    count to 64-bit and move it outside the realm of feasibly overflowing.
    
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9112bd107208cd6a4f0175ca36289ed170622cce
Author: Hyunwoo Kim <v4bel@theori.io>
Date:   Tue Dec 12 23:10:56 2023 -0500

    appletalk: Fix Use-After-Free in atalk_ioctl
    
    [ Upstream commit 189ff16722ee36ced4d2a2469d4ab65a8fee4198 ]
    
    Because atalk_ioctl() accesses sk->sk_receive_queue
    without holding a sk->sk_receive_queue.lock, it can
    cause a race with atalk_recvmsg().
    A use-after-free for skb occurs with the following flow.
    ```
    atalk_ioctl() -> skb_peek()
    atalk_recvmsg() -> skb_recv_datagram() -> skb_free_datagram()
    ```
    Add sk->sk_receive_queue.lock to atalk_ioctl() to fix this issue.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Hyunwoo Kim <v4bel@theori.io>
    Link: https://lore.kernel.org/r/20231213041056.GA519680@v4bel-B760M-AORUS-ELITE-AX
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 23ee06762c6fdc5abbd16669182bacc80cc2b485
Author: Andrew Halaney <ahalaney@redhat.com>
Date:   Tue Dec 12 16:18:33 2023 -0600

    net: stmmac: Handle disabled MDIO busses from devicetree
    
    [ Upstream commit e23c0d21ce9234fbc31ece35663ababbb83f9347 ]
    
    Many hardware configurations have the MDIO bus disabled, and are instead
    using some other MDIO bus to talk to the MAC's phy.
    
    of_mdiobus_register() returns -ENODEV in this case. Let's handle it
    gracefully instead of failing to probe the MAC.
    
    Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.")
    Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
    Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
    Link: https://lore.kernel.org/r/20231212-b4-stmmac-handle-mdio-enodev-v2-1-600171acf79f@redhat.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 538b7b8f21dcd77784aa088bcf27900ce66af91b
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Thu Jun 2 09:48:40 2022 +0200

    net: stmmac: use dev_err_probe() for reporting mdio bus registration failure
    
    [ Upstream commit 839612d23ffd933174db911ce56dc3f3ca883ec5 ]
    
    I have a board where these two lines are always printed during boot:
    
       imx-dwmac 30bf0000.ethernet: Cannot register the MDIO bus
       imx-dwmac 30bf0000.ethernet: stmmac_dvr_probe: MDIO bus (id: 1) registration failed
    
    It's perfectly fine, and the device is successfully (and silently, as
    far as the console goes) probed later.
    
    Use dev_err_probe() instead, which will demote these messages to debug
    level (thus removing the alarming messages from the console) when the
    error is -EPROBE_DEFER, and also has the advantage of including the
    error code if/when it happens to be something other than -EPROBE_DEFER.
    
    While here, add the missing \n to one of the format strings.
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Link: https://lore.kernel.org/r/20220602074840.1143360-1-linux@rasmusvillemoes.dk
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: e23c0d21ce92 ("net: stmmac: Handle disabled MDIO busses from devicetree")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 067e6ec9f53077ef6513b4fcfcc882713eb95b4e
Author: Nikolay Kuratov <kniv@yandex-team.ru>
Date:   Mon Dec 11 19:23:17 2023 +0300

    vsock/virtio: Fix unsigned integer wrap around in virtio_transport_has_space()
    
    [ Upstream commit 60316d7f10b17a7ebb1ead0642fee8710e1560e0 ]
    
    We need to do signed arithmetic if we expect condition
    `if (bytes < 0)` to be possible
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE
    
    Fixes: 06a8fc78367d ("VSOCK: Introduce virtio_vsock_common.ko")
    Signed-off-by: Nikolay Kuratov <kniv@yandex-team.ru>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Link: https://lore.kernel.org/r/20231211162317.4116625-1-kniv@yandex-team.ru
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cc7cf0b2ee60df74ee0b82e97dfded86eafb4b30
Author: Yusong Gao <a869920004@gmail.com>
Date:   Wed Dec 13 10:31:10 2023 +0000

    sign-file: Fix incorrect return values check
    
    [ Upstream commit 829649443e78d85db0cff0c37cadb28fbb1a5f6f ]
    
    There are some wrong return values check in sign-file when call OpenSSL
    API. The ERR() check cond is wrong because of the program only check the
    return value is < 0 which ignored the return val is 0. For example:
    1. CMS_final() return 1 for success or 0 for failure.
    2. i2d_CMS_bio_stream() returns 1 for success or 0 for failure.
    3. i2d_TYPEbio() return 1 for success and 0 for failure.
    4. BIO_free() return 1 for success and 0 for failure.
    
    Link: https://www.openssl.org/docs/manmaster/man3/
    Fixes: e5a2e3c84782 ("scripts/sign-file.c: Add support for signing with a raw signature")
    Signed-off-by: Yusong Gao <a869920004@gmail.com>
    Reviewed-by: Juerg Haefliger <juerg.haefliger@canonical.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Link: https://lore.kernel.org/r/20231213024405.624692-1-a869920004@gmail.com/ # v5
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 510d45207ae1cd463d0b8085e4ff44e2a6c70c6f
Author: Dong Chenchen <dongchenchen2@huawei.com>
Date:   Sun Dec 10 10:02:00 2023 +0800

    net: Remove acked SYN flag from packet in the transmit queue correctly
    
    [ Upstream commit f99cd56230f56c8b6b33713c5be4da5d6766be1f ]
    
    syzkaller report:
    
     kernel BUG at net/core/skbuff.c:3452!
     invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
     CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.7.0-rc4-00009-gbee0e7762ad2-dirty #135
     RIP: 0010:skb_copy_and_csum_bits (net/core/skbuff.c:3452)
     Call Trace:
     icmp_glue_bits (net/ipv4/icmp.c:357)
     __ip_append_data.isra.0 (net/ipv4/ip_output.c:1165)
     ip_append_data (net/ipv4/ip_output.c:1362 net/ipv4/ip_output.c:1341)
     icmp_push_reply (net/ipv4/icmp.c:370)
     __icmp_send (./include/net/route.h:252 net/ipv4/icmp.c:772)
     ip_fragment.constprop.0 (./include/linux/skbuff.h:1234 net/ipv4/ip_output.c:592 net/ipv4/ip_output.c:577)
     __ip_finish_output (net/ipv4/ip_output.c:311 net/ipv4/ip_output.c:295)
     ip_output (net/ipv4/ip_output.c:427)
     __ip_queue_xmit (net/ipv4/ip_output.c:535)
     __tcp_transmit_skb (net/ipv4/tcp_output.c:1462)
     __tcp_retransmit_skb (net/ipv4/tcp_output.c:3387)
     tcp_retransmit_skb (net/ipv4/tcp_output.c:3404)
     tcp_retransmit_timer (net/ipv4/tcp_timer.c:604)
     tcp_write_timer (./include/linux/spinlock.h:391 net/ipv4/tcp_timer.c:716)
    
    The panic issue was trigered by tcp simultaneous initiation.
    The initiation process is as follows:
    
          TCP A                                            TCP B
    
      1.  CLOSED                                           CLOSED
    
      2.  SYN-SENT     --> <SEQ=100><CTL=SYN>              ...
    
      3.  SYN-RECEIVED <-- <SEQ=300><CTL=SYN>              <-- SYN-SENT
    
      4.               ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED
    
      5.  SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...
    
      // TCP B: not send challenge ack for ack limit or packet loss
      // TCP A: close
            tcp_close
               tcp_send_fin
                  if (!tskb && tcp_under_memory_pressure(sk))
                      tskb = skb_rb_last(&sk->tcp_rtx_queue); //pick SYN_ACK packet
               TCP_SKB_CB(tskb)->tcp_flags |= TCPHDR_FIN;  // set FIN flag
    
      6.  FIN_WAIT_1  --> <SEQ=100><ACK=301><END_SEQ=102><CTL=SYN,FIN,ACK> ...
    
      // TCP B: send challenge ack to SYN_FIN_ACK
    
      7.               ... <SEQ=301><ACK=101><CTL=ACK>   <-- SYN-RECEIVED //challenge ack
    
      // TCP A:  <SND.UNA=101>
    
      8.  FIN_WAIT_1 --> <SEQ=101><ACK=301><END_SEQ=102><CTL=SYN,FIN,ACK> ... // retransmit panic
    
            __tcp_retransmit_skb  //skb->len=0
                tcp_trim_head
                    len = tp->snd_una - TCP_SKB_CB(skb)->seq // len=101-100
                        __pskb_trim_head
                            skb->data_len -= len // skb->len=-1, wrap around
                ... ...
                ip_fragment
                    icmp_glue_bits //BUG_ON
    
    If we use tcp_trim_head() to remove acked SYN from packet that contains data
    or other flags, skb->len will be incorrectly decremented. We can remove SYN
    flag that has been acked from rtx_queue earlier than tcp_trim_head(), which
    can fix the problem mentioned above.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Co-developed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com>
    Link: https://lore.kernel.org/r/20231210020200.1539875-1-dongchenchen2@huawei.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5d9d500a2811cc12ead9aee1c0dbf35529171a76
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Sun Dec 10 12:52:55 2023 +0800

    qed: Fix a potential use-after-free in qed_cxt_tables_alloc
    
    [ Upstream commit b65d52ac9c085c0c52dee012a210d4e2f352611b ]
    
    qed_ilt_shadow_alloc() will call qed_ilt_shadow_free() to
    free p_hwfn->p_cxt_mngr->ilt_shadow on error. However,
    qed_cxt_tables_alloc() accesses the freed pointer on failure
    of qed_ilt_shadow_alloc() through calling qed_cxt_mngr_free(),
    which may lead to use-after-free. Fix this issue by setting
    p_mngr->ilt_shadow to NULL in qed_ilt_shadow_free().
    
    Fixes: fe56b9e6a8d9 ("qed: Add module with basic common support")
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Link: https://lore.kernel.org/r/20231210045255.21383-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3df812627e7d0bf557f3781c3448d42c8fe8313e
Author: Hyunwoo Kim <v4bel@theori.io>
Date:   Sat Dec 9 05:05:38 2023 -0500

    net/rose: Fix Use-After-Free in rose_ioctl
    
    [ Upstream commit 810c38a369a0a0ce625b5c12169abce1dd9ccd53 ]
    
    Because rose_ioctl() accesses sk->sk_receive_queue
    without holding a sk->sk_receive_queue.lock, it can
    cause a race with rose_accept().
    A use-after-free for skb occurs with the following flow.
    ```
    rose_ioctl() -> skb_peek()
    rose_accept() -> skb_dequeue() -> kfree_skb()
    ```
    Add sk->sk_receive_queue.lock to rose_ioctl() to fix this issue.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Hyunwoo Kim <v4bel@theori.io>
    Link: https://lore.kernel.org/r/20231209100538.GA407321@v4bel-B760M-AORUS-ELITE-AX
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b099c28847cfa33854731eeec9c64619d99a1255
Author: Hyunwoo Kim <v4bel@theori.io>
Date:   Sat Dec 9 04:42:10 2023 -0500

    atm: Fix Use-After-Free in do_vcc_ioctl
    
    [ Upstream commit 24e90b9e34f9e039f56b5f25f6e6eb92cdd8f4b3 ]
    
    Because do_vcc_ioctl() accesses sk->sk_receive_queue
    without holding a sk->sk_receive_queue.lock, it can
    cause a race with vcc_recvmsg().
    A use-after-free for skb occurs with the following flow.
    ```
    do_vcc_ioctl() -> skb_peek()
    vcc_recvmsg() -> skb_recv_datagram() -> skb_free_datagram()
    ```
    Add sk->sk_receive_queue.lock to do_vcc_ioctl() to fix this issue.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Hyunwoo Kim <v4bel@theori.io>
    Link: https://lore.kernel.org/r/20231209094210.GA403126@v4bel-B760M-AORUS-ELITE-AX
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e3430b870eff184cf1c8a07665095919153349af
Author: Chengfeng Ye <dg573847474@gmail.com>
Date:   Thu Dec 7 12:34:53 2023 +0000

    atm: solos-pci: Fix potential deadlock on &tx_queue_lock
    
    [ Upstream commit 15319a4e8ee4b098118591c6ccbd17237f841613 ]
    
    As &card->tx_queue_lock is acquired under softirq context along the
    following call chain from solos_bh(), other acquisition of the same
    lock inside process context should disable at least bh to avoid double
    lock.
    
    <deadlock #2>
    pclose()
    --> spin_lock(&card->tx_queue_lock)
    <interrupt>
       --> solos_bh()
       --> fpga_tx()
       --> spin_lock(&card->tx_queue_lock)
    
    This flaw was found by an experimental static analysis tool I am
    developing for irq-related deadlock.
    
    To prevent the potential deadlock, the patch uses spin_lock_bh()
    on &card->tx_queue_lock under process context code consistently to
    prevent the possible deadlock scenario.
    
    Fixes: 213e85d38912 ("solos-pci: clean up pclose() function")
    Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8cff60fb736bd20b9201e55ae893b10ee8cfd057
Author: Chengfeng Ye <dg573847474@gmail.com>
Date:   Thu Dec 7 12:34:37 2023 +0000

    atm: solos-pci: Fix potential deadlock on &cli_queue_lock
    
    [ Upstream commit d5dba32b8f6cb39be708b726044ba30dbc088b30 ]
    
    As &card->cli_queue_lock is acquired under softirq context along the
    following call chain from solos_bh(), other acquisition of the same
    lock inside process context should disable at least bh to avoid double
    lock.
    
    <deadlock #1>
    console_show()
    --> spin_lock(&card->cli_queue_lock)
    <interrupt>
       --> solos_bh()
       --> spin_lock(&card->cli_queue_lock)
    
    This flaw was found by an experimental static analysis tool I am
    developing for irq-related deadlock.
    
    To prevent the potential deadlock, the patch uses spin_lock_bh()
    on the card->cli_queue_lock under process context code consistently
    to prevent the possible deadlock scenario.
    
    Fixes: 9c54004ea717 ("atm: Driver for Solos PCI ADSL2+ card.")
    Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fcf17666ef1b4b0b922893444ff1a27aa206e24e
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Wed Dec 6 15:12:22 2023 +0100

    qca_spi: Fix reset behavior
    
    [ Upstream commit 1057812d146dd658c9a9a96d869c2551150207b5 ]
    
    In case of a reset triggered by the QCA7000 itself, the behavior of the
    qca_spi driver was not quite correct:
    - in case of a pending RX frame decoding the drop counter must be
      incremented and decoding state machine reseted
    - also the reset counter must always be incremented regardless of sync
      state
    
    Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Link: https://lore.kernel.org/r/20231206141222.52029-4-wahrenst@gmx.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 51ad9c19bb573791f1bea4baf2ffc51d085aa1af
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Wed Dec 6 15:12:21 2023 +0100

    qca_debug: Fix ethtool -G iface tx behavior
    
    [ Upstream commit 96a7e861d9e04d07febd3011c30cd84cd141d81f ]
    
    After calling ethtool -g it was not possible to adjust the TX ring
    size again:
    
      # ethtool -g eth1
      Ring parameters for eth1:
      Pre-set maximums:
      RX:           4
      RX Mini:      n/a
      RX Jumbo:     n/a
      TX:           10
      Current hardware settings:
      RX:           4
      RX Mini:      n/a
      RX Jumbo:     n/a
      TX:           10
      # ethtool -G eth1 tx 8
      netlink error: Invalid argument
    
    The reason for this is that the readonly setting rx_pending get
    initialized and after that the range check in qcaspi_set_ringparam()
    fails regardless of the provided parameter. So fix this by accepting
    the exposed RX defaults. Instead of adding another magic number
    better use a new define here.
    
    Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
    Suggested-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Link: https://lore.kernel.org/r/20231206141222.52029-3-wahrenst@gmx.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b7f58686643f3eb6eeab1841b228453638bf845b
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Wed Dec 6 15:12:20 2023 +0100

    qca_debug: Prevent crash on TX ring changes
    
    [ Upstream commit f4e6064c97c050bd9904925ff7d53d0c9954fc7b ]
    
    The qca_spi driver stop and restart the SPI kernel thread
    (via ndo_stop & ndo_open) in case of TX ring changes. This is
    a big issue because it allows userspace to prevent restart of
    the SPI kernel thread (via signals). A subsequent change of
    TX ring wrongly assume a valid spi_thread pointer which result
    in a crash.
    
    So prevent this by stopping the network traffic handling and
    temporary park the SPI thread.
    
    Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Link: https://lore.kernel.org/r/20231206141222.52029-2-wahrenst@gmx.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9354e0acdb745f572b37b6a6911b07e8bad1c1df
Author: Maciej Żenczykowski <maze@google.com>
Date:   Wed Dec 6 09:36:12 2023 -0800

    net: ipv6: support reporting otherwise unknown prefix flags in RTM_NEWPREFIX
    
    [ Upstream commit bd4a816752bab609dd6d65ae021387beb9e2ddbd ]
    
    Lorenzo points out that we effectively clear all unknown
    flags from PIO when copying them to userspace in the netlink
    RTM_NEWPREFIX notification.
    
    We could fix this one at a time as new flags are defined,
    or in one fell swoop - I choose the latter.
    
    We could either define 6 new reserved flags (reserved1..6) and handle
    them individually (and rename them as new flags are defined), or we
    could simply copy the entire unmodified byte over - I choose the latter.
    
    This unfortunately requires some anonymous union/struct magic,
    so we add a static assert on the struct size for a little extra safety.
    
    Cc: David Ahern <dsahern@kernel.org>
    Cc: Lorenzo Colitti <lorenzo@google.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Maciej Żenczykowski <maze@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 053220aaed26420c793d454d1af8a118638e2b2a
Author: David Howells <dhowells@redhat.com>
Date:   Mon Dec 11 21:43:52 2023 +0000

    afs: Fix refcount underflow from error handling race
    
    [ Upstream commit 52bf9f6c09fca8c74388cd41cc24e5d1bff812a9 ]
    
    If an AFS cell that has an unreachable (eg. ENETUNREACH) server listed (VL
    server or fileserver), an asynchronous probe to one of its addresses may
    fail immediately because sendmsg() returns an error.  When this happens, a
    refcount underflow can happen if certain events hit a very small window.
    
    The way this occurs is:
    
     (1) There are two levels of "call" object, the afs_call and the
         rxrpc_call.  Each of them can be transitioned to a "completed" state
         in the event of success or failure.
    
     (2) Asynchronous afs_calls are self-referential whilst they are active to
         prevent them from evaporating when they're not being processed.  This
         reference is disposed of when the afs_call is completed.
    
         Note that an afs_call may only be completed once; once completed
         completing it again will do nothing.
    
     (3) When a call transmission is made, the app-side rxrpc code queues a Tx
         buffer for the rxrpc I/O thread to transmit.  The I/O thread invokes
         sendmsg() to transmit it - and in the case of failure, it transitions
         the rxrpc_call to the completed state.
    
     (4) When an rxrpc_call is completed, the app layer is notified.  In this
         case, the app is kafs and it schedules a work item to process events
         pertaining to an afs_call.
    
     (5) When the afs_call event processor is run, it goes down through the
         RPC-specific handler to afs_extract_data() to retrieve data from rxrpc
         - and, in this case, it picks up the error from the rxrpc_call and
         returns it.
    
         The error is then propagated to the afs_call and that is completed
         too.  At this point the self-reference is released.
    
     (6) If the rxrpc I/O thread manages to complete the rxrpc_call within the
         window between rxrpc_send_data() queuing the request packet and
         checking for call completion on the way out, then
         rxrpc_kernel_send_data() will return the error from sendmsg() to the
         app.
    
     (7) Then afs_make_call() will see an error and will jump to the error
         handling path which will attempt to clean up the afs_call.
    
     (8) The problem comes when the error handling path in afs_make_call()
         tries to unconditionally drop an async afs_call's self-reference.
         This self-reference, however, may already have been dropped by
         afs_extract_data() completing the afs_call
    
     (9) The refcount underflows when we return to afs_do_probe_vlserver() and
         that tries to drop its reference on the afs_call.
    
    Fix this by making afs_make_call() attempt to complete the afs_call rather
    than unconditionally putting it.  That way, if afs_extract_data() manages
    to complete the call first, afs_make_call() won't do anything.
    
    The bug can be forced by making do_udp_sendmsg() return -ENETUNREACH and
    sticking an msleep() in rxrpc_send_data() after the 'success:' label to
    widen the race window.
    
    The error message looks something like:
    
        refcount_t: underflow; use-after-free.
        WARNING: CPU: 3 PID: 720 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110
        ...
        RIP: 0010:refcount_warn_saturate+0xba/0x110
        ...
        afs_put_call+0x1dc/0x1f0 [kafs]
        afs_fs_get_capabilities+0x8b/0xe0 [kafs]
        afs_fs_probe_fileserver+0x188/0x1e0 [kafs]
        afs_lookup_server+0x3bf/0x3f0 [kafs]
        afs_alloc_server_list+0x130/0x2e0 [kafs]
        afs_create_volume+0x162/0x400 [kafs]
        afs_get_tree+0x266/0x410 [kafs]
        vfs_get_tree+0x25/0xc0
        fc_mount+0xe/0x40
        afs_d_automount+0x1b3/0x390 [kafs]
        __traverse_mounts+0x8f/0x210
        step_into+0x340/0x760
        path_openat+0x13a/0x1260
        do_filp_open+0xaf/0x160
        do_sys_openat2+0xaf/0x170
    
    or something like:
    
        refcount_t: underflow; use-after-free.
        ...
        RIP: 0010:refcount_warn_saturate+0x99/0xda
        ...
        afs_put_call+0x4a/0x175
        afs_send_vl_probes+0x108/0x172
        afs_select_vlserver+0xd6/0x311
        afs_do_cell_detect_alias+0x5e/0x1e9
        afs_cell_detect_alias+0x44/0x92
        afs_validate_fc+0x9d/0x134
        afs_get_tree+0x20/0x2e6
        vfs_get_tree+0x1d/0xc9
        fc_mount+0xe/0x33
        afs_d_automount+0x48/0x9d
        __traverse_mounts+0xe0/0x166
        step_into+0x140/0x274
        open_last_lookups+0x1c1/0x1df
        path_openat+0x138/0x1c3
        do_filp_open+0x55/0xb4
        do_sys_openat2+0x6c/0xb6
    
    Fixes: 34fa47612bfe ("afs: Fix race in async call refcounting")
    Reported-by: Bill MacAllister <bill@ca-zephyr.org>
    Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052304
    Suggested-by: Jeffrey E Altman <jaltman@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Link: https://lore.kernel.org/r/2633992.1702073229@warthog.procyon.org.uk/ # v1
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>