Linux 5.4.229

 
acct: fix potential integer overflow in encode_comp_t() [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Sat May 15 22:06:31 2021 +0800

    acct: fix potential integer overflow in encode_comp_t()
    
    [ Upstream commit c5f31c655bcc01b6da53b836ac951c1556245305 ]
    
    The integer overflow is descripted with following codes:
      > 317 static comp_t encode_comp_t(u64 value)
      > 318 {
      > 319         int exp, rnd;
        ......
      > 341         exp <<= MANTSIZE;
      > 342         exp += value;
      > 343         return exp;
      > 344 }
    
    Currently comp_t is defined as type of '__u16', but the variable 'exp' is
    type of 'int', so overflow would happen when variable 'exp' in line 343 is
    greater than 65535.
    
    Link: https://lkml.kernel.org/r/20210515140631.369106-3-zhengyejian1@huawei.com
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Cc: Hanjun Guo <guohanjun@huawei.com>
    Cc: Randy Dunlap <rdunlap@infradead.org>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Zhang Jinhao <zhangjinhao2@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ACPICA: Fix error code path in acpi_ds_call_control_method() [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon Nov 7 18:42:36 2022 +0100

    ACPICA: Fix error code path in acpi_ds_call_control_method()
    
    [ Upstream commit 404ec60438add1afadaffaed34bb5fe4ddcadd40 ]
    
    A use-after-free in acpi_ps_parse_aml() after a failing invocaion of
    acpi_ds_call_control_method() is reported by KASAN [1] and code
    inspection reveals that next_walk_state pushed to the thread by
    acpi_ds_create_walk_state() is freed on errors, but it is not popped
    from the thread beforehand.  Thus acpi_ds_get_current_walk_state()
    called by acpi_ps_parse_aml() subsequently returns it as the new
    walk state which is incorrect.
    
    To address this, make acpi_ds_call_control_method() call
    acpi_ds_pop_walk_state() to pop next_walk_state from the thread before
    returning an error.
    
    Link: https://lore.kernel.org/linux-acpi/20221019073443.248215-1-chenzhongjin@huawei.com/ # [1]
    Reported-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage() [+ + +]
Author: Li Zetao <lizetao1@huawei.com>
Date:   Thu Dec 1 16:05:14 2022 +0800

    ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()
    
    [ Upstream commit 470188b09e92d83c5a997f25f0e8fb8cd2bc3469 ]
    
    There is an use-after-free reported by KASAN:
    
      BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82
      Read of size 1 at addr ffff888112afc460 by task modprobe/2111
      CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
      Call Trace:
       <TASK>
       kasan_report+0xae/0xe0
       acpi_ut_remove_reference+0x3b/0x82
       acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5
       acpi_ds_store_object_to_local+0x15d/0x3a0
       acpi_ex_store+0x78d/0x7fd
       acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b
       acpi_ps_parse_aml+0x217/0x8d5
       ...
       </TASK>
    
    The root cause of the problem is that the acpi_operand_object
    is freed when acpi_ut_walk_package_tree() fails in
    acpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in
    acpi_ut_copy_iobject_to_iobject(). The problem was introduced
    by "8aa5e56eeb61" commit, this commit is to fix memory leak in
    acpi_ut_copy_iobject_to_iobject(), repeatedly adding remove
    operation, lead to "acpi_operand_object" used after free.
    
    Fix it by removing acpi_ut_remove_reference() in
    acpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage()
    is called to copy an internal package object into another internal
    package object, when it fails, the memory of acpi_operand_object
    should be freed by the caller.
    
    Fixes: 8aa5e56eeb61 ("ACPICA: Utilities: Fix memory leak in acpi_ut_copy_iobject_to_iobject")
    Signed-off-by: Li Zetao <lizetao1@huawei.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
alpha: fix syscall entry in !AUDUT_SYSCALL case [+ + +]
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Sep 18 18:18:48 2021 -0400

    alpha: fix syscall entry in !AUDUT_SYSCALL case
    
    [ Upstream commit f7b2431a6d22f7a91c567708e071dfcd6d66db14 ]
    
    We only want to take the slow path if SYSCALL_TRACE or SYSCALL_AUDIT is
    set; on !AUDIT_SYSCALL configs the current tree hits it whenever _any_
    thread flag (including NEED_RESCHED, NOTIFY_SIGNAL, etc.) happens to
    be set.
    
    Fixes: a9302e843944 "alpha: Enable system-call auditing support"
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA/ASoC: hda: move/rename snd_hdac_ext_stop_streams to hdac_stream.c [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Thu Dec 16 17:11:27 2021 -0600

    ALSA/ASoC: hda: move/rename snd_hdac_ext_stop_streams to hdac_stream.c
    
    [ Upstream commit 12054f0ce8be7d2003ec068ab27c9eb608397b98 ]
    
    snd_hdac_ext_stop_streams() has really nothing to do with the
    extension, it just loops over the bus streams.
    
    Move it to the hdac_stream layer and rename to remove the 'ext'
    prefix and add the precision that the chip will also be stopped.
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
    Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://lore.kernel.org/r/20211216231128.344321-2-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Stable-dep-of: 171107237246 ("ASoC: Intel: Skylake: Fix driver hang during shutdown")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: asihpi: fix missing pci_disable_device() [+ + +]
Author: Liu Shixin <liushixin2@huawei.com>
Date:   Sat Nov 26 10:14:29 2022 +0800

    ALSA: asihpi: fix missing pci_disable_device()
    
    [ Upstream commit 9d86515c3d4c0564a0c31a2df87d735353a1971e ]
    
    pci_disable_device() need be called while module exiting, switch to use
    pcim_enable(), pci_disable_device() will be called in pcim_release().
    
    Fixes: 3285ea10e9b0 ("ALSA: asihpi - Interrelated HPI tidy up.")
    Signed-off-by: Liu Shixin <liushixin2@huawei.com>
    Link: https://lore.kernel.org/r/20221126021429.3029562-1-liushixin2@huawei.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: hda/hdmi: Add a HP device 0x8715 to force connect list [+ + +]
Author: Adrian Chan <adchan@google.com>
Date:   Mon Jan 9 16:05:20 2023 -0500

    ALSA: hda/hdmi: Add a HP device 0x8715 to force connect list
    
    commit de1ccb9e61728dd941fe0e955a7a129418657267 upstream.
    
    Add the 'HP Engage Flex Mini' device to the force connect list to
    enable audio through HDMI.
    
    Signed-off-by: Adrian Chan <adchan@google.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20230109210520.16060-1-adchan@google.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/hdmi: Add HP Device 0x8711 to force connect list [+ + +]
Author: Jiao Zhou <jiaozhou@google.com>
Date:   Tue Dec 6 13:53:11 2022 -0500

    ALSA: hda/hdmi: Add HP Device 0x8711 to force connect list
    
    commit 31b573946ea55e1ea0e08ae8e83bcf879b30f83a upstream.
    
    HDMI audio is not working on the HP EliteDesk 800 G6 because the pin is
    unconnected. This issue can be resolved by using the 'hdajackretask'
    tool to override the unconnected pin to force it to connect.
    
    Signed-off-by: Jiao Zhou <jiaozhou@google.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20221206185311.3669950-1-jiaozhou@google.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Add quirk for Lenovo TianYi510Pro-14IOB [+ + +]
Author: Edward Pacman <edward@edward-p.xyz>
Date:   Wed Dec 7 21:32:18 2022 +0800

    ALSA: hda/realtek: Add quirk for Lenovo TianYi510Pro-14IOB
    
    commit 4bf5bf54476dffe60e6b6d8d539f67309ff599e2 upstream.
    
    Lenovo TianYi510Pro-14IOB (17aa:3742)
    require quirk for enabling headset-mic
    
    Signed-off-by: Edward Pacman <edward@edward-p.xyz>
    Cc: <stable@vger.kernel.org>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216756
    Link: https://lore.kernel.org/r/20221207133218.18989-1-edward@edward-p.xyz
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda: add snd_hdac_stop_streams() helper [+ + +]
Author: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Date:   Mon Sep 19 14:10:38 2022 +0200

    ALSA: hda: add snd_hdac_stop_streams() helper
    
    [ Upstream commit 24ad3835a6db4f8857975effa6bf47730371a5ff ]
    
    Minor code reuse, no functionality change.
    
    Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
    Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
    Link: https://lore.kernel.org/r/20220919121041.43463-6-pierre-louis.bossart@linux.intel.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Stable-dep-of: 171107237246 ("ASoC: Intel: Skylake: Fix driver hang during shutdown")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: line6: correct midi status byte when receiving data from podxt [+ + +]
Author: Artem Egorkine <arteme@gmail.com>
Date:   Sun Dec 25 12:57:27 2022 +0200

    ALSA: line6: correct midi status byte when receiving data from podxt
    
    commit 8508fa2e7472f673edbeedf1b1d2b7a6bb898ecc upstream.
    
    A PODxt device sends 0xb2, 0xc2 or 0xf2 as a status byte for MIDI
    messages over USB that should otherwise have a 0xb0, 0xc0 or 0xf0
    status byte. This is usually corrected by the driver on other OSes.
    
    This fixes MIDI sysex messages sent by PODxt.
    
    [ tiwai: fixed white spaces ]
    
    Signed-off-by: Artem Egorkine <arteme@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20221225105728.1153989-1-arteme@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: line6: fix stack overflow in line6_midi_transmit [+ + +]
Author: Artem Egorkine <arteme@gmail.com>
Date:   Sun Dec 25 12:57:28 2022 +0200

    ALSA: line6: fix stack overflow in line6_midi_transmit
    
    commit b8800d324abb50160560c636bfafe2c81001b66c upstream.
    
    Correctly calculate available space including the size of the chunk
    buffer. This fixes a buffer overflow when multiple MIDI sysex
    messages are sent to a PODxt device.
    
    Signed-off-by: Artem Egorkine <arteme@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20221225105728.1153989-2-arteme@gmail.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: mts64: fix possible null-ptr-defer in snd_mts64_interrupt [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Tue Dec 6 14:10:04 2022 +0800

    ALSA: mts64: fix possible null-ptr-defer in snd_mts64_interrupt
    
    [ Upstream commit cf2ea3c86ad90d63d1c572b43e1ca9276b0357ad ]
    
    I got a null-ptr-defer error report when I do the following tests
    on the qemu platform:
    
    make defconfig and CONFIG_PARPORT=m, CONFIG_PARPORT_PC=m,
    CONFIG_SND_MTS64=m
    
    Then making test scripts:
    cat>test_mod1.sh<<EOF
    modprobe snd-mts64
    modprobe snd-mts64
    EOF
    
    Executing the script, perhaps several times, we will get a null-ptr-defer
    report, as follow:
    
    syzkaller:~# ./test_mod.sh
    snd_mts64: probe of snd_mts64.0 failed with error -5
    modprobe: ERROR: could not insert 'snd_mts64': No such device
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     #PF: supervisor write access in kernel mode
     #PF: error_code(0x0002) - not-present page
     PGD 0 P4D 0
     Oops: 0002 [#1] PREEMPT SMP PTI
     CPU: 0 PID: 205 Comm: modprobe Not tainted 6.1.0-rc8-00588-g76dcd734eca2 #6
     Call Trace:
      <IRQ>
      snd_mts64_interrupt+0x24/0xa0 [snd_mts64]
      parport_irq_handler+0x37/0x50 [parport]
      __handle_irq_event_percpu+0x39/0x190
      handle_irq_event_percpu+0xa/0x30
      handle_irq_event+0x2f/0x50
      handle_edge_irq+0x99/0x1b0
      __common_interrupt+0x5d/0x100
      common_interrupt+0xa0/0xc0
      </IRQ>
      <TASK>
      asm_common_interrupt+0x22/0x40
     RIP: 0010:_raw_write_unlock_irqrestore+0x11/0x30
      parport_claim+0xbd/0x230 [parport]
      snd_mts64_probe+0x14a/0x465 [snd_mts64]
      platform_probe+0x3f/0xa0
      really_probe+0x129/0x2c0
      __driver_probe_device+0x6d/0xc0
      driver_probe_device+0x1a/0xa0
      __device_attach_driver+0x7a/0xb0
      bus_for_each_drv+0x62/0xb0
      __device_attach+0xe4/0x180
      bus_probe_device+0x82/0xa0
      device_add+0x550/0x920
      platform_device_add+0x106/0x220
      snd_mts64_attach+0x2e/0x80 [snd_mts64]
      port_check+0x14/0x20 [parport]
      bus_for_each_dev+0x6e/0xc0
      __parport_register_driver+0x7c/0xb0 [parport]
      snd_mts64_module_init+0x31/0x1000 [snd_mts64]
      do_one_initcall+0x3c/0x1f0
      do_init_module+0x46/0x1c6
      load_module+0x1d8d/0x1e10
      __do_sys_finit_module+0xa2/0xf0
      do_syscall_64+0x37/0x90
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      </TASK>
     Kernel panic - not syncing: Fatal exception in interrupt
     Rebooting in 1 seconds..
    
    The mts wa not initialized during interrupt,  we add check for
    mts to fix this bug.
    
    Fixes: 68ab801e32bb ("[ALSA] Add snd-mts64 driver for ESI Miditerminal 4140")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221206061004.1222966-1-cuigaosheng1@huawei.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: pcm: fix undefined behavior in bit shift for SNDRV_PCM_RATE_KNOT [+ + +]
Author: Baisong Zhong <zhongbaisong@huawei.com>
Date:   Mon Nov 21 19:00:44 2022 +0800

    ALSA: pcm: fix undefined behavior in bit shift for SNDRV_PCM_RATE_KNOT
    
    [ Upstream commit b5172e62458f8e6ff359e5f096044a488db90ac5 ]
    
    Shifting signed 32-bit value by 31 bits is undefined, so changing
    significant bit to unsigned. The UBSAN warning calltrace like below:
    
    UBSAN: shift-out-of-bounds in sound/core/pcm_native.c:2676:21
    left shift of 1 by 31 places cannot be represented in type 'int'
    ...
    Call Trace:
     <TASK>
     dump_stack_lvl+0x8d/0xcf
     ubsan_epilogue+0xa/0x44
     __ubsan_handle_shift_out_of_bounds+0x1e7/0x208
     snd_pcm_open_substream+0x9f0/0xa90
     snd_pcm_oss_open.part.26+0x313/0x670
     snd_pcm_oss_open+0x30/0x40
     soundcore_open+0x18b/0x2e0
     chrdev_open+0xe2/0x270
     do_dentry_open+0x2f7/0x620
     path_openat+0xd66/0xe70
     do_filp_open+0xe3/0x170
     do_sys_openat2+0x357/0x4a0
     do_sys_open+0x87/0xd0
     do_syscall_64+0x34/0x80
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com>
    Link: https://lore.kernel.org/r/20221121110044.3115686-1-zhongbaisong@huawei.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: pcm: Move rwsem lock inside snd_ctl_elem_read to prevent UAF [+ + +]
Author: Clement Lecigne <clecigne@google.com>
Date:   Fri Jan 13 13:07:45 2023 +0100

    ALSA: pcm: Move rwsem lock inside snd_ctl_elem_read to prevent UAF
    
    [ Note: this is a fix that works around the bug equivalently as the
      two upstream commits:
       1fa4445f9adf ("ALSA: control - introduce snd_ctl_notify_one() helper")
       56b88b50565c ("ALSA: pcm: Move rwsem lock inside snd_ctl_elem_read to prevent UAF")
      but in a simpler way to fit with older stable trees -- tiwai ]
    
    Add missing locking in ctl_elem_read_user/ctl_elem_write_user which can be
    easily triggered and turned into an use-after-free.
    
    Example code paths with SNDRV_CTL_IOCTL_ELEM_READ:
    
    64-bits:
    snd_ctl_ioctl
      snd_ctl_elem_read_user
        [takes controls_rwsem]
        snd_ctl_elem_read [lock properly held, all good]
        [drops controls_rwsem]
    
    32-bits (compat):
    snd_ctl_ioctl_compat
      snd_ctl_elem_write_read_compat
        ctl_elem_write_read
          snd_ctl_elem_read [missing lock, not good]
    
    CVE-2023-0266 was assigned for this issue.
    
    Signed-off-by: Clement Lecigne <clecigne@google.com>
    Cc: stable@kernel.org # 5.12 and older
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Reviewed-by: Jaroslav Kysela <perex@perex.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: seq: fix undefined behavior in bit shift for SNDRV_SEQ_FILTER_USE_EVENT [+ + +]
Author: Baisong Zhong <zhongbaisong@huawei.com>
Date:   Mon Nov 21 19:16:30 2022 +0800

    ALSA: seq: fix undefined behavior in bit shift for SNDRV_SEQ_FILTER_USE_EVENT
    
    [ Upstream commit cf59e1e4c79bf741905484cdb13c130b53576a16 ]
    
    Shifting signed 32-bit value by 31 bits is undefined, so changing
    significant bit to unsigned. The UBSAN warning calltrace like below:
    
    UBSAN: shift-out-of-bounds in sound/core/seq/seq_clientmgr.c:509:22
    left shift of 1 by 31 places cannot be represented in type 'int'
    ...
    Call Trace:
     <TASK>
     dump_stack_lvl+0x8d/0xcf
     ubsan_epilogue+0xa/0x44
     __ubsan_handle_shift_out_of_bounds+0x1e7/0x208
     snd_seq_deliver_single_event.constprop.21+0x191/0x2f0
     snd_seq_deliver_event+0x1a2/0x350
     snd_seq_kernel_client_dispatch+0x8b/0xb0
     snd_seq_client_notify_subscription+0x72/0xa0
     snd_seq_ioctl_subscribe_port+0x128/0x160
     snd_seq_kernel_client_ctl+0xce/0xf0
     snd_seq_oss_create_client+0x109/0x15b
     alsa_seq_oss_init+0x11c/0x1aa
     do_one_initcall+0x80/0x440
     kernel_init_freeable+0x370/0x3c3
     kernel_init+0x1b/0x190
     ret_from_fork+0x1f/0x30
     </TASK>
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com>
    Link: https://lore.kernel.org/r/20221121111630.3119259-1-zhongbaisong@huawei.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
amdgpu/pm: prevent array underflow in vega20_odn_edit_dpm_table() [+ + +]
Author: Dan Carpenter <error27@gmail.com>
Date:   Tue Nov 15 15:56:57 2022 +0300

    amdgpu/pm: prevent array underflow in vega20_odn_edit_dpm_table()
    
    [ Upstream commit d27252b5706e51188aed7647126e44dcf9e940c1 ]
    
    In the PP_OD_EDIT_VDDC_CURVE case the "input_index" variable is capped at
    2 but not checked for negative values so it results in an out of bounds
    read.  This value comes from the user via sysfs.
    
    Fixes: d5bf26539494 ("drm/amd/powerplay: added vega20 overdrive support V3")
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
apparmor: fix a memleak in multi_transaction_new() [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Tue Aug 23 09:15:03 2022 +0800

    apparmor: fix a memleak in multi_transaction_new()
    
    [ Upstream commit c73275cf6834787ca090317f1d20dbfa3b7f05aa ]
    
    In multi_transaction_new(), the variable t is not freed or passed out
    on the failure of copy_from_user(t->data, buf, size), which could lead
    to a memleak.
    
    Fix this bug by adding a put_multi_transaction(t) in the error path.
    
    Fixes: 1dea3b41e84c5 ("apparmor: speed up transactional queries")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

apparmor: Fix abi check to include v8 abi [+ + +]
Author: John Johansen <john.johansen@canonical.com>
Date:   Fri May 6 18:57:12 2022 -0700

    apparmor: Fix abi check to include v8 abi
    
    [ Upstream commit 1b5a6198f5a9d0aa5497da0dc4bcd4fc166ee516 ]
    
    The v8 abi is supported by the kernel but the userspace supported
    version check does not allow for it. This was missed when v8 was added
    due to a bug in the userspace compiler which was setting an older abi
    version for v8 encoding (which is forward compatible except on the
    network encoding). However it is possible to detect the network
    encoding by checking the policydb network support which the code
    does. The end result was that missing the abi flag worked until
    userspace was fixed and began correctly checking for the v8 abi
    version.
    
    Fixes: 56974a6fcfef ("apparmor: add base infastructure for socket mediation")
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

apparmor: fix lockdep warning when removing a namespace [+ + +]
Author: John Johansen <john.johansen@canonical.com>
Date:   Tue Sep 6 03:39:55 2022 -0700

    apparmor: fix lockdep warning when removing a namespace
    
    [ Upstream commit 9c4557efc558a68e4cd973490fd936d6e3414db8 ]
    
    Fix the following lockdep warning
    
    [ 1119.158984] ============================================
    [ 1119.158988] WARNING: possible recursive locking detected
    [ 1119.158996] 6.0.0-rc1+ #257 Tainted: G            E    N
    [ 1119.158999] --------------------------------------------
    [ 1119.159001] bash/80100 is trying to acquire lock:
    [ 1119.159007] ffff88803e79b4a0 (&ns->lock/1){+.+.}-{4:4}, at: destroy_ns.part.0+0x43/0x140
    [ 1119.159028]
                   but task is already holding lock:
    [ 1119.159030] ffff8881009764a0 (&ns->lock/1){+.+.}-{4:4}, at: aa_remove_profiles+0x3f0/0x640
    [ 1119.159040]
                   other info that might help us debug this:
    [ 1119.159042]  Possible unsafe locking scenario:
    
    [ 1119.159043]        CPU0
    [ 1119.159045]        ----
    [ 1119.159047]   lock(&ns->lock/1);
    [ 1119.159051]   lock(&ns->lock/1);
    [ 1119.159055]
                    *** DEADLOCK ***
    
    Which is caused by an incorrect lockdep nesting notation
    
    Fixes: feb3c766a3ab ("apparmor: fix possible recursive lock warning in __aa_create_ns")
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

apparmor: Use pointer to struct aa_label for lbs_cred [+ + +]
Author: Xiu Jianfeng <xiujianfeng@huawei.com>
Date:   Fri Oct 21 08:46:04 2022 +0800

    apparmor: Use pointer to struct aa_label for lbs_cred
    
    [ Upstream commit 37923d4321b1e38170086da2c117f78f2b0f49c6 ]
    
    According to the implementations of cred_label() and set_cred_label(),
    we should use pointer to struct aa_label for lbs_cred instead of struct
    aa_task_ctx, this patch fixes it.
    
    Fixes: bbd3662a8348 ("Infrastructure management of the cred security blob")
    Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm64: atomics: format whitespace consistently [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri Dec 10 15:14:06 2021 +0000

    arm64: atomics: format whitespace consistently
    
    [ Upstream commit 8e6082e94aac6d0338883b5953631b662a5a9188 ]
    
    The code for the atomic ops is formatted inconsistently, and while this
    is not a functional problem it is rather distracting when working on
    them.
    
    Some have ops have consistent indentation, e.g.
    
    | #define ATOMIC_OP_ADD_RETURN(name, mb, cl...)                           \
    | static inline int __lse_atomic_add_return##name(int i, atomic_t *v)     \
    | {                                                                       \
    |         u32 tmp;                                                        \
    |                                                                         \
    |         asm volatile(                                                   \
    |         __LSE_PREAMBLE                                                  \
    |         "       ldadd" #mb "    %w[i], %w[tmp], %[v]\n"                 \
    |         "       add     %w[i], %w[i], %w[tmp]"                          \
    |         : [i] "+r" (i), [v] "+Q" (v->counter), [tmp] "=&r" (tmp)        \
    |         : "r" (v)                                                       \
    |         : cl);                                                          \
    |                                                                         \
    |         return i;                                                       \
    | }
    
    While others have negative indentation for some lines, and/or have
    misaligned trailing backslashes, e.g.
    
    | static inline void __lse_atomic_##op(int i, atomic_t *v)                        \
    | {                                                                       \
    |         asm volatile(                                                   \
    |         __LSE_PREAMBLE                                                  \
    | "       " #asm_op "     %w[i], %[v]\n"                                  \
    |         : [i] "+r" (i), [v] "+Q" (v->counter)                           \
    |         : "r" (v));                                                     \
    | }
    
    This patch makes the indentation consistent and also aligns the trailing
    backslashes. This makes the code easier to read for those (like myself)
    who are easily distracted by these inconsistencies.
    
    This is intended as a cleanup.
    There should be no functional change as a result of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Boqun Feng <boqun.feng@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Will Deacon <will@kernel.org>
    Acked-by: Will Deacon <will@kernel.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20211210151410.2782645-2-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Stable-dep-of: 031af50045ea ("arm64: cmpxchg_double*: hazard against entire exchange variable")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: atomics: remove LL/SC trampolines [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Aug 17 16:59:13 2022 +0100

    arm64: atomics: remove LL/SC trampolines
    
    [ Upstream commit b2c3ccbd0011bb3b51d0fec24cb3a5812b1ec8ea ]
    
    When CONFIG_ARM64_LSE_ATOMICS=y, each use of an LL/SC atomic results in
    a fragment of code being generated in a subsection without a clear
    association with its caller. A trampoline in the caller branches to the
    LL/SC atomic with with a direct branch, and the atomic directly branches
    back into its trampoline.
    
    This breaks backtracing, as any PC within the out-of-line fragment will
    be symbolized as an offset from the nearest prior symbol (which may not
    be the function using the atomic), and since the atomic returns with a
    direct branch, the caller's PC may be missing from the backtrace.
    
    For example, with secondary_start_kernel() hacked to contain
    atomic_inc(NULL), the resulting exception can be reported as being taken
    from cpus_are_stuck_in_kernel():
    
    | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    | Mem abort info:
    |   ESR = 0x0000000096000004
    |   EC = 0x25: DABT (current EL), IL = 32 bits
    |   SET = 0, FnV = 0
    |   EA = 0, S1PTW = 0
    |   FSC = 0x04: level 0 translation fault
    | Data abort info:
    |   ISV = 0, ISS = 0x00000004
    |   CM = 0, WnR = 0
    | [0000000000000000] user address but active_mm is swapper
    | Internal error: Oops: 96000004 [#1] PREEMPT SMP
    | Modules linked in:
    | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.19.0-11219-geb555cb5b794-dirty #3
    | Hardware name: linux,dummy-virt (DT)
    | pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    | pc : cpus_are_stuck_in_kernel+0xa4/0x120
    | lr : secondary_start_kernel+0x164/0x170
    | sp : ffff80000a4cbe90
    | x29: ffff80000a4cbe90 x28: 0000000000000000 x27: 0000000000000000
    | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
    | x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000
    | x20: 0000000000000001 x19: 0000000000000001 x18: 0000000000000008
    | x17: 3030383832343030 x16: 3030303030307830 x15: ffff80000a4cbab0
    | x14: 0000000000000001 x13: 5d31666130663133 x12: 3478305b20313030
    | x11: 3030303030303078 x10: 3020726f73736563 x9 : 726f737365636f72
    | x8 : ffff800009ff2ef0 x7 : 0000000000000003 x6 : 0000000000000000
    | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000100
    | x2 : 0000000000000000 x1 : ffff0000029bd880 x0 : 0000000000000000
    | Call trace:
    |  cpus_are_stuck_in_kernel+0xa4/0x120
    |  __secondary_switched+0xb0/0xb4
    | Code: 35ffffa3 17fffc6c d53cd040 f9800011 (885f7c01)
    | ---[ end trace 0000000000000000 ]---
    
    This is confusing and hinders debugging, and will be problematic for
    CONFIG_LIVEPATCH as these cases cannot be unwound reliably.
    
    This is very similar to recent issues with out-of-line exception fixups,
    which were removed in commits:
    
      35d67794b8828333 ("arm64: lib: __arch_clear_user(): fold fixups into body")
      4012e0e22739eef9 ("arm64: lib: __arch_copy_from_user(): fold fixups into body")
      139f9ab73d60cf76 ("arm64: lib: __arch_copy_to_user(): fold fixups into body")
    
    When the trampolines were introduced in commit:
    
      addfc38672c73efd ("arm64: atomics: avoid out-of-line ll/sc atomics")
    
    The rationale was to improve icache performance by grouping the LL/SC
    atomics together. This has never been measured, and this theoretical
    benefit is outweighed by other factors:
    
    * As the subsections are collapsed into sections at object file
      granularity, these are spread out throughout the kernel and can share
      cachelines with unrelated code regardless.
    
    * GCC 12.1.0 has been observed to place the trampoline out-of-line in
      specialised __ll_sc_*() functions, introducing more branching than was
      intended.
    
    * Removing the trampolines has been observed to shrink a defconfig
      kernel Image by 64KiB when building with GCC 12.1.0.
    
    This patch removes the LL/SC trampolines, meaning that the LL/SC atomics
    will be inlined into their callers (or placed in out-of line functions
    using regular BL/RET pairs). When CONFIG_ARM64_LSE_ATOMICS=y, the LL/SC
    atomics are always called in an unlikely branch, and will be placed in a
    cold portion of the function, so this should have minimal impact to the
    hot paths.
    
    Other than the improved backtracing, there should be no functional
    change as a result of this patch.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20220817155914.3975112-2-mark.rutland@arm.com
    Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
    Stable-dep-of: 031af50045ea ("arm64: cmpxchg_double*: hazard against entire exchange variable")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: cmpxchg_double*: hazard against entire exchange variable [+ + +]
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Wed Jan 4 15:16:26 2023 +0000

    arm64: cmpxchg_double*: hazard against entire exchange variable
    
    [ Upstream commit 031af50045ea97ed4386eb3751ca2c134d0fc911 ]
    
    The inline assembly for arm64's cmpxchg_double*() implementations use a
    +Q constraint to hazard against other accesses to the memory location
    being exchanged. However, the pointer passed to the constraint is a
    pointer to unsigned long, and thus the hazard only applies to the first
    8 bytes of the location.
    
    GCC can take advantage of this, assuming that other portions of the
    location are unchanged, leading to a number of potential problems.
    
    This is similar to what we fixed back in commit:
    
      fee960bed5e857eb ("arm64: xchg: hazard against entire exchange variable")
    
    ... but we forgot to adjust cmpxchg_double*() similarly at the same
    time.
    
    The same problem applies, as demonstrated with the following test:
    
    | struct big {
    |         u64 lo, hi;
    | } __aligned(128);
    |
    | unsigned long foo(struct big *b)
    | {
    |         u64 hi_old, hi_new;
    |
    |         hi_old = b->hi;
    |         cmpxchg_double_local(&b->lo, &b->hi, 0x12, 0x34, 0x56, 0x78);
    |         hi_new = b->hi;
    |
    |         return hi_old ^ hi_new;
    | }
    
    ... which GCC 12.1.0 compiles as:
    
    | 0000000000000000 <foo>:
    |    0:   d503233f        paciasp
    |    4:   aa0003e4        mov     x4, x0
    |    8:   1400000e        b       40 <foo+0x40>
    |    c:   d2800240        mov     x0, #0x12                       // #18
    |   10:   d2800681        mov     x1, #0x34                       // #52
    |   14:   aa0003e5        mov     x5, x0
    |   18:   aa0103e6        mov     x6, x1
    |   1c:   d2800ac2        mov     x2, #0x56                       // #86
    |   20:   d2800f03        mov     x3, #0x78                       // #120
    |   24:   48207c82        casp    x0, x1, x2, x3, [x4]
    |   28:   ca050000        eor     x0, x0, x5
    |   2c:   ca060021        eor     x1, x1, x6
    |   30:   aa010000        orr     x0, x0, x1
    |   34:   d2800000        mov     x0, #0x0                        // #0    <--- BANG
    |   38:   d50323bf        autiasp
    |   3c:   d65f03c0        ret
    |   40:   d2800240        mov     x0, #0x12                       // #18
    |   44:   d2800681        mov     x1, #0x34                       // #52
    |   48:   d2800ac2        mov     x2, #0x56                       // #86
    |   4c:   d2800f03        mov     x3, #0x78                       // #120
    |   50:   f9800091        prfm    pstl1strm, [x4]
    |   54:   c87f1885        ldxp    x5, x6, [x4]
    |   58:   ca0000a5        eor     x5, x5, x0
    |   5c:   ca0100c6        eor     x6, x6, x1
    |   60:   aa0600a6        orr     x6, x5, x6
    |   64:   b5000066        cbnz    x6, 70 <foo+0x70>
    |   68:   c8250c82        stxp    w5, x2, x3, [x4]
    |   6c:   35ffff45        cbnz    w5, 54 <foo+0x54>
    |   70:   d2800000        mov     x0, #0x0                        // #0     <--- BANG
    |   74:   d50323bf        autiasp
    |   78:   d65f03c0        ret
    
    Notice that at the lines with "BANG" comments, GCC has assumed that the
    higher 8 bytes are unchanged by the cmpxchg_double() call, and that
    `hi_old ^ hi_new` can be reduced to a constant zero, for both LSE and
    LL/SC versions of cmpxchg_double().
    
    This patch fixes the issue by passing a pointer to __uint128_t into the
    +Q constraint, ensuring that the compiler hazards against the entire 16
    bytes being modified.
    
    With this change, GCC 12.1.0 compiles the above test as:
    
    | 0000000000000000 <foo>:
    |    0:   f9400407        ldr     x7, [x0, #8]
    |    4:   d503233f        paciasp
    |    8:   aa0003e4        mov     x4, x0
    |    c:   1400000f        b       48 <foo+0x48>
    |   10:   d2800240        mov     x0, #0x12                       // #18
    |   14:   d2800681        mov     x1, #0x34                       // #52
    |   18:   aa0003e5        mov     x5, x0
    |   1c:   aa0103e6        mov     x6, x1
    |   20:   d2800ac2        mov     x2, #0x56                       // #86
    |   24:   d2800f03        mov     x3, #0x78                       // #120
    |   28:   48207c82        casp    x0, x1, x2, x3, [x4]
    |   2c:   ca050000        eor     x0, x0, x5
    |   30:   ca060021        eor     x1, x1, x6
    |   34:   aa010000        orr     x0, x0, x1
    |   38:   f9400480        ldr     x0, [x4, #8]
    |   3c:   d50323bf        autiasp
    |   40:   ca0000e0        eor     x0, x7, x0
    |   44:   d65f03c0        ret
    |   48:   d2800240        mov     x0, #0x12                       // #18
    |   4c:   d2800681        mov     x1, #0x34                       // #52
    |   50:   d2800ac2        mov     x2, #0x56                       // #86
    |   54:   d2800f03        mov     x3, #0x78                       // #120
    |   58:   f9800091        prfm    pstl1strm, [x4]
    |   5c:   c87f1885        ldxp    x5, x6, [x4]
    |   60:   ca0000a5        eor     x5, x5, x0
    |   64:   ca0100c6        eor     x6, x6, x1
    |   68:   aa0600a6        orr     x6, x5, x6
    |   6c:   b5000066        cbnz    x6, 78 <foo+0x78>
    |   70:   c8250c82        stxp    w5, x2, x3, [x4]
    |   74:   35ffff45        cbnz    w5, 5c <foo+0x5c>
    |   78:   f9400480        ldr     x0, [x4, #8]
    |   7c:   d50323bf        autiasp
    |   80:   ca0000e0        eor     x0, x7, x0
    |   84:   d65f03c0        ret
    
    ... sampling the high 8 bytes before and after the cmpxchg, and
    performing an EOR, as we'd expect.
    
    For backporting, I've tested this atop linux-4.9.y with GCC 5.5.0. Note
    that linux-4.9.y is oldest currently supported stable release, and
    mandates GCC 5.1+. Unfortunately I couldn't get a GCC 5.1 binary to run
    on my machines due to library incompatibilities.
    
    I've also used a standalone test to check that we can use a __uint128_t
    pointer in a +Q constraint at least as far back as GCC 4.8.5 and LLVM
    3.9.1.
    
    Fixes: 5284e1b4bc8a ("arm64: xchg: Implement cmpxchg_double")
    Fixes: e9a4b795652f ("arm64: cmpxchg_dbl: patch in lse instructions when supported by the CPU")
    Reported-by: Boqun Feng <boqun.feng@gmail.com>
    Link: https://lore.kernel.org/lkml/Y6DEfQXymYVgL3oJ@boqun-archlinux/
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/lkml/Y6GXoO4qmH9OIZ5Q@hirez.programming.kicks-ass.net/
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Cc: stable@vger.kernel.org
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Steve Capper <steve.capper@arm.com>
    Cc: Will Deacon <will@kernel.org>
    Link: https://lore.kernel.org/r/20230104151626.3262137-1-mark.rutland@arm.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: armada-3720-turris-mox: Add missing interrupt for RTC [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Sat Sep 24 13:58:26 2022 +0200

    arm64: dts: armada-3720-turris-mox: Add missing interrupt for RTC
    
    [ Upstream commit 21aad8ba615e9c39cee6c5d0b76726f63791926c ]
    
    MCP7940MT-I/MNY RTC has connected interrupt line to GPIO2_5.
    
    Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mediatek: mt6797: Fix 26M oscillator unit name [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Oct 13 17:22:12 2022 +0200

    arm64: dts: mediatek: mt6797: Fix 26M oscillator unit name
    
    [ Upstream commit 5f535cc583759c9c60d4cc9b8d221762e2d75387 ]
    
    Update its unit name to oscillator-26m and remove the unneeded unit
    address to fix a unit_address_vs_reg warning.
    
    Fixes: 464c510f60c6 ("arm64: dts: mediatek: add mt6797 support")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20221013152212.416661-9-angelogioacchino.delregno@collabora.com
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mt2712-evb: Fix usb vbus regulators unit names [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Oct 13 17:22:10 2022 +0200

    arm64: dts: mt2712-evb: Fix usb vbus regulators unit names
    
    [ Upstream commit ec1ae39a8d25cfb067b5459fac7c5b7b9bce6f6a ]
    
    Update the names to regulator-usb-p{0-3}-vbus to fix unit_address_vs_reg
    warnings for those.
    
    Fixes: 1724f4cc5133 ("arm64: dts: Add USB3 related nodes for MT2712")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20221013152212.416661-7-angelogioacchino.delregno@collabora.com
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mt2712-evb: Fix vproc fixed regulators unit names [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Oct 13 17:22:09 2022 +0200

    arm64: dts: mt2712-evb: Fix vproc fixed regulators unit names
    
    [ Upstream commit 377063156893bf6c088309ac799fe5c6dce2822d ]
    
    Update the names to regulator-vproc-buck{0,1} to fix unit_addres_vs_reg
    warnings for those.
    
    Fixes: f75dd8bdd344 ("arm64: dts: mediatek: add mt2712 cpufreq related device nodes")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20221013152212.416661-6-angelogioacchino.delregno@collabora.com
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mt2712e: Fix unit address for pinctrl node [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Oct 13 17:22:08 2022 +0200

    arm64: dts: mt2712e: Fix unit address for pinctrl node
    
    [ Upstream commit 1d4516f53a611b362db7ba7a8889923d469f57e1 ]
    
    The unit address for the pinctrl node is (0x)1000b000 and not
    (0x)10005000, which is the syscfg_pctl_a address instead.
    
    This fixes the following warning:
    arch/arm64/boot/dts/mediatek/mt2712e.dtsi:264.40-267.4: Warning
    (unique_unit_address): /syscfg_pctl_a@10005000: duplicate
    unit-address (also used in node /pinctrl@10005000)
    
    Fixes: f0c64340b748 ("arm64: dts: mt2712: add pintcrl device node.")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20221013152212.416661-5-angelogioacchino.delregno@collabora.com
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: mt2712e: Fix unit_address_vs_reg warning for oscillators [+ + +]
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Date:   Thu Oct 13 17:22:07 2022 +0200

    arm64: dts: mt2712e: Fix unit_address_vs_reg warning for oscillators
    
    [ Upstream commit e4495a0a8b3d84816c9a46edf3ce060bbf267475 ]
    
    Rename the fixed-clock oscillators to remove the unit address.
    
    This solves unit_address_vs_reg warnings.
    
    Fixes: 5d4839709c8e ("arm64: dts: mt2712: Add clock controller device nodes")
    Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Link: https://lore.kernel.org/r/20221013152212.416661-4-angelogioacchino.delregno@collabora.com
    Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm845-cheza: fix AP suspend pin bias [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Mon Oct 10 07:44:14 2022 -0400

    arm64: dts: qcom: sdm845-cheza: fix AP suspend pin bias
    
    [ Upstream commit 9bce41fab14da8f21027dc9847535ef5e22cbe8b ]
    
    There is no "bias-no-pull" property.  Assume intentions were disabling
    bias.
    
    Fixes: 79e7739f7b87 ("arm64: dts: qcom: sdm845-cheza: add initial cheza dt")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221010114417.29859-3-krzysztof.kozlowski@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sdm850-lenovo-yoga-c630: correct I2C12 pins drive strength [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Fri Sep 30 21:20:37 2022 +0200

    arm64: dts: qcom: sdm850-lenovo-yoga-c630: correct I2C12 pins drive strength
    
    commit fd49776d8f458bba5499384131eddc0b8bcaf50c upstream.
    
    The pin configuration (done with generic pin controller helpers and
    as expressed by bindings) requires children nodes with either:
    1. "pins" property and the actual configuration,
    2. another set of nodes with above point.
    
    The qup_i2c12_default pin configuration used second method - with a
    "pinmux" child.
    
    Fixes: 44acee207844 ("arm64: dts: qcom: Add Lenovo Yoga C630")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Tested-by: Steev Klimaszewski <steev@kali.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20220930192039.240486-1-krzysztof.kozlowski@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ARM: 9256/1: NWFPE: avoid compiler-generated __aeabi_uldivmod [+ + +]
Author: Nick Desaulniers <ndesaulniers@google.com>
Date:   Tue Oct 11 20:00:12 2022 +0100

    ARM: 9256/1: NWFPE: avoid compiler-generated __aeabi_uldivmod
    
    commit 3220022038b9a3845eea762af85f1c5694b9f861 upstream.
    
    clang-15's ability to elide loops completely became more aggressive when
    it can deduce how a variable is being updated in a loop. Counting down
    one variable by an increment of another can be replaced by a modulo
    operation.
    
    For 64b variables on 32b ARM EABI targets, this can result in the
    compiler generating calls to __aeabi_uldivmod, which it does for a do
    while loop in float64_rem().
    
    For the kernel, we'd generally prefer that developers not open code 64b
    division via binary / operators and instead use the more explicit
    helpers from div64.h. On arm-linux-gnuabi targets, failure to do so can
    result in linkage failures due to undefined references to
    __aeabi_uldivmod().
    
    While developers can avoid open coding divisions on 64b variables, the
    compiler doesn't know that the Linux kernel has a partial implementation
    of a compiler runtime (--rtlib) to enforce this convention.
    
    It's also undecidable for the compiler whether the code in question
    would be faster to execute the loop vs elide it and do the 64b division.
    
    While I actively avoid using the internal -mllvm command line flags, I
    think we get better code than using barrier() here, which will force
    reloads+spills in the loop for all toolchains.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1666
    
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ARM: dts: armada-370: Fix assigned-addresses for every PCIe Root Port [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Aug 18 00:30:49 2022 +0200

    ARM: dts: armada-370: Fix assigned-addresses for every PCIe Root Port
    
    [ Upstream commit d9208b0fa2e803d16b28d91bf1d46b7ee9ea13c6 ]
    
    BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port
    (PCI-to-PCI bridge) should match BDF in address part in that DT node name
    as specified resource belongs to Marvell PCIe Root Port itself.
    
    Fixes: a09a0b7c6ff1 ("arm: mvebu: add PCIe Device Tree informations for Armada 370")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: armada-375: Fix assigned-addresses for every PCIe Root Port [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Aug 18 00:30:51 2022 +0200

    ARM: dts: armada-375: Fix assigned-addresses for every PCIe Root Port
    
    [ Upstream commit 823956d2436f70ced74c0fe8ab99facd8abfc060 ]
    
    BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port
    (PCI-to-PCI bridge) should match BDF in address part in that DT node name
    as specified resource belongs to Marvell PCIe Root Port itself.
    
    Fixes: 4de59085091f ("ARM: mvebu: add Device Tree description of the Armada 375 SoC")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: armada-38x: Fix assigned-addresses for every PCIe Root Port [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Aug 18 00:30:52 2022 +0200

    ARM: dts: armada-38x: Fix assigned-addresses for every PCIe Root Port
    
    [ Upstream commit 44f47b7a8fa4678ce4c38ea74837e4996b9df6d6 ]
    
    BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port
    (PCI-to-PCI bridge) should match BDF in address part in that DT node name
    as specified resource belongs to Marvell PCIe Root Port itself.
    
    Fixes: 0d3d96ab0059 ("ARM: mvebu: add Device Tree description of the Armada 380/385 SoCs")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: armada-39x: Fix assigned-addresses for every PCIe Root Port [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Aug 18 00:30:53 2022 +0200

    ARM: dts: armada-39x: Fix assigned-addresses for every PCIe Root Port
    
    [ Upstream commit 69236d2391b4d7324b11c3252921571577892e7b ]
    
    BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port
    (PCI-to-PCI bridge) should match BDF in address part in that DT node name
    as specified resource belongs to Marvell PCIe Root Port itself.
    
    Fixes: 538da83ddbea ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: armada-xp: Fix assigned-addresses for every PCIe Root Port [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Aug 18 00:30:50 2022 +0200

    ARM: dts: armada-xp: Fix assigned-addresses for every PCIe Root Port
    
    [ Upstream commit eab276787f456cbea89fabea110fe0728673d308 ]
    
    BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port
    (PCI-to-PCI bridge) should match BDF in address part in that DT node name
    as specified resource belongs to Marvell PCIe Root Port itself.
    
    Fixes: 9d8f44f02d4a ("arm: mvebu: add PCIe Device Tree informations for Armada XP")
    Fixes: 12b69a599745 ("ARM: mvebu: second PCIe unit of Armada XP mv78230 is only x1 capable")
    Fixes: 2163e61c92d9 ("ARM: mvebu: fix second and third PCIe unit of Armada XP mv78260")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: dove: Fix assigned-addresses for every PCIe Root Port [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Aug 18 00:30:48 2022 +0200

    ARM: dts: dove: Fix assigned-addresses for every PCIe Root Port
    
    [ Upstream commit dcc7d8c72b64a479b8017e4332d99179deb8802d ]
    
    BDF of resource in DT assigned-addresses property of Marvell PCIe Root Port
    (PCI-to-PCI bridge) should match BDF in address part in that DT node name
    as specified resource belongs to Marvell PCIe Root Port itself.
    
    Fixes: 74ecaa403a74 ("ARM: dove: add PCIe controllers to SoC DT")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: apq8064: fix coresight compatible [+ + +]
Author: Luca Weiss <luca@z3ntu.xyz>
Date:   Thu Oct 13 21:06:57 2022 +0200

    ARM: dts: qcom: apq8064: fix coresight compatible
    
    [ Upstream commit a42b1ee868361f1cb0492f1bdaefb43e0751e468 ]
    
    There's a typo missing the arm, prefix of arm,coresight-etb10. Fix it to
    make devicetree validation happier.
    
    Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
    Fixes: 7a5c275fd821 ("ARM: dts: qcom: Add apq8064 CoreSight components")
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221013190657.48499-3-luca@z3ntu.xyz
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm: dts: spear600: Fix clcd interrupt [+ + +]
Author: Kory Maincent <kory.maincent@bootlin.com>
Date:   Wed Nov 2 18:10:06 2022 +0100

    arm: dts: spear600: Fix clcd interrupt
    
    [ Upstream commit 0336e2ce34e7a89832b6c214f924eb7bc58940be ]
    
    Interrupt 12 of the Interrupt controller belongs to the SMI controller,
    the right one for the display controller is the interrupt 13.
    
    Fixes: 8113ba917dfa ("ARM: SPEAr: DT: Update device nodes")
    Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: dts: turris-omnia: Add ethernet aliases [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Wed Jul 27 15:09:26 2022 +0200

    ARM: dts: turris-omnia: Add ethernet aliases
    
    [ Upstream commit f1f3e530c59a7e8c5f06172f4c28b945a6b4bfb8 ]
    
    This allows bootloader to correctly pass MAC addresses used by bootloader
    to individual interfaces into kernel device tree.
    
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: turris-omnia: Add switch port 6 node [+ + +]
Author: Pali Rohár <pali@kernel.org>
Date:   Thu Aug 25 14:21:02 2022 +0200

    ARM: dts: turris-omnia: Add switch port 6 node
    
    [ Upstream commit f87db2005f73876602211af0ee156817019b6bda ]
    
    Switch port 6 is connected to eth0, so add appropriate device tree node for it.
    
    Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
    Signed-off-by: Pali Rohár <pali@kernel.org>
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: mmp: fix timer_read delay [+ + +]
Author: Doug Brown <doug@schmorgal.com>
Date:   Sat Dec 3 16:51:17 2022 -0800

    ARM: mmp: fix timer_read delay
    
    [ Upstream commit e348b4014c31041e13ff370669ba3348c4d385e3 ]
    
    timer_read() was using an empty 100-iteration loop to wait for the
    TMR_CVWR register to capture the latest timer counter value. The delay
    wasn't long enough. This resulted in CPU idle time being extremely
    underreported on PXA168 with CONFIG_NO_HZ_IDLE=y.
    
    Switch to the approach used in the vendor kernel, which implements the
    capture delay by reading TMR_CVWR a few times instead.
    
    Fixes: 49cbe78637eb ("[ARM] pxa: add base support for Marvell's PXA168 processor line")
    Signed-off-by: Doug Brown <doug@schmorgal.com>
    Link: https://lore.kernel.org/r/20221204005117.53452-3-doug@schmorgal.com
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: ux500: do not directly dereference __iomem [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Tue Nov 8 13:37:55 2022 +0100

    ARM: ux500: do not directly dereference __iomem
    
    commit 65b0e307a1a9193571db12910f382f84195a3d29 upstream.
    
    Sparse reports that calling add_device_randomness() on `uid` is a
    violation of address spaces. And indeed the next usage uses readl()
    properly, but that was left out when passing it toadd_device_
    randomness(). So instead copy the whole thing to the stack first.
    
    Fixes: 4040d10a3d44 ("ARM: ux500: add DB serial number to entropy pool")
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/all/202210230819.loF90KDh-lkp@intel.com/
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Link: https://lore.kernel.org/r/20221108123755.207438-1-Jason@zx2c4.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link() [+ + +]
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Mon Dec 5 16:15:27 2022 +0800

    ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link()
    
    [ Upstream commit 8ab2d12c726f0fde0692fa5d81d8019b3dcd62d0 ]
    
    The of_get_next_child() returns a node with refcount incremented, and
    decrements the refcount of prev. So in the error path of the while loop,
    of_node_put() needs be called for cpu_ep.
    
    Fixes: fce9b90c1ab7 ("ASoC: audio-graph-card: cleanup DAI link loop method - step2")
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Link: https://lore.kernel.org/r/1670228127-13835-1-git-send-email-wangyufen@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: codecs: rt298: Add quirk for KBL-R RVP platform [+ + +]
Author: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Date:   Mon Oct 10 14:19:43 2022 +0200

    ASoC: codecs: rt298: Add quirk for KBL-R RVP platform
    
    [ Upstream commit 953dbd1cef18ce9ac0d69c1bd735b929fe52a17e ]
    
    KBL-R RVP platforms also use combojack, so we need to enable that
    configuration for them.
    
    Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Link: https://lore.kernel.org/r/20221010121955.718168-4-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: dt-bindings: wcd9335: fix reset line polarity in example [+ + +]
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date:   Thu Oct 27 00:46:48 2022 -0700

    ASoC: dt-bindings: wcd9335: fix reset line polarity in example
    
    [ Upstream commit 34cb111f8a7b98b5fec809dd194003bca20ef1b2 ]
    
    When resetting the block, the reset line is being driven low and then
    high, which means that the line in DTS should be annotated as "active
    low".
    
    Fixes: 1877c9fda1b7 ("ASoC: dt-bindings: add dt bindings for wcd9335 audio codec")
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20221027074652.1044235-2-dmitry.torokhov@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: bytcr_rt5640: Add quirk for the Advantech MICA-071 tablet [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Dec 13 13:32:46 2022 +0100

    ASoC: Intel: bytcr_rt5640: Add quirk for the Advantech MICA-071 tablet
    
    [ Upstream commit a1dec9d70b6ad97087b60b81d2492134a84208c6 ]
    
    The Advantech MICA-071 tablet deviates from the defaults for
    a non CR Bay Trail based tablet in several ways:
    
    1. It uses an analog MIC on IN3 rather then using DMIC1
    2. It only has 1 speaker
    3. It needs the OVCD current threshold to be set to 1500uA instead of
       the default 2000uA to reliable differentiate between headphones vs
       headsets
    
    Add a quirk with these settings for this tablet.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
    Link: https://lore.kernel.org/r/20221213123246.11226-1-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: Intel: Skylake: Fix driver hang during shutdown [+ + +]
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Mon Dec 5 09:53:29 2022 +0100

    ASoC: Intel: Skylake: Fix driver hang during shutdown
    
    [ Upstream commit 171107237246d66bce04f3769d33648f896b4ce3 ]
    
    AudioDSP cores and HDAudio links need to be turned off on shutdown to
    ensure no communication or data transfer occurs during the procedure.
    
    Fixes: c5a76a246989 ("ASoC: Intel: Skylake: Add shutdown callback")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Tested-by: Lukasz Majczak <lma@semihlaf.com>
    Link: https://lore.kernel.org/r/20221205085330.857665-6-cezary.rojewski@intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mediatek: mt8173-rt5650-rt5514: fix refcount leak in mt8173_rt5650_rt5514_dev_probe() [+ + +]
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Mon Dec 5 18:04:24 2022 +0800

    ASoC: mediatek: mt8173-rt5650-rt5514: fix refcount leak in mt8173_rt5650_rt5514_dev_probe()
    
    [ Upstream commit 3327d721114c109ba0575f86f8fda3b525404054 ]
    
    The node returned by of_parse_phandle() with refcount incremented,
    of_node_put() needs be called when finish using it. So add it in the
    error path in mt8173_rt5650_rt5514_dev_probe().
    
    Fixes: 0d1d7a664288 ("ASoC: mediatek: Refine mt8173 driver and change config option")
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Link: https://lore.kernel.org/r/1670234664-24246-1-git-send-email-wangyufen@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mediatek: mt8173: Enable IRQ when pdata is ready [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Mon Nov 28 11:49:16 2022 +0100

    ASoC: mediatek: mt8173: Enable IRQ when pdata is ready
    
    [ Upstream commit 4cbb264d4e9136acab2c8fd39e39ab1b1402b84b ]
    
    If the device does not come straight from reset, we might receive an IRQ
    before we are ready to handle it.
    
    Fixes:
    
    [    2.334737] Unable to handle kernel read from unreadable memory at virtual address 00000000000001e4
    [    2.522601] Call trace:
    [    2.525040]  regmap_read+0x1c/0x80
    [    2.528434]  mt8173_afe_irq_handler+0x40/0xf0
    ...
    [    2.598921]  start_kernel+0x338/0x42c
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Fixes: ee0bcaff109f ("ASoC: mediatek: Add AFE platform driver")
    Link: https://lore.kernel.org/r/20221128-mt8173-afe-v1-0-70728221628f@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: mediatek: mtk-btcvsd: Add checks for write and read of mtk_btcvsd_snd [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Wed Nov 16 11:07:50 2022 +0800

    ASoC: mediatek: mtk-btcvsd: Add checks for write and read of mtk_btcvsd_snd
    
    [ Upstream commit d067b3378a78c9c3048ac535e31c171b6f5b5846 ]
    
    As the mtk_btcvsd_snd_write and mtk_btcvsd_snd_read may return error,
    it should be better to catch the exception.
    
    Fixes: 4bd8597dc36c ("ASoC: mediatek: add btcvsd driver")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20221116030750.40500-1-jiasheng@iscas.ac.cn
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: pcm512x: Fix PM disable depth imbalance in pcm512x_probe [+ + +]
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Thu Sep 29 00:04:02 2022 +0800

    ASoC: pcm512x: Fix PM disable depth imbalance in pcm512x_probe
    
    [ Upstream commit 97b801be6f8e53676b9f2b105f54e35c745c1b22 ]
    
    The pm_runtime_enable will increase power disable depth. Thus
    a pairing decrement is needed on the error handling path to
    keep it balanced according to context. We fix it by going to
    err_pm instead of err_clk.
    
    Fixes:f086ba9d5389c ("ASoC: pcm512x: Support mastering BCLK/LRCLK using the PLL")
    
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Link: https://lore.kernel.org/r/20220928160402.126140-1-zhangqilong3@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: pxa: fix null-pointer dereference in filter() [+ + +]
Author: Zeng Heng <zengheng4@huawei.com>
Date:   Mon Nov 14 16:56:29 2022 +0800

    ASoC: pxa: fix null-pointer dereference in filter()
    
    [ Upstream commit ec7bf231aaa1bdbcb69d23bc50c753c80fb22429 ]
    
    kasprintf() would return NULL pointer when kmalloc() fail to allocate.
    Need to check the return pointer before calling strcmp().
    
    Fixes: 7a824e214e25 ("ASoC: mmp: add audio dma support")
    Signed-off-by: Zeng Heng <zengheng4@huawei.com>
    Link: https://lore.kernel.org/r/20221114085629.1910435-1-zengheng4@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rockchip: pdm: Add missing clk_disable_unprepare() in rockchip_pdm_runtime_resume() [+ + +]
Author: Wang Jingjin <wangjingjin1@huawei.com>
Date:   Mon Dec 5 11:28:02 2022 +0800

    ASoC: rockchip: pdm: Add missing clk_disable_unprepare() in rockchip_pdm_runtime_resume()
    
    [ Upstream commit ef0a098efb36660326c133af9b5a04a96a00e3ca ]
    
    The clk_disable_unprepare() should be called in the error handling of
    rockchip_pdm_runtime_resume().
    
    Fixes: fc05a5b22253 ("ASoC: rockchip: add support for pdm controller")
    Signed-off-by: Wang Jingjin <wangjingjin1@huawei.com>
    Link: https://lore.kernel.org/r/20221205032802.2422983-1-wangjingjin1@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rockchip: spdif: Add missing clk_disable_unprepare() in rk_spdif_runtime_resume() [+ + +]
Author: Wang Jingjin <wangjingjin1@huawei.com>
Date:   Thu Dec 8 14:39:00 2022 +0800

    ASoC: rockchip: spdif: Add missing clk_disable_unprepare() in rk_spdif_runtime_resume()
    
    [ Upstream commit 6d94d0090527b1763872275a7ccd44df7219b31e ]
    
    rk_spdif_runtime_resume() may have called clk_prepare_enable() before return
    from failed branches, add missing clk_disable_unprepare() in this case.
    
    Fixes: f874b80e1571 ("ASoC: rockchip: Add rockchip SPDIF transceiver driver")
    Signed-off-by: Wang Jingjin <wangjingjin1@huawei.com>
    Link: https://lore.kernel.org/r/20221208063900.4180790-1-wangjingjin1@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: rt5670: Remove unbalanced pm_runtime_put() [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Dec 13 13:33:19 2022 +0100

    ASoC: rt5670: Remove unbalanced pm_runtime_put()
    
    [ Upstream commit 6c900dcc3f7331a67ed29739d74524e428d137fb ]
    
    For some reason rt5670_i2c_probe() does a pm_runtime_put() at the end
    of a successful probe. But it has never done a pm_runtime_get() leading
    to the following error being logged into dmesg:
    
     rt5670 i2c-10EC5640:00: Runtime PM usage count underflow!
    
    Fix this by removing the unnecessary pm_runtime_put().
    
    Fixes: 64e89e5f5548 ("ASoC: rt5670: Add runtime PM support")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20221213123319.11285-1-hdegoede@redhat.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: wm8994: Fix potential deadlock [+ + +]
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Fri Dec 9 10:16:57 2022 +0100

    ASoC: wm8994: Fix potential deadlock
    
    [ Upstream commit 9529dc167ffcdfd201b9f0eda71015f174095f7e ]
    
    Fix this by dropping wm8994->accdet_lock while calling
    cancel_delayed_work_sync(&wm8994->mic_work) in wm1811_jackdet_irq().
    
    Fixes: c0cc3f166525 ("ASoC: wm8994: Allow a delay between jack insertion and microphone detect")
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://lore.kernel.org/r/20221209091657.1183-1-m.szyprowski@samsung.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: ahci: Fix PCS quirk application for suspend [+ + +]
Author: Adam Vodopjan <grozzly@protonmail.com>
Date:   Fri Dec 9 09:26:34 2022 +0000

    ata: ahci: Fix PCS quirk application for suspend
    
    [ Upstream commit 37e14e4f3715428b809e4df9a9958baa64c77d51 ]
    
    Since kernel 5.3.4 my laptop (ICH8M controller) does not see Kingston
    SV300S37A60G SSD disk connected into a SATA connector on wake from
    suspend.  The problem was introduced in c312ef176399 ("libata/ahci: Drop
    PCS quirk for Denverton and beyond"): the quirk is not applied on wake
    from suspend as it originally was.
    
    It is worth to mention the commit contained another bug: the quirk is
    not applied at all to controllers which require it. The fix commit
    09d6ac8dc51a ("libata/ahci: Fix PCS quirk application") landed in 5.3.8.
    So testing my patch anywhere between commits c312ef176399 and
    09d6ac8dc51a is pointless.
    
    Not all disks trigger the problem. For example nothing bad happens with
    Western Digital WD5000LPCX HDD.
    
    Test hardware:
    - Acer 5920G with ICH8M SATA controller
    - sda: some SATA HDD connnected into the DVD drive IDE port with a
      SATA-IDE caddy. It is a boot disk
    - sdb: Kingston SV300S37A60G SSD connected into the only SATA port
    
    Sample "dmesg --notime | grep -E '^(sd |ata)'" output on wake:
    
    sd 0:0:0:0: [sda] Starting disk
    sd 2:0:0:0: [sdb] Starting disk
    ata4: SATA link down (SStatus 4 SControl 300)
    ata3: SATA link down (SStatus 4 SControl 300)
    ata1.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out
    ata1.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) filtered out
    ata1: FORCE: cable set to 80c
    ata5: SATA link down (SStatus 0 SControl 300)
    ata3: SATA link down (SStatus 4 SControl 300)
    ata3: SATA link down (SStatus 4 SControl 300)
    ata3.00: disabled
    sd 2:0:0:0: rejecting I/O to offline device
    ata3.00: detaching (SCSI 2:0:0:0)
    sd 2:0:0:0: [sdb] Start/Stop Unit failed: Result: hostbyte=DID_NO_CONNECT
            driverbyte=DRIVER_OK
    sd 2:0:0:0: [sdb] Synchronizing SCSI cache
    sd 2:0:0:0: [sdb] Synchronize Cache(10) failed: Result:
            hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
    sd 2:0:0:0: [sdb] Stopping disk
    sd 2:0:0:0: [sdb] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET
            driverbyte=DRIVER_OK
    
    Commit c312ef176399 dropped ahci_pci_reset_controller() which internally
    calls ahci_reset_controller() and applies the PCS quirk if needed after
    that. It was called each time a reset was required instead of just
    ahci_reset_controller(). This patch puts the function back in place.
    
    Fixes: c312ef176399 ("libata/ahci: Drop PCS quirk for Denverton and beyond")
    Signed-off-by: Adam Vodopjan <grozzly@protonmail.com>
    Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
binfmt: Fix error return code in load_elf_fdpic_binary() [+ + +]
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Fri Dec 2 09:41:01 2022 +0800

    binfmt: Fix error return code in load_elf_fdpic_binary()
    
    [ Upstream commit e7f703ff2507f4e9f496da96cd4b78fd3026120c ]
    
    Fix to return a negative error code from create_elf_fdpic_tables()
    instead of 0.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/1669945261-30271-1-git-send-email-wangyufen@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

binfmt: Move install_exec_creds after setup_new_exec to match binfmt_elf [+ + +]
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Thu Mar 12 10:17:17 2020 -0500

    binfmt: Move install_exec_creds after setup_new_exec to match binfmt_elf
    
    [ Upstream commit e7f7785449a1f459a4a3ca92f82f56fb054dd2b9 ]
    
    In 2016 Linus moved install_exec_creds immediately after
    setup_new_exec, in binfmt_elf as a cleanup and as part of closing a
    potential information leak.
    
    Perform the same cleanup for the other binary formats.
    
    Different binary formats doing the same things the same way makes exec
    easier to reason about and easier to maintain.
    
    Greg Ungerer reports:
    > I tested the the whole series on non-MMU m68k and non-MMU arm
    > (exercising binfmt_flat) and it all tested out with no problems,
    > so for the binfmt_flat changes:
    Tested-by: Greg Ungerer <gerg@linux-m68k.org>
    
    Ref: 9f834ec18def ("binfmt_elf: switch to new creds when switching to new mm")
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Greg Ungerer <gerg@linux-m68k.org>
    Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
    Stable-dep-of: e7f703ff2507 ("binfmt: Fix error return code in load_elf_fdpic_binary()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
binfmt_misc: fix shift-out-of-bounds in check_special_flags [+ + +]
Author: Liu Shixin <liushixin2@huawei.com>
Date:   Wed Nov 2 10:51:23 2022 +0800

    binfmt_misc: fix shift-out-of-bounds in check_special_flags
    
    [ Upstream commit 6a46bf558803dd2b959ca7435a5c143efe837217 ]
    
    UBSAN reported a shift-out-of-bounds warning:
    
     left shift of 1 by 31 places cannot be represented in type 'int'
     Call Trace:
      <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106
      ubsan_epilogue+0xa/0x44 lib/ubsan.c:151
      __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322
      check_special_flags fs/binfmt_misc.c:241 [inline]
      create_entry fs/binfmt_misc.c:456 [inline]
      bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654
      vfs_write+0x11e/0x580 fs/read_write.c:582
      ksys_write+0xcf/0x120 fs/read_write.c:637
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
     RIP: 0033:0x4194e1
    
    Since the type of Node's flags is unsigned long, we should define these
    macros with same type too.
    
    Signed-off-by: Liu Shixin <liushixin2@huawei.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221102025123.1117184-1-liushixin2@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
blk-mq: fix possible memleak when register 'hctx' failed [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu Nov 17 10:29:40 2022 +0800

    blk-mq: fix possible memleak when register 'hctx' failed
    
    [ Upstream commit 4b7a21c57b14fbcd0e1729150189e5933f5088e9 ]
    
    There's issue as follows when do fault injection test:
    unreferenced object 0xffff888132a9f400 (size 512):
      comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff  ...........2....
        08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00  ...2............
      backtrace:
        [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0
        [<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0
        [<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230
        [<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910
        [<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0
        [<00000000a2a34657>] 0xffffffffa2ad310f
        [<00000000b173f718>] 0xffffffffa2af824a
        [<0000000095a1dabb>] do_one_initcall+0x87/0x2a0
        [<00000000f32fdf93>] do_init_module+0xdf/0x320
        [<00000000cbe8541e>] load_module+0x3006/0x3390
        [<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0
        [<00000000a1a29ae8>] do_syscall_64+0x35/0x80
        [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Fault injection context as follows:
     kobject_add
     blk_mq_register_hctx
     blk_mq_sysfs_register
     blk_register_queue
     device_add_disk
     null_add_dev.part.0 [null_blk]
    
    As 'blk_mq_register_hctx' may already add some objects when failed halfway,
    but there isn't do fallback, caller don't know which objects add failed.
    To solve above issue just do fallback when add objects failed halfway in
    'blk_mq_register_hctx'.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20221117022940.873959-1-yebin@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
blktrace: Fix output non-blktrace event when blk_classic option enabled [+ + +]
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Tue Nov 22 12:04:10 2022 +0800

    blktrace: Fix output non-blktrace event when blk_classic option enabled
    
    [ Upstream commit f596da3efaf4130ff61cd029558845808df9bf99 ]
    
    When the blk_classic option is enabled, non-blktrace events must be
    filtered out. Otherwise, events of other types are output in the blktrace
    classic format, which is unexpected.
    
    The problem can be triggered in the following ways:
    
      # echo 1 > /sys/kernel/debug/tracing/options/blk_classic
      # echo 1 > /sys/kernel/debug/tracing/events/enable
      # echo blk > /sys/kernel/debug/tracing/current_tracer
      # cat /sys/kernel/debug/tracing/trace_pipe
    
    Fixes: c71a89615411 ("blktrace: add ftrace plugin")
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Link: https://lore.kernel.org/r/20221122040410.85113-1-yangjihong1@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: btusb: don't call kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Dec 6 20:59:10 2022 +0800

    Bluetooth: btusb: don't call kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit b15a6bd3c80c77faec8317319b97f976b1a08332 ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with interrupts being disabled. So replace kfree_skb()
    with dev_kfree_skb_irq() under spin_lock_irqsave().
    
    Fixes: 803b58367ffb ("Bluetooth: btusb: Implement driver internal packet reassembly")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_bcsp: don't call kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Dec 7 10:18:33 2022 +0800

    Bluetooth: hci_bcsp: don't call kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 7b503e339c1a80bf0051ec2d19c3bc777014ac61 ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with interrupts being disabled. So replace kfree_skb()
    with dev_kfree_skb_irq() under spin_lock_irqsave().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_core: don't call kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Dec 7 10:18:34 2022 +0800

    Bluetooth: hci_core: don't call kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 39c1eb6fcbae8ce9bb71b2ac5cb609355a2b181b ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with interrupts being disabled. So replace kfree_skb()
    with dev_kfree_skb_irq() under spin_lock_irqsave().
    
    Fixes: 9238f36a5a50 ("Bluetooth: Add request cmd_complete and cmd_status functions")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_h5: don't call kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Dec 7 10:18:32 2022 +0800

    Bluetooth: hci_h5: don't call kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 383630cc6758d619874c2e8bb2f68a61f3f9ef6e ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with interrupts being disabled. So replace kfree_skb()
    with dev_kfree_skb_irq() under spin_lock_irqsave().
    
    Fixes: 43eb12d78960 ("Bluetooth: Fix/implement Three-wire reliable packet sending")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_ll: don't call kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Dec 7 10:18:31 2022 +0800

    Bluetooth: hci_ll: don't call kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 8f458f783dfbb19c1f1cb58ed06eeb701f52091b ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with interrupts being disabled. So replace kfree_skb()
    with dev_kfree_skb_irq() under spin_lock_irqsave().
    
    Fixes: 166d2f6a4332 ("[Bluetooth] Add UART driver for Texas Instruments' BRF63xx chips")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: hci_qca: don't call kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Dec 7 10:18:30 2022 +0800

    Bluetooth: hci_qca: don't call kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit df4cfc91208e0a98f078223793f5871b1a82cc54 ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with interrupts being disabled. So replace kfree_skb()
    with dev_kfree_skb_irq() under spin_lock_irqsave().
    
    Fixes: 0ff252c1976d ("Bluetooth: hciuart: Add support QCA chipset for UART")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: L2CAP: Fix u8 overflow [+ + +]
Author: Sungwoo Kim <iam@sung-woo.kim>
Date:   Fri Nov 18 15:01:47 2022 -0500

    Bluetooth: L2CAP: Fix u8 overflow
    
    [ Upstream commit bcd70260ef56e0aee8a4fc6cd214a419900b0765 ]
    
    By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases
    multiple times and eventually it will wrap around the maximum number
    (i.e., 255).
    This patch prevents this by adding a boundary check with
    L2CAP_MAX_CONF_RSP
    
    Btmon log:
    Bluetooth monitor ver 5.64
    = Note: Linux version 6.1.0-rc2 (x86_64)                               0.264594
    = Note: Bluetooth subsystem version 2.22                               0.264636
    @ MGMT Open: btmon (privileged) version 1.22                  {0x0001} 0.272191
    = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0)          [hci0] 13.877604
    @ RAW Open: 9496 (privileged) version 2.22                   {0x0002} 13.890741
    = Open Index: 00:00:00:00:00:00                                [hci0] 13.900426
    (...)
    > ACL Data RX: Handle 200 flags 0x00 dlen 1033             #32 [hci0] 14.273106
            invalid packet size (12 != 1033)
            08 00 01 00 02 01 04 00 01 10 ff ff              ............
    > ACL Data RX: Handle 200 flags 0x00 dlen 1547             #33 [hci0] 14.273561
            invalid packet size (14 != 1547)
            0a 00 01 00 04 01 06 00 40 00 00 00 00 00        ........@.....
    > ACL Data RX: Handle 200 flags 0x00 dlen 2061             #34 [hci0] 14.274390
            invalid packet size (16 != 2061)
            0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04  ........@.......
    > ACL Data RX: Handle 200 flags 0x00 dlen 2061             #35 [hci0] 14.274932
            invalid packet size (16 != 2061)
            0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00  ........@.......
    = bluetoothd: Bluetooth daemon 5.43                                   14.401828
    > ACL Data RX: Handle 200 flags 0x00 dlen 1033             #36 [hci0] 14.275753
            invalid packet size (12 != 1033)
            08 00 01 00 04 01 04 00 40 00 00 00              ........@...
    
    Signed-off-by: Sungwoo Kim <iam@sung-woo.kim>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: RFCOMM: don't call kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Dec 7 10:18:35 2022 +0800

    Bluetooth: RFCOMM: don't call kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 0ba18967d4544955b2eff2fbc4f2a8750c4df90a ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with interrupts being disabled. So replace kfree_skb()
    with dev_kfree_skb_irq() under spin_lock_irqsave().
    
    Fixes: 81be03e026dc ("Bluetooth: RFCOMM: Replace use of memcpy_from_msg with bt_skb_sendmmsg")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bonding: Export skip slave logic to function [+ + +]
Author: Maor Gottlieb <maorg@mellanox.com>
Date:   Thu Apr 30 22:21:32 2020 +0300

    bonding: Export skip slave logic to function
    
    [ Upstream commit 119d48fd4298594beccf4f2ecd00627826ce2646 ]
    
    As a preparation for following change that add array of
    all slaves, extract code that skip slave to function.
    
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Reviewed-by: Jiri Pirko <jiri@mellanox.com>
    Reviewed-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Stable-dep-of: f8a65ab2f3ff ("bonding: fix link recovery in mode 2 when updelay is nonzero")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bonding: fix link recovery in mode 2 when updelay is nonzero [+ + +]
Author: Jonathan Toppins <jtoppins@redhat.com>
Date:   Tue Nov 22 16:24:29 2022 -0500

    bonding: fix link recovery in mode 2 when updelay is nonzero
    
    [ Upstream commit f8a65ab2f3ff7410921ebbf0dc55453102c33c56 ]
    
    Before this change when a bond in mode 2 lost link, all of its slaves
    lost link, the bonding device would never recover even after the
    expiration of updelay. This change removes the updelay when the bond
    currently has no usable links. Conforming to bonding.txt section 13.1
    paragraph 4.
    
    Fixes: 41f891004063 ("bonding: ignore updelay param when there is no active slave")
    Signed-off-by: Jonathan Toppins <jtoppins@redhat.com>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bonding: Rename slave_arr to usable_slaves [+ + +]
Author: Maor Gottlieb <maorg@mellanox.com>
Date:   Thu Apr 30 22:21:33 2020 +0300

    bonding: Rename slave_arr to usable_slaves
    
    [ Upstream commit ed7d4f023b1a9b0578f20d66557c66452ab845ec ]
    
    Rename slave_arr to usable_slaves, since we will have two arrays,
    one for the usable slaves and the other to all slaves.
    
    Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
    Reviewed-by: Jiri Pirko <jiri@mellanox.com>
    Reviewed-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
    Stable-dep-of: f8a65ab2f3ff ("bonding: fix link recovery in mode 2 when updelay is nonzero")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bonding: uninitialized variable in bond_miimon_inspect() [+ + +]
Author: Dan Carpenter <error27@gmail.com>
Date:   Mon Nov 28 14:06:14 2022 +0300

    bonding: uninitialized variable in bond_miimon_inspect()
    
    [ Upstream commit e5214f363dabca240446272dac54d404501ad5e5 ]
    
    The "ignore_updelay" variable needs to be initialized to false.
    
    Fixes: f8a65ab2f3ff ("bonding: fix link recovery in mode 2 when updelay is nonzero")
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
    Link: https://lore.kernel.org/r/Y4SWJlh3ohJ6EPTL@kili
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, sockmap: Fix data loss caused by using apply_bytes on ingress redirect [+ + +]
Author: Pengcheng Yang <yangpc@wangsu.com>
Date:   Tue Nov 29 18:40:40 2022 +0800

    bpf, sockmap: Fix data loss caused by using apply_bytes on ingress redirect
    
    [ Upstream commit 9072931f020bfd907d6d89ee21ff1481cd78b407 ]
    
    Use apply_bytes on ingress redirect, when apply_bytes is less than
    the length of msg data, some data may be skipped and lost in
    bpf_tcp_ingress().
    
    If there is still data in the scatterlist that has not been consumed,
    we cannot move the msg iter.
    
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Signed-off-by: Pengcheng Yang <yangpc@wangsu.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/1669718441-2654-4-git-send-email-yangpc@wangsu.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf, sockmap: fix race in sock_map_free() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Dec 2 11:16:40 2022 +0000

    bpf, sockmap: fix race in sock_map_free()
    
    [ Upstream commit 0a182f8d607464911756b4dbef5d6cad8de22469 ]
    
    sock_map_free() calls release_sock(sk) without owning a reference
    on the socket. This can cause use-after-free as syzbot found [1]
    
    Jakub Sitnicki already took care of a similar issue
    in sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:
    Synchronize delete from bucket list on map free")
    
    [1]
    refcount_t: decrement hit 0; leaking memory.
    WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
    Modules linked in:
    CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    Workqueue: events_unbound bpf_map_free_deferred
    RIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
    Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff
    RSP: 0018:ffffc9000456fb60 EFLAGS: 00010246
    RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0
    RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000
    RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5
    R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004
    R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf
    FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    <TASK>
    __refcount_dec include/linux/refcount.h:344 [inline]
    refcount_dec include/linux/refcount.h:359 [inline]
    __sock_put include/net/sock.h:779 [inline]
    tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092
    release_sock+0xaf/0x1c0 net/core/sock.c:3468
    sock_map_free+0x219/0x2c0 net/core/sock_map.c:356
    process_one_work+0x81c/0xd10 kernel/workqueue.c:2289
    worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
    kthread+0x266/0x300 kernel/kthread.c:376
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
    </TASK>
    
    Fixes: 7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Cc: Jakub Sitnicki <jakub@cloudflare.com>
    Cc: John Fastabend <john.fastabend@gmail.com>
    Cc: Alexei Starovoitov <ast@kernel.org>
    Cc: Daniel Borkmann <daniel@iogearbox.net>
    Cc: Song Liu <songliubraving@fb.com>
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Link: https://lore.kernel.org/r/20221202111640.2745533-1-edumazet@google.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data [+ + +]
Author: Pengcheng Yang <yangpc@wangsu.com>
Date:   Tue Nov 29 18:40:38 2022 +0800

    bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data
    
    [ Upstream commit 7a9841ca025275b5b0edfb0b618934abb6ceec15 ]
    
    In tcp_bpf_send_verdict() redirection, the eval variable is assigned to
    __SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,
    sock_put() will be called multiple times.
    
    We should reset the eval variable to __SK_NONE every time more_data
    starts.
    
    This causes:
    
    IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7
    ------------[ cut here ]------------
    refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110
    Modules linked in:
    CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1
    Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
    Call Trace:
     <TASK>
     __tcp_transmit_skb+0xa1b/0xb90
     ? __alloc_skb+0x8c/0x1a0
     ? __kmalloc_node_track_caller+0x184/0x320
     tcp_write_xmit+0x22a/0x1110
     __tcp_push_pending_frames+0x32/0xf0
     do_tcp_sendpages+0x62d/0x640
     tcp_bpf_push+0xae/0x2c0
     tcp_bpf_sendmsg_redir+0x260/0x410
     ? preempt_count_add+0x70/0xa0
     tcp_bpf_send_verdict+0x386/0x4b0
     tcp_bpf_sendmsg+0x21b/0x3b0
     sock_sendmsg+0x58/0x70
     __sys_sendto+0xfa/0x170
     ? xfd_validate_state+0x1d/0x80
     ? switch_fpu_return+0x59/0xe0
     __x64_sys_sendto+0x24/0x30
     do_syscall_64+0x37/0x90
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: cd9733f5d75c ("tcp_bpf: Fix one concurrency problem in the tcp_bpf_send_verdict function")
    Signed-off-by: Pengcheng Yang <yangpc@wangsu.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/bpf/1669718441-2654-2-git-send-email-yangpc@wangsu.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf: make sure skb->len != 0 when redirecting to a tunneling device [+ + +]
Author: Stanislav Fomichev <sdf@google.com>
Date:   Thu Oct 27 15:55:37 2022 -0700

    bpf: make sure skb->len != 0 when redirecting to a tunneling device
    
    [ Upstream commit 07ec7b502800ba9f7b8b15cb01dd6556bb41aaca ]
    
    syzkaller managed to trigger another case where skb->len == 0
    when we enter __dev_queue_xmit:
    
    WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]
    WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295
    
    Call Trace:
     dev_queue_xmit+0x17/0x20 net/core/dev.c:4406
     __bpf_tx_skb net/core/filter.c:2115 [inline]
     __bpf_redirect_no_mac net/core/filter.c:2140 [inline]
     __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163
     ____bpf_clone_redirect net/core/filter.c:2447 [inline]
     bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419
     bpf_prog_48159a89cb4a9a16+0x59/0x5e
     bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline]
     __bpf_prog_run include/linux/filter.h:596 [inline]
     bpf_prog_run include/linux/filter.h:603 [inline]
     bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402
     bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170
     bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648
     __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005
     __do_sys_bpf kernel/bpf/syscall.c:5091 [inline]
     __se_sys_bpf kernel/bpf/syscall.c:5089 [inline]
     __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089
     do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48
     entry_SYSCALL_64_after_hwframe+0x61/0xc6
    
    The reproducer doesn't really reproduce outside of syzkaller
    environment, so I'm taking a guess here. It looks like we
    do generate correct ETH_HLEN-sized packet, but we redirect
    the packet to the tunneling device. Before we do so, we
    __skb_pull l2 header and arrive again at skb->len == 0.
    Doesn't seem like we can do anything better than having
    an explicit check after __skb_pull?
    
    Cc: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot+f635e86ec3fa0a37e019@syzkaller.appspotmail.com
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/r/20221027225537.353077-1-sdf@google.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Move skb->len == 0 checks into __bpf_redirect [+ + +]
Author: Stanislav Fomichev <sdf@google.com>
Date:   Mon Nov 21 10:03:39 2022 -0800

    bpf: Move skb->len == 0 checks into __bpf_redirect
    
    [ Upstream commit 114039b342014680911c35bd6b72624180fd669a ]
    
    To avoid potentially breaking existing users.
    
    Both mac/no-mac cases have to be amended; mac_header >= network_header
    is not enough (verified with a new test, see next patch).
    
    Fixes: fd1894224407 ("bpf: Don't redirect packets with invalid pkt_len")
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/r/20221121180340.1983627-1-sdf@google.com
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: Prevent decl_tag from being referenced in func_proto arg [+ + +]
Author: Stanislav Fomichev <sdf@google.com>
Date:   Tue Nov 22 19:54:22 2022 -0800

    bpf: Prevent decl_tag from being referenced in func_proto arg
    
    [ Upstream commit f17472d4599697d701aa239b4c475a506bccfd19 ]
    
    Syzkaller managed to hit another decl_tag issue:
    
      btf_func_proto_check kernel/bpf/btf.c:4506 [inline]
      btf_check_all_types kernel/bpf/btf.c:4734 [inline]
      btf_parse_type_sec+0x1175/0x1980 kernel/bpf/btf.c:4763
      btf_parse kernel/bpf/btf.c:5042 [inline]
      btf_new_fd+0x65a/0xb00 kernel/bpf/btf.c:6709
      bpf_btf_load+0x6f/0x90 kernel/bpf/syscall.c:4342
      __sys_bpf+0x50a/0x6c0 kernel/bpf/syscall.c:5034
      __do_sys_bpf kernel/bpf/syscall.c:5093 [inline]
      __se_sys_bpf kernel/bpf/syscall.c:5091 [inline]
      __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5091
      do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48
    
    This seems similar to commit ea68376c8bed ("bpf: prevent decl_tag from being
    referenced in func_proto") but for the argument.
    
    Reported-by: syzbot+8dd0551dda6020944c5d@syzkaller.appspotmail.com
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Yonghong Song <yhs@fb.com>
    Link: https://lore.kernel.org/bpf/20221123035422.872531-2-sdf@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: propagate precision in ALU/ALU64 operations [+ + +]
Author: Andrii Nakryiko <andrii@kernel.org>
Date:   Fri Nov 4 09:36:44 2022 -0700

    bpf: propagate precision in ALU/ALU64 operations
    
    [ Upstream commit a3b666bfa9c9edc05bca62a87abafe0936bd7f97 ]
    
    When processing ALU/ALU64 operations (apart from BPF_MOV, which is
    handled correctly already; and BPF_NEG and BPF_END are special and don't
    have source register), if destination register is already marked
    precise, this causes problem with potentially missing precision tracking
    for the source register. E.g., when we have r1 >>= r5 and r1 is marked
    precise, but r5 isn't, this will lead to r5 staying as imprecise. This
    is due to the precision backtracking logic stopping early when it sees
    r1 is already marked precise. If r1 wasn't precise, we'd keep
    backtracking and would add r5 to the set of registers that need to be
    marked precise. So there is a discrepancy here which can lead to invalid
    and incompatible states matched due to lack of precision marking on r5.
    If r1 wasn't precise, precision backtracking would correctly mark both
    r1 and r5 as precise.
    
    This is simple to fix, though. During the forward instruction simulation
    pass, for arithmetic operations of `scalar <op>= scalar` form (where
    <op> is ALU or ALU64 operations), if destination register is already
    precise, mark source register as precise. This applies only when both
    involved registers are SCALARs. `ptr += scalar` and `scalar += ptr`
    cases are already handled correctly.
    
    This does have (negative) effect on some selftest programs and few
    Cilium programs.  ~/baseline-tmp-results.csv are veristat results with
    this patch, while ~/baseline-results.csv is without it. See post
    scriptum for instructions on how to make Cilium programs testable with
    veristat. Correctness has a price.
    
    $ ./veristat -C -e file,prog,insns,states ~/baseline-results.csv ~/baseline-tmp-results.csv | grep -v '+0'
    File                     Program               Total insns (A)  Total insns (B)  Total insns (DIFF)  Total states (A)  Total states (B)  Total states (DIFF)
    -----------------------  --------------------  ---------------  ---------------  ------------------  ----------------  ----------------  -------------------
    bpf_cubic.bpf.linked1.o  bpf_cubic_cong_avoid              997             1700      +703 (+70.51%)                62                90        +28 (+45.16%)
    test_l4lb.bpf.linked1.o  balancer_ingress                 4559             5469      +910 (+19.96%)               118               126          +8 (+6.78%)
    -----------------------  --------------------  ---------------  ---------------  ------------------  ----------------  ----------------  -------------------
    
    $ ./veristat -C -e file,prog,verdict,insns,states ~/baseline-results-cilium.csv ~/baseline-tmp-results-cilium.csv | grep -v '+0'
    File           Program                         Total insns (A)  Total insns (B)  Total insns (DIFF)  Total states (A)  Total states (B)  Total states (DIFF)
    -------------  ------------------------------  ---------------  ---------------  ------------------  ----------------  ----------------  -------------------
    bpf_host.o     tail_nodeport_nat_ingress_ipv6             4448             5261      +813 (+18.28%)               234               247         +13 (+5.56%)
    bpf_host.o     tail_nodeport_nat_ipv6_egress              3396             3446        +50 (+1.47%)               201               203          +2 (+1.00%)
    bpf_lxc.o      tail_nodeport_nat_ingress_ipv6             4448             5261      +813 (+18.28%)               234               247         +13 (+5.56%)
    bpf_overlay.o  tail_nodeport_nat_ingress_ipv6             4448             5261      +813 (+18.28%)               234               247         +13 (+5.56%)
    bpf_xdp.o      tail_lb_ipv4                              71736            73442      +1706 (+2.38%)              4295              4370         +75 (+1.75%)
    -------------  ------------------------------  ---------------  ---------------  ------------------  ----------------  ----------------  -------------------
    
    P.S. To make Cilium ([0]) programs libbpf-compatible and thus
    veristat-loadable, apply changes from topmost commit in [1], which does
    minimal changes to Cilium source code, mostly around SEC() annotations
    and BPF map definitions.
    
      [0] https://github.com/cilium/cilium/
      [1] https://github.com/anakryiko/cilium/commits/libbpf-friendliness
    
    Fixes: b5dc0163d8fd ("bpf: precise scalar_value tracking")
    Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/r/20221104163649.121784-2-andrii@kernel.org
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

bpf: pull before calling skb_postpull_rcsum() [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Mon Dec 19 16:47:00 2022 -0800

    bpf: pull before calling skb_postpull_rcsum()
    
    [ Upstream commit 54c3f1a81421f85e60ae2eaae7be3727a09916ee ]
    
    Anand hit a BUG() when pulling off headers on egress to a SW tunnel.
    We get to skb_checksum_help() with an invalid checksum offset
    (commit d7ea0d9df2a6 ("net: remove two BUG() from skb_checksum_help()")
    converted those BUGs to WARN_ONs()).
    He points out oddness in how skb_postpull_rcsum() gets used.
    Indeed looks like we should pull before "postpull", otherwise
    the CHECKSUM_PARTIAL fixup from skb_postpull_rcsum() will not
    be able to do its job:
    
            if (skb->ip_summed == CHECKSUM_PARTIAL &&
                skb_checksum_start_offset(skb) < 0)
                    skb->ip_summed = CHECKSUM_NONE;
    
    Reported-by: Anand Parthasarathy <anpartha@meta.com>
    Fixes: 6578171a7ff0 ("bpf: add bpf_skb_change_proto helper")
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Acked-by: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/r/20221220004701.402165-1-kuba@kernel.org
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
brcmfmac: return error when getting invalid max_flowrings from dongle [+ + +]
Author: Wright Feng <wright.feng@cypress.com>
Date:   Wed Sep 28 22:10:00 2022 -0500

    brcmfmac: return error when getting invalid max_flowrings from dongle
    
    [ Upstream commit 2aca4f3734bd717e04943ddf340d49ab62299a00 ]
    
    When firmware hit trap at initialization, host will read abnormal
    max_flowrings number from dongle, and it will cause kernel panic when
    doing iowrite to initialize dongle ring.
    To detect this error at early stage, we directly return error when getting
    invalid max_flowrings(>256).
    
    Signed-off-by: Wright Feng <wright.feng@cypress.com>
    Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
    Signed-off-by: Ian Lin <ian.lin@infineon.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20220929031001.9962-3-ian.lin@infineon.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: fix resolving backrefs for inline extent followed by prealloc [+ + +]
Author: Boris Burkov <boris@bur.io>
Date:   Wed Dec 14 15:05:08 2022 -0800

    btrfs: fix resolving backrefs for inline extent followed by prealloc
    
    commit 560840afc3e63bbe5d9c5ef6b2ecf8f3589adff6 upstream.
    
    If a file consists of an inline extent followed by a regular or prealloc
    extent, then a legitimate attempt to resolve a logical address in the
    non-inline region will result in add_all_parents reading the invalid
    offset field of the inline extent. If the inline extent item is placed
    in the leaf eb s.t. it is the first item, attempting to access the
    offset field will not only be meaningless, it will go past the end of
    the eb and cause this panic:
    
      [17.626048] BTRFS warning (device dm-2): bad eb member end: ptr 0x3fd4 start 30834688 member offset 16377 size 8
      [17.631693] general protection fault, probably for non-canonical address 0x5088000000000: 0000 [#1] SMP PTI
      [17.635041] CPU: 2 PID: 1267 Comm: btrfs Not tainted 5.12.0-07246-g75175d5adc74-dirty #199
      [17.637969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
      [17.641995] RIP: 0010:btrfs_get_64+0xe7/0x110
      [17.649890] RSP: 0018:ffffc90001f73a08 EFLAGS: 00010202
      [17.651652] RAX: 0000000000000001 RBX: ffff88810c42d000 RCX: 0000000000000000
      [17.653921] RDX: 0005088000000000 RSI: ffffc90001f73a0f RDI: 0000000000000001
      [17.656174] RBP: 0000000000000ff9 R08: 0000000000000007 R09: c0000000fffeffff
      [17.658441] R10: ffffc90001f73790 R11: ffffc90001f73788 R12: ffff888106afe918
      [17.661070] R13: 0000000000003fd4 R14: 0000000000003f6f R15: cdcdcdcdcdcdcdcd
      [17.663617] FS:  00007f64e7627d80(0000) GS:ffff888237c80000(0000) knlGS:0000000000000000
      [17.666525] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [17.668664] CR2: 000055d4a39152e8 CR3: 000000010c596002 CR4: 0000000000770ee0
      [17.671253] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [17.673634] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [17.676034] PKRU: 55555554
      [17.677004] Call Trace:
      [17.677877]  add_all_parents+0x276/0x480
      [17.679325]  find_parent_nodes+0xfae/0x1590
      [17.680771]  btrfs_find_all_leafs+0x5e/0xa0
      [17.682217]  iterate_extent_inodes+0xce/0x260
      [17.683809]  ? btrfs_inode_flags_to_xflags+0x50/0x50
      [17.685597]  ? iterate_inodes_from_logical+0xa1/0xd0
      [17.687404]  iterate_inodes_from_logical+0xa1/0xd0
      [17.689121]  ? btrfs_inode_flags_to_xflags+0x50/0x50
      [17.691010]  btrfs_ioctl_logical_to_ino+0x131/0x190
      [17.692946]  btrfs_ioctl+0x104a/0x2f60
      [17.694384]  ? selinux_file_ioctl+0x182/0x220
      [17.695995]  ? __x64_sys_ioctl+0x84/0xc0
      [17.697394]  __x64_sys_ioctl+0x84/0xc0
      [17.698697]  do_syscall_64+0x33/0x40
      [17.700017]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [17.701753] RIP: 0033:0x7f64e72761b7
      [17.709355] RSP: 002b:00007ffefb067f58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [17.712088] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f64e72761b7
      [17.714667] RDX: 00007ffefb067fb0 RSI: 00000000c0389424 RDI: 0000000000000003
      [17.717386] RBP: 00007ffefb06d188 R08: 000055d4a390d2b0 R09: 00007f64e7340a60
      [17.719938] R10: 0000000000000231 R11: 0000000000000246 R12: 0000000000000001
      [17.722383] R13: 0000000000000000 R14: 00000000c0389424 R15: 000055d4a38fd2a0
      [17.724839] Modules linked in:
    
    Fix the bug by detecting the inline extent item in add_all_parents and
    skipping to the next extent item.
    
    CC: stable@vger.kernel.org # 4.9+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Boris Burkov <boris@bur.io>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: replace strncpy() with strscpy() [+ + +]
Author: Sasha Levin <sashal@kernel.org>
Date:   Wed Jan 4 11:14:45 2023 -0500

    btrfs: replace strncpy() with strscpy()
    
    [ Upstream commit 63d5429f68a3d4c4aa27e65a05196c17f86c41d6 ]
    
    Using strncpy() on NUL-terminated strings are deprecated.  To avoid
    possible forming of non-terminated string strscpy() should be used.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    CC: stable@vger.kernel.org # 4.9+
    Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
caif: fix memory leak in cfctrl_linkup_request() [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Wed Jan 4 14:51:46 2023 +0800

    caif: fix memory leak in cfctrl_linkup_request()
    
    [ Upstream commit fe69230f05897b3de758427b574fc98025dfc907 ]
    
    When linktype is unknown or kzalloc failed in cfctrl_linkup_request(),
    pkt is not released. Add release process to error path.
    
    Fixes: b482cd2053e3 ("net-caif: add CAIF core protocol stack")
    Fixes: 8d545c8f958f ("caif: Disconnect without waiting for response")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20230104065146.1153009-1-shaozhengchao@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
can: kvaser_usb: Add struct kvaser_usb_busparams [+ + +]
Author: Jimmy Assarsson <extja@kvaser.com>
Date:   Mon Oct 10 20:52:36 2022 +0200

    can: kvaser_usb: Add struct kvaser_usb_busparams
    
    [ Upstream commit 00e5786177649c1e3110f9454fdd34e336597265 ]
    
    Add struct kvaser_usb_busparams containing the busparameters used in
    CMD_{SET,GET}_BUSPARAMS* commands.
    
    Tested-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://lore.kernel.org/all/20221010185237.319219-11-extja@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Stable-dep-of: 39d3df6b0ea8 ("can: kvaser_usb: Compare requested bittiming parameters with actual parameters in do_set_{,data}_bittiming")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb: Compare requested bittiming parameters with actual parameters in do_set_{,data}_bittiming [+ + +]
Author: Jimmy Assarsson <extja@kvaser.com>
Date:   Mon Oct 10 20:52:37 2022 +0200

    can: kvaser_usb: Compare requested bittiming parameters with actual parameters in do_set_{,data}_bittiming
    
    [ Upstream commit 39d3df6b0ea80f9b515c632ca07b39b1c156edee ]
    
    The device will respond with a CMD_ERROR_EVENT command, with error_code
    KVASER_USB_{LEAF,HYDRA}_ERROR_EVENT_PARAM, if the CMD_SET_BUSPARAMS_REQ
    contains invalid bittiming parameters.
    However, this command does not contain any channel reference.
    
    To check if the CMD_SET_BUSPARAMS_REQ was successful, redback and compare
    the requested bittiming parameters with the device reported parameters.
    
    Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
    Fixes: aec5fb2268b7 ("can: kvaser_usb: Add support for Kvaser USB hydra family")
    Tested-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Co-developed-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://lore.kernel.org/all/20221010185237.319219-12-extja@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb: do not increase tx statistics when sending error message frames [+ + +]
Author: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Date:   Tue Dec 7 21:15:28 2021 +0900

    can: kvaser_usb: do not increase tx statistics when sending error message frames
    
    [ Upstream commit 0b0ce2c67795672115ac6ca28351a78799cd114b ]
    
    The CAN error message frames (i.e. error skb) are an interface
    specific to socket CAN. The payload of the CAN error message frames
    does not correspond to any actual data sent on the wire. Only an error
    flag and a delimiter are transmitted when an error occurs (c.f. ISO
    11898-1 section 10.4.4.2 "Error flag").
    
    For this reason, it makes no sense to increment the tx_packets and
    tx_bytes fields of struct net_device_stats when sending an error
    message frame because no actual payload will be transmitted on the
    wire.
    
    N.B. Sending error message frames is a very specific feature which, at
    the moment, is only supported by the Kvaser Hydra hardware. Please
    refer to [1] for more details on the topic.
    
    [1] https://lore.kernel.org/linux-can/CAMZ6RqK0rTNg3u3mBpZOoY51jLZ-et-J01tY6-+mWsM4meVw-A@mail.gmail.com/t/#u
    
    Link: https://lore.kernel.org/all/20211207121531.42941-3-mailhol.vincent@wanadoo.fr
    Co-developed-by: Jimmy Assarsson <extja@kvaser.com>
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Stable-dep-of: 35364f5b41a4 ("can: kvaser_usb: kvaser_usb_leaf: Get capabilities from device")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb: kvaser_usb_leaf: Get capabilities from device [+ + +]
Author: Jimmy Assarsson <extja@kvaser.com>
Date:   Mon Oct 10 20:52:28 2022 +0200

    can: kvaser_usb: kvaser_usb_leaf: Get capabilities from device
    
    [ Upstream commit 35364f5b41a4917fe94a3f393d149b63ec583297 ]
    
    Use the CMD_GET_CAPABILITIES_REQ command to query the device for certain
    capabilities. We are only interested in LISTENONLY mode and wither the
    device reports CAN error counters.
    
    Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
    Reported-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Tested-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://lore.kernel.org/all/20221010185237.319219-3-extja@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb: kvaser_usb_leaf: Handle CMD_ERROR_EVENT [+ + +]
Author: Jimmy Assarsson <extja@kvaser.com>
Date:   Mon Oct 10 20:52:30 2022 +0200

    can: kvaser_usb: kvaser_usb_leaf: Handle CMD_ERROR_EVENT
    
    [ Upstream commit b24cb2d169e0c9dce664a959e1f2aa9781285dc9 ]
    
    The device will send an error event command, to indicate certain errors.
    This indicates a misbehaving driver, and should never occur.
    
    Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
    Tested-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Co-developed-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://lore.kernel.org/all/20221010185237.319219-5-extja@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb: kvaser_usb_leaf: Rename {leaf,usbcan}_cmd_error_event to {leaf,usbcan}_cmd_can_error_event [+ + +]
Author: Jimmy Assarsson <extja@kvaser.com>
Date:   Mon Oct 10 20:52:29 2022 +0200

    can: kvaser_usb: kvaser_usb_leaf: Rename {leaf,usbcan}_cmd_error_event to {leaf,usbcan}_cmd_can_error_event
    
    [ Upstream commit 7ea56128dbf904a3359bcf9289cccdfa3c85c7e8 ]
    
    Prepare for handling CMD_ERROR_EVENT. Rename struct
    {leaf,usbcan}_cmd_error_event to {leaf,usbcan}_cmd_can_error_event.
    
    Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
    Reported-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Tested-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://lore.kernel.org/all/20221010185237.319219-4-extja@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb_leaf: Fix bogus restart events [+ + +]
Author: Anssi Hannula <anssi.hannula@bitwise.fi>
Date:   Mon Oct 10 20:52:35 2022 +0200

    can: kvaser_usb_leaf: Fix bogus restart events
    
    [ Upstream commit 90904d326269a38fe5dd895fb2db7c03199654c4 ]
    
    When auto-restart is enabled, the kvaser_usb_leaf driver considers
    transition from any state >= CAN_STATE_BUS_OFF as a bus-off recovery
    event (restart).
    
    However, these events may occur at interface startup time before
    kvaser_usb_open() has set the state to CAN_STATE_ERROR_ACTIVE, causing
    restarts counter to increase and CAN_ERR_RESTARTED to be sent despite no
    actual restart having occurred.
    
    Fix that by making the auto-restart condition checks more strict so that
    they only trigger when the interface was actually in the BUS_OFF state.
    
    Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
    Tested-by: Jimmy Assarsson <extja@kvaser.com>
    Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://lore.kernel.org/all/20221010185237.319219-10-extja@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb_leaf: Fix improved state not being reported [+ + +]
Author: Anssi Hannula <anssi.hannula@bitwise.fi>
Date:   Mon Oct 10 20:52:32 2022 +0200

    can: kvaser_usb_leaf: Fix improved state not being reported
    
    [ Upstream commit 8d21f5927ae604881f98587fabf6753f88730968 ]
    
    The tested 0bfd:0017 Kvaser Memorator Professional HS/HS FW 2.0.50 and
    0bfd:0124 Kvaser Mini PCI Express 2xHS FW 4.18.778 do not seem to send
    any unsolicited events when error counters decrease or when the device
    transitions from ERROR_PASSIVE to ERROR_ACTIVE (or WARNING).
    
    This causes the interface to e.g. indefinitely stay in the ERROR_PASSIVE
    state.
    
    Fix that by asking for chip state (inc. counters) event every 0.5 secs
    when error counters are non-zero.
    
    Since there are non-error-counter devices, also always poll in
    ERROR_PASSIVE even if the counters show zero.
    
    Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
    Tested-by: Jimmy Assarsson <extja@kvaser.com>
    Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://lore.kernel.org/all/20221010185237.319219-7-extja@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb_leaf: Fix wrong CAN state after stopping [+ + +]
Author: Anssi Hannula <anssi.hannula@bitwise.fi>
Date:   Mon Oct 10 20:52:33 2022 +0200

    can: kvaser_usb_leaf: Fix wrong CAN state after stopping
    
    [ Upstream commit a11249acf802341294557895d8e5f6aef080253f ]
    
    0bfd:0124 Kvaser Mini PCI Express 2xHS FW 4.18.778 sends a
    CMD_CHIP_STATE_EVENT indicating bus-off after stopping the device,
    causing a stopped device to appear as CAN_STATE_BUS_OFF instead of
    CAN_STATE_STOPPED.
    
    Fix that by not handling error events on stopped devices.
    
    Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
    Tested-by: Jimmy Assarsson <extja@kvaser.com>
    Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://lore.kernel.org/all/20221010185237.319219-8-extja@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: kvaser_usb_leaf: Set Warning state even without bus errors [+ + +]
Author: Anssi Hannula <anssi.hannula@bitwise.fi>
Date:   Mon Oct 10 20:52:31 2022 +0200

    can: kvaser_usb_leaf: Set Warning state even without bus errors
    
    [ Upstream commit df1b7af2761b935f63b4a53e789d41ed859edf61 ]
    
    kvaser_usb_leaf_rx_error_update_can_state() sets error state according
    to error counters when the hardware does not indicate a specific state
    directly.
    
    However, this is currently gated behind a check for
    M16C_STATE_BUS_ERROR which does not always seem to be set when error
    counters are increasing, and may not be set when error counters are
    decreasing.
    
    This causes the CAN_STATE_ERROR_WARNING state to not be set in some
    cases even when appropriate.
    
    Change the code to set error state from counters even without
    M16C_STATE_BUS_ERROR.
    
    The Error-Passive case seems superfluous as it is already set via
    M16C_STATE_BUS_PASSIVE flag above, but it is kept for now.
    
    Tested with 0bfd:0124 Kvaser Mini PCI Express 2xHS FW 4.18.778.
    
    Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices")
    Tested-by: Jimmy Assarsson <extja@kvaser.com>
    Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi>
    Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
    Link: https://lore.kernel.org/all/20221010185237.319219-6-extja@kvaser.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: tcan4x5x: Remove invalid write in clear_interrupts [+ + +]
Author: Markus Schneider-Pargmann <msp@baylibre.com>
Date:   Tue Dec 6 12:57:25 2022 +0100

    can: tcan4x5x: Remove invalid write in clear_interrupts
    
    [ Upstream commit 40c9e4f676abbe194541d88e796341c92d5a13c0 ]
    
    Register 0x824 TCAN4X5X_MCAN_INT_REG is a read-only register. Any writes
    to this register do not have any effect.
    
    Remove this write. The m_can driver aldready clears the interrupts in
    m_can_isr() by writing to M_CAN_IR which is translated to register
    0x1050 which is a writable version of this register.
    
    Fixes: 5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel")
    Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
    Link: https://lore.kernel.org/all/20221206115728.1056014-9-msp@baylibre.com
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
chardev: fix error handling in cdev_device_add() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Dec 2 11:02:37 2022 +0800

    chardev: fix error handling in cdev_device_add()
    
    [ Upstream commit 11fa7fefe3d8fac7da56bc9aa3dd5fb3081ca797 ]
    
    While doing fault injection test, I got the following report:
    
    ------------[ cut here ]------------
    kobject: '(null)' (0000000039956980): is not initialized, yet kobject_put() is being called.
    WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0
    CPU: 3 PID: 6306 Comm: 283 Tainted: G        W          6.1.0-rc2-00005-g307c1086d7c9 #1253
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
    RIP: 0010:kobject_put+0x23d/0x4e0
    Call Trace:
     <TASK>
     cdev_device_add+0x15e/0x1b0
     __iio_device_register+0x13b4/0x1af0 [industrialio]
     __devm_iio_device_register+0x22/0x90 [industrialio]
     max517_probe+0x3d8/0x6b4 [max517]
     i2c_device_probe+0xa81/0xc00
    
    When device_add() is injected fault and returns error, if dev->devt is not set,
    cdev_add() is not called, cdev_del() is not needed. Fix this by checking dev->devt
    in error path.
    
    Fixes: 233ed09d7fda ("chardev: add helper function to register char devs with a struct device")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221202030237.520280-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cifs: fix confusing debug message [+ + +]
Author: Paulo Alcantara <pc@cjr.nz>
Date:   Fri Dec 16 22:03:41 2022 -0300

    cifs: fix confusing debug message
    
    commit a85ceafd41927e41a4103d228a993df7edd8823b upstream.
    
    Since rc was initialised to -ENOMEM in cifs_get_smb_ses(), when an
    existing smb session was found, free_xid() would be called and then
    print
    
      CIFS: fs/cifs/connect.c: Existing tcp session with server found
      CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 44 with uid: 0
      CIFS: fs/cifs/connect.c: Existing smb sess found (status=1)
      CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 44) rc = -12
    
    Fix this by initialising rc to 0 and then let free_xid() print this
    instead
    
      CIFS: fs/cifs/connect.c: Existing tcp session with server found
      CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 14 with uid: 0
      CIFS: fs/cifs/connect.c: Existing smb sess found (status=1)
      CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 14) rc = 0
    
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cifs: fix missing display of three mount options [+ + +]
Author: Steve French <stfrench@microsoft.com>
Date:   Sun Dec 11 13:54:21 2022 -0600

    cifs: fix missing display of three mount options
    
    commit 2bfd81043e944af0e52835ef6d9b41795af22341 upstream.
    
    Three mount options: "tcpnodelay" and "noautotune" and "noblocksend"
    were not displayed when passed in on cifs/smb3 mounts (e.g. displayed
    in /proc/mounts e.g.).  No change to defaults so these are not
    displayed if not specified on mount.
    
    Cc: stable@vger.kernel.org
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cifs: fix oops during encryption [+ + +]
Author: Paulo Alcantara <pc@cjr.nz>
Date:   Sun Dec 11 18:18:55 2022 -0300

    cifs: fix oops during encryption
    
    [ Upstream commit f7f291e14dde32a07b1f0aa06921d28f875a7b54 ]
    
    When running xfstests against Azure the following oops occurred on an
    arm64 system
    
      Unable to handle kernel write to read-only memory at virtual address
      ffff0001221cf000
      Mem abort info:
        ESR = 0x9600004f
        EC = 0x25: DABT (current EL), IL = 32 bits
        SET = 0, FnV = 0
        EA = 0, S1PTW = 0
        FSC = 0x0f: level 3 permission fault
      Data abort info:
        ISV = 0, ISS = 0x0000004f
        CM = 0, WnR = 1
      swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000294f3000
      [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003,
      pud=18000001ff82e003, pmd=18000001ff71d003, pte=00600001221cf787
      Internal error: Oops: 9600004f [#1] PREEMPT SMP
      ...
      pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
      pc : __memcpy+0x40/0x230
      lr : scatterwalk_copychunks+0xe0/0x200
      sp : ffff800014e92de0
      x29: ffff800014e92de0 x28: ffff000114f9de80 x27: 0000000000000008
      x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008
      x23: 0000000000000001 x22: 0000040000000000 x21: ffff000000000000
      x20: 0000000000000001 x19: ffff0001037c4488 x18: 0000000000000014
      x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058
      x14: 0000000000000001 x13: 0000000000000008 x12: ffff000114f2e590
      x11: ffffffffffffffff x10: 0000040000000000 x9 : ffff8000105c3580
      x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005
      x5 : ffff0001221cf008 x4 : ffff0001037c4490 x3 : 0000000000000001
      x2 : 0000000000000008 x1 : ffff0001037c4488 x0 : ffff0001221cf000
      Call trace:
       __memcpy+0x40/0x230
       scatterwalk_map_and_copy+0x98/0x100
       crypto_ccm_encrypt+0x150/0x180
       crypto_aead_encrypt+0x2c/0x40
       crypt_message+0x750/0x880
       smb3_init_transform_rq+0x298/0x340
       smb_send_rqst.part.11+0xd8/0x180
       smb_send_rqst+0x3c/0x100
       compound_send_recv+0x534/0xbc0
       smb2_query_info_compound+0x32c/0x440
       smb2_set_ea+0x438/0x4c0
       cifs_xattr_set+0x5d4/0x7c0
    
    This is because in scatterwalk_copychunks(), we attempted to write to
    a buffer (@sign) that was allocated in the stack (vmalloc area) by
    crypt_message() and thus accessing its remaining 8 (x2) bytes ended up
    crossing a page boundary.
    
    To simply fix it, we could just pass @sign kmalloc'd from
    crypt_message() and then we're done.  Luckily, we don't seem to pass
    any other vmalloc'd buffers in smb_rqst::rq_iov...
    
    Instead, let's map the correct pages and offsets from vmalloc buffers
    as well in cifs_sg_set_buf() and then avoiding such oopses.
    
    Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Cc: stable@vger.kernel.org
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cifs: Fix uninitialized memory read for smb311 posix symlink create [+ + +]
Author: Volker Lendecke <vl@samba.org>
Date:   Wed Jan 11 12:37:58 2023 +0100

    cifs: Fix uninitialized memory read for smb311 posix symlink create
    
    commit a152d05ae4a71d802d50cf9177dba34e8bb09f68 upstream.
    
    If smb311 posix is enabled, we send the intended mode for file
    creation in the posix create context. Instead of using what's there on
    the stack, create the mfsymlink file with 0644.
    
    Fixes: ce558b0e17f8a ("smb3: Add posix create context for smb3.11 posix mounts")
    Cc: stable@vger.kernel.org
    Signed-off-by: Volker Lendecke <vl@samba.org>
    Reviewed-by: Tom Talpey <tom@talpey.com>
    Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
class: fix possible memory leak in __class_register() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Oct 26 16:28:03 2022 +0800

    class: fix possible memory leak in __class_register()
    
    [ Upstream commit 8c3e8a6bdb5253b97ad532570f8b5db5f7a06407 ]
    
    If class_add_groups() returns error, the 'cp->subsys' need be
    unregister, and the 'cp' need be freed.
    
    We can not call kset_unregister() here, because the 'cls' will
    be freed in callback function class_release() and it's also
    freed in caller's error path, it will cause double free.
    
    So fix this by calling kobject_del() and kfree_const(name) to
    cleanup kobject. Besides, call kfree() to free the 'cp'.
    
    Fault injection test can trigger this:
    
    unreferenced object 0xffff888102fa8190 (size 8):
      comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s)
      hex dump (first 8 bytes):
        70 6b 74 63 64 76 64 00                          pktcdvd.
      backtrace:
        [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320
        [<000000005e4d70bc>] kstrdup+0x3a/0x70
        [<00000000c2e5e85a>] kstrdup_const+0x68/0x80
        [<000000000049a8c7>] kvasprintf_const+0x10b/0x190
        [<0000000029123163>] kobject_set_name_vargs+0x56/0x150
        [<00000000747219c9>] kobject_set_name+0xab/0xe0
        [<0000000005f1ea4e>] __class_register+0x15c/0x49a
    
    unreferenced object 0xffff888037274000 (size 1024):
      comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s)
      hex dump (first 32 bytes):
        00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff  .@'7.....@'7....
        00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
      backtrace:
        [<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0
        [<00000000ecf3dd95>] __class_register+0x86/0x49a
    
    Fixes: ced6473e7486 ("driver core: class: add class_groups support")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221026082803.3458760-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: imx8mn: correct the usb1_ctrl parent to be usb_bus [+ + +]
Author: Li Jun <jun.li@nxp.com>
Date:   Thu Dec 5 08:06:17 2019 +0000

    clk: imx8mn: correct the usb1_ctrl parent to be usb_bus
    
    [ Upstream commit 134d43bb1ff09a696996f16ed8b28d404b770c8a ]
    
    Per latest imx8mn datasheet of CCM, the parent of usb1_ctrl_root_clk
    should be usb_bus.
    
    Signed-off-by: Li Jun <jun.li@nxp.com>
    Signed-off-by: Shawn Guo <shawnguo@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: imx: replace osc_hdmi with dummy [+ + +]
Author: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Date:   Thu Nov 17 12:36:34 2022 +0100

    clk: imx: replace osc_hdmi with dummy
    
    [ Upstream commit e7fa365ff66f16772dc06b480cd78f858d10856b ]
    
    There is no occurrence of the hdmi oscillator in the reference manual
    (document IMX8MNRM Rev 2, 07/2022). Further, if we consider the indexes
    76-81 and 134 of the "Clock Root" table of chapter 5 of the RM, there is
    no entry for the source select bits 101b, which is the setting referenced
    by "osc_hdmi".
    Fix by renaming "osc_hdmi" with "dummy", a clock which has already been
    used for missing source select bits.
    
    Tested on the BSH SystemMaster (SMM) S2 board.
    
    Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver")
    Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
    Acked-by: Marco Felsch <m.felsch@pengutronix.de>
    Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
    Link: https://lore.kernel.org/r/20221117113637.1978703-3-dario.binacchi@amarulasolutions.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: clk-krait: fix wrong div2 functions [+ + +]
Author: Christian Marangi <ansuelsmth@gmail.com>
Date:   Tue Nov 8 22:56:25 2022 +0100

    clk: qcom: clk-krait: fix wrong div2 functions
    
    [ Upstream commit d676d3a3717cf726d3affedbe5ba98fc4ccad7b3 ]
    
    Currently div2 value is applied to the wrong bits. This is caused by a
    bug in the code where the shift is done only for lpl, for anything
    else the mask is not shifted to the correct bits.
    
    Fix this by correctly shift if lpl is not supported.
    
    Fixes: 4d7dc77babfe ("clk: qcom: Add support for Krait clocks")
    Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221108215625.30186-1-ansuelsmth@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: renesas: r9a06g032: Repair grave increment error [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Fri Oct 28 13:38:34 2022 +0200

    clk: renesas: r9a06g032: Repair grave increment error
    
    [ Upstream commit 02693e11611e082e3c4d8653e8af028e43d31164 ]
    
    If condition (clkspec.np != pd->dev.of_node) is true, then the driver
    ends up in an endless loop, forever, locking up the machine.
    
    Fixes: aad03a66f902 ("clk: renesas: r9a06g032: Add clock domain support")
    Reviewed-by: Ralph Siemsen <ralph.siemsen@linaro.org>
    Signed-off-by: Marek Vasut <marex@denx.de>
    Reviewed-by: Gareth Williams <gareth.williams.jx@renesas.com>
    Link: https://lore.kernel.org/r/20221028113834.7496-1-marex@denx.de
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: rockchip: Fix memory leak in rockchip_clk_register_pll() [+ + +]
Author: Xiu Jianfeng <xiujianfeng@huawei.com>
Date:   Wed Nov 23 17:12:01 2022 +0800

    clk: rockchip: Fix memory leak in rockchip_clk_register_pll()
    
    [ Upstream commit 739a6a6bbdb793bd57938cb24aa5a6df89983546 ]
    
    If clk_register() fails, @pll->rate_table may have allocated memory by
    kmemdup(), so it needs to be freed, otherwise will cause memory leak
    issue, this patch fixes it.
    
    Fixes: 90c590254051 ("clk: rockchip: add clock type for pll clocks and pll used on rk3066")
    Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
    Link: https://lore.kernel.org/r/20221123091201.199819-1-xiujianfeng@huawei.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: samsung: Fix memory leak in _samsung_clk_register_pll() [+ + +]
Author: Xiu Jianfeng <xiujianfeng@huawei.com>
Date:   Wed Nov 23 11:20:15 2022 +0800

    clk: samsung: Fix memory leak in _samsung_clk_register_pll()
    
    [ Upstream commit 5174e5b0d1b669a489524192b6adcbb3c54ebc72 ]
    
    If clk_register() fails, @pll->rate_table may have allocated memory by
    kmemdup(), so it needs to be freed, otherwise will cause memory leak
    issue, this patch fixes it.
    
    Fixes: 3ff6e0d8d64d ("clk: samsung: Add support to register rate_table for samsung plls")
    Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
    Link: https://lore.kernel.org/r/20221123032015.63980-1-xiujianfeng@huawei.com
    Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: socfpga: clk-pll: Remove unused variable 'rc' [+ + +]
Author: Lee Jones <lee.jones@linaro.org>
Date:   Wed Jan 20 09:30:27 2021 +0000

    clk: socfpga: clk-pll: Remove unused variable 'rc'
    
    [ Upstream commit 75fddccbca32349570b2d53955982b4117fa5515 ]
    
    Fixes the following W=1 kernel build warning(s):
    
     drivers/clk/socfpga/clk-pll.c: In function ‘__socfpga_pll_init’:
     drivers/clk/socfpga/clk-pll.c:83:6: warning: variable ‘rc’ set but not used [-Wunused-but-set-variable]
    
    Cc: Dinh Nguyen <dinguyen@kernel.org>
    Cc: Michael Turquette <mturquette@baylibre.com>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: linux-clk@vger.kernel.org
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Link: https://lore.kernel.org/r/20210120093040.1719407-8-lee.jones@linaro.org
    Acked-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 0b8ba891ad4d ("clk: socfpga: Fix memory leak in socfpga_gate_init()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: socfpga: Fix memory leak in socfpga_gate_init() [+ + +]
Author: Xiu Jianfeng <xiujianfeng@huawei.com>
Date:   Wed Nov 23 11:16:22 2022 +0800

    clk: socfpga: Fix memory leak in socfpga_gate_init()
    
    [ Upstream commit 0b8ba891ad4d1ef6bfa4c72efc83f9f9f855f68b ]
    
    Free @socfpga_clk and @ops on the error path to avoid memory leak issue.
    
    Fixes: a30a67be7b6e ("clk: socfpga: Don't have get_parent for single parent ops")
    Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
    Link: https://lore.kernel.org/r/20221123031622.63171-1-xiujianfeng@huawei.com
    Acked-by: Dinh Nguyen <dinguyen@kernel.org>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: socfpga: use clk_hw_register for a5/c5 [+ + +]
Author: Dinh Nguyen <dinguyen@kernel.org>
Date:   Tue Mar 2 15:41:49 2021 -0600

    clk: socfpga: use clk_hw_register for a5/c5
    
    [ Upstream commit 2c2b9c6067170de2a63e7e3d9f5bb205b870de7c ]
    
    As recommended by Stephen Boyd, convert the cyclone5/arria5 clock driver
    to use the clk_hw registration method.
    
    Suggested-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
    Link: https://lore.kernel.org/r/20210302214151.1333447-1-dinguyen@kernel.org
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Stable-dep-of: 0b8ba891ad4d ("clk: socfpga: Fix memory leak in socfpga_gate_init()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: st: Fix memory leak in st_of_quadfs_setup() [+ + +]
Author: Xiu Jianfeng <xiujianfeng@huawei.com>
Date:   Tue Nov 22 21:36:14 2022 +0800

    clk: st: Fix memory leak in st_of_quadfs_setup()
    
    [ Upstream commit cfd3ffb36f0d566846163118651d868e607300ba ]
    
    If st_clk_register_quadfs_pll() fails, @lock should be freed before goto
    @err_exit, otherwise will cause meory leak issue, fix it.
    
    Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
    Link: https://lore.kernel.org/r/20221122133614.184910-1-xiujianfeng@huawei.com
    Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clocksource/drivers/sh_cmt: Make sure channel clock supply is enabled [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Dec 10 20:46:48 2020 +0100

    clocksource/drivers/sh_cmt: Make sure channel clock supply is enabled
    
    [ Upstream commit 2a97d55333e4299f32c98cca6dc5c4db1c5855fc ]
    
    The Renesas Compare Match Timer 0 and 1 (CMT0/1) variants have a
    register to control the clock supply to the individual channels.
    Currently the driver does not touch this register, and relies on the
    documented initial value, which has the clock supply enabled for all
    channels present.
    
    However, when Linux starts on the APE6-EVM development board, only the
    clock supply to the first CMT1 channel is enabled.  Hence the first
    channel (used as a clockevent) works, while the second channel (used as
    a clocksource) does not.  Note that the default system clocksource is
    the Cortex-A15 architectured timer, and the user needs to manually
    switch to the CMT1 clocksource to trigger the broken behavior.
    
    Fix this by removing the fragile dependency on implicit reset and/or
    boot loader state, and by enabling the clock supply explicitly for all
    channels used instead.  This requires postponing the clk_disable() call,
    else the timer's registers cannot be accessed in sh_cmt_setup_channel().
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
    Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
    Link: https://lore.kernel.org/r/20201210194648.2901899-1-geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
configfs: fix possible memory leak in configfs_create_dir() [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Mon Oct 17 09:42:30 2022 +0800

    configfs: fix possible memory leak in configfs_create_dir()
    
    [ Upstream commit c65234b283a65cfbfc94619655e820a5e55199eb ]
    
    kmemleak reported memory leaks in configfs_create_dir():
    
    unreferenced object 0xffff888009f6af00 (size 192):
      comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)
      backtrace:
        kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
        new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163)
        configfs_register_subsystem (fs/configfs/dir.c:1857)
        basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
        do_one_initcall (init/main.c:1296)
        do_init_module (kernel/module/main.c:2455)
        ...
    
    unreferenced object 0xffff888003ba7180 (size 96):
      comm "modprobe", pid 3777, jiffies 4295537735 (age 233.784s)
      backtrace:
        kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
        configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194)
        configfs_make_dirent (fs/configfs/dir.c:248)
        configfs_create_dir (fs/configfs/dir.c:296)
        configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852)
        configfs_register_subsystem (fs/configfs/dir.c:1881)
        basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
        do_one_initcall (init/main.c:1296)
        do_init_module (kernel/module/main.c:2455)
        ...
    
    This is because the refcount is not correct in configfs_make_dirent().
    For normal stage, the refcount is changing as:
    
    configfs_register_subsystem()
      configfs_create_dir()
        configfs_make_dirent()
          configfs_new_dirent() # set s_count = 1
          dentry->d_fsdata = configfs_get(sd); # s_count = 2
    ...
    configfs_unregister_subsystem()
      configfs_remove_dir()
        remove_dir()
          configfs_remove_dirent() # s_count = 1
        dput() ...
          *dentry_unlink_inode()*
            configfs_d_iput() # s_count = 0, release
    
    However, if we failed in configfs_create():
    
    configfs_register_subsystem()
      configfs_create_dir()
        configfs_make_dirent() # s_count = 2
        ...
        configfs_create() # fail
        ->out_remove:
        configfs_remove_dirent(dentry)
          configfs_put(sd) # s_count = 1
          return PTR_ERR(inode);
    
    There is no inode in the error path, so the configfs_d_iput() is lost
    and makes sd and fragment memory leaked.
    
    To fix this, when we failed in configfs_create(), manually call
    configfs_put(sd) to keep the refcount correct.
    
    Fixes: 7063fbf22611 ("[PATCH] configfs: User-driven configuration filesystem")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
counter: stm32-lptimer-cnt: fix the check on arr and cmp registers update [+ + +]
Author: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Date:   Wed Nov 23 14:36:09 2022 +0100

    counter: stm32-lptimer-cnt: fix the check on arr and cmp registers update
    
    [ Upstream commit fd5ac974fc25feed084c2d1599d0dddb4e0556bc ]
    
    The ARR (auto reload register) and CMP (compare) registers are
    successively written. The status bits to check the update of these
    registers are polled together with regmap_read_poll_timeout().
    The condition to end the loop may become true, even if one of the register
    isn't correctly updated.
    So ensure both status bits are set before clearing them.
    
    Fixes: d8958824cf07 ("iio: counter: Add support for STM32 LPTimer")
    Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Link: https://lore.kernel.org/r/20221123133609.465614-1-fabrice.gasnier@foss.st.com/
    Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cpufreq: amd_freq_sensitivity: Add missing pci_dev_put() [+ + +]
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Wed Nov 16 19:33:39 2022 +0800

    cpufreq: amd_freq_sensitivity: Add missing pci_dev_put()
    
    [ Upstream commit 91fda1f88c0968f1491ab150bb01690525af150a ]
    
    pci_get_device() will increase the reference count for the returned
    pci_dev. We need to use pci_dev_put() to decrease the reference count
    after using pci_get_device(). Let's add it.
    
    Fixes: 59a3b3a8db16 ("cpufreq: AMD: Ignore the check for ProcFeedback in ST/CZ")
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cpufreq: Init completion before kobject_init_and_add() [+ + +]
Author: Yongqiang Liu <liuyongqiang13@huawei.com>
Date:   Thu Nov 10 14:23:07 2022 +0000

    cpufreq: Init completion before kobject_init_and_add()
    
    commit 5c51054896bcce1d33d39fead2af73fec24f40b6 upstream.
    
    In cpufreq_policy_alloc(), it will call uninitialed completion in
    cpufreq_sysfs_release() when kobject_init_and_add() fails. And
    that will cause a crash such as the following page fault in complete:
    
    BUG: unable to handle page fault for address: fffffffffffffff8
    [..]
    RIP: 0010:complete+0x98/0x1f0
    [..]
    Call Trace:
     kobject_put+0x1be/0x4c0
     cpufreq_online.cold+0xee/0x1fd
     cpufreq_add_dev+0x183/0x1e0
     subsys_interface_register+0x3f5/0x4e0
     cpufreq_register_driver+0x3b7/0x670
     acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq]
     do_one_initcall+0x13d/0x780
     do_init_module+0x1c3/0x630
     load_module+0x6e67/0x73b0
     __do_sys_finit_module+0x181/0x240
     do_syscall_64+0x35/0x80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: 4ebe36c94aed ("cpufreq: Fix kobject memleak")
    Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: 5.2+ <stable@vger.kernel.org> # 5.2+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cpuidle: dt: Return the correct numbers of parsed idle states [+ + +]
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Fri Oct 21 17:10:12 2022 +0200

    cpuidle: dt: Return the correct numbers of parsed idle states
    
    [ Upstream commit ee3c2c8ad6ba6785f14a60e4081d7c82e88162a2 ]
    
    While we correctly skips to initialize an idle state from a disabled idle
    state node in DT, the returned value from dt_init_idle_driver() don't get
    adjusted accordingly. Instead the number of found idle state nodes are
    returned, while the callers are expecting the number of successfully
    initialized idle states from DT.
    
    This leads to cpuidle drivers unnecessarily continues to initialize their
    idle state specific data. Moreover, in the case when all idle states have
    been disabled in DT, we would end up registering a cpuidle driver, rather
    than relying on the default arch specific idle call.
    
    Fixes: 9f14da345599 ("drivers: cpuidle: implement DT based idle states infrastructure")
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: ccree - Make cc_debugfs_global_fini() available for module init function [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Mon Nov 21 18:22:36 2022 +0100

    crypto: ccree - Make cc_debugfs_global_fini() available for module init function
    
    [ Upstream commit 8e96729fc26c8967db45a3fb7a60387619f77a22 ]
    
    ccree_init() calls cc_debugfs_global_fini(), the former is an init
    function and the latter an exit function though.
    
    A modular build emits:
    
            WARNING: modpost: drivers/crypto/ccree/ccree.o: section mismatch in reference: init_module (section: .init.text) -> cc_debugfs_global_fini (section: .exit.text)
    
    (with CONFIG_DEBUG_SECTION_MISMATCH=y).
    
    Fixes: 4f1c596df706 ("crypto: ccree - Remove debugfs when platform_driver_register failed")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: ccree - Remove debugfs when platform_driver_register failed [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Tue Nov 8 16:29:12 2022 +0800

    crypto: ccree - Remove debugfs when platform_driver_register failed
    
    [ Upstream commit 4f1c596df706c9aca662b6c214fad84047ae2a97 ]
    
    When platform_driver_register failed, we need to remove debugfs,
    which will caused a resource leak, fix it.
    
    Failed logs as follows:
    [   32.606488] debugfs: Directory 'ccree' with parent '/' already present!
    
    Fixes: 4c3f97276e15 ("crypto: ccree - introduce CryptoCell driver")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: ccree - swap SHA384 and SHA512 larval hashes at build time [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Tue Feb 11 19:18:59 2020 +0100

    crypto: ccree - swap SHA384 and SHA512 larval hashes at build time
    
    [ Upstream commit f08b58501c74d6ec0828b55a0d4e0b2e840c2b9e ]
    
    Due to the way the hardware works, every double word in the SHA384 and
    SHA512 larval hashes must be swapped.  Currently this is done at run
    time, during driver initialization.
    
    However, this swapping can easily be done at build time.  Treating each
    double word as two words has the benefit of changing the larval hashes'
    types from u64[] to u32[], like for all other hashes, and allows
    dropping the casts and size doublings when calling cc_set_sram_desc().
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: 4f1c596df706 ("crypto: ccree - Remove debugfs when platform_driver_register failed")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: img-hash - Fix variable dereferenced before check 'hdev->req' [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Thu Dec 1 14:25:26 2022 +0800

    crypto: img-hash - Fix variable dereferenced before check 'hdev->req'
    
    [ Upstream commit 04ba54e5af8f8f0137b08cb51a0b3a2e1ea46c94 ]
    
    Smatch report warning as follows:
    
    drivers/crypto/img-hash.c:366 img_hash_dma_task() warn: variable
    dereferenced before check 'hdev->req'
    
    Variable dereferenced should be done after check 'hdev->req',
    fix it.
    
    Fixes: d358f1abbf71 ("crypto: img-hash - Add Imagination Technologies hw hash accelerator")
    Fixes: 10badea259fa ("crypto: img-hash - Fix null pointer exception")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: n2 - add missing hash statesize [+ + +]
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Thu Oct 6 04:34:19 2022 +0000

    crypto: n2 - add missing hash statesize
    
    commit 76a4e874593543a2dff91d249c95bac728df2774 upstream.
    
    Add missing statesize to hash templates.
    This is mandatory otherwise no algorithms can be registered as the core
    requires statesize to be set.
    
    CC: stable@kernel.org # 4.3+
    Reported-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Tested-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
    Fixes: 0a625fd2abaa ("crypto: n2 - Add Niagara2 crypto driver")
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

crypto: omap-sham - Use pm_runtime_resume_and_get() in omap_sham_probe() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Thu Nov 24 14:49:40 2022 +0800

    crypto: omap-sham - Use pm_runtime_resume_and_get() in omap_sham_probe()
    
    [ Upstream commit 7bcceb4c9896b1b672b636ae70fe75110d6bf1ad ]
    
    omap_sham_probe() calls pm_runtime_get_sync() and calls
    pm_runtime_put_sync() latter to put usage_counter. However,
    pm_runtime_get_sync() will increment usage_counter even it failed. Fix
    it by replacing it with pm_runtime_resume_and_get() to keep usage
    counter balanced.
    
    Fixes: b359f034c8bf ("crypto: omap-sham - Convert to use pm_runtime API")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Acked-by: Mark Greer <mgreer@animalcreek.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: tcrypt - Fix multibuffer skcipher speed test mem leak [+ + +]
Author: Zhang Yiqun <zhangyiqun@phytium.com.cn>
Date:   Wed Nov 16 17:24:11 2022 +0800

    crypto: tcrypt - Fix multibuffer skcipher speed test mem leak
    
    [ Upstream commit 1aa33fc8d4032227253ceb736f47c52b859d9683 ]
    
    In the past, the data for mb-skcipher test has been allocated
    twice, that means the first allcated memory area is without
    free, which may cause a potential memory leakage. So this
    patch is to remove one allocation to fix this error.
    
    Fixes: e161c5930c15 ("crypto: tcrypt - add multibuf skcipher...")
    Signed-off-by: Zhang Yiqun <zhangyiqun@phytium.com.cn>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Nov 11 22:54:39 2022 +0800

    cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()
    
    [ Upstream commit 61c80d1c3833e196256fb060382db94f24d3d9a7 ]
    
    If device_register() fails in cxl_register_afu|adapter(), the device
    is not added, device_unregister() can not be called in the error path,
    otherwise it will cause a null-ptr-deref because of removing not added
    device.
    
    As comment of device_register() says, it should use put_device() to give
    up the reference in the error path. So split device_unregister() into
    device_del() and put_device(), then goes to put dev when register fails.
    
    Fixes: 14baf4d9c739 ("cxl: Add guest-specific code")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
    Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
    Link: https://lore.kernel.org/r/20221111145440.2426970-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Nov 11 22:54:40 2022 +0800

    cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()
    
    [ Upstream commit 02cd3032b154fa02fdf90e7467abaeed889330b2 ]
    
    If device_register() fails in cxl_pci_afu|adapter(), the device
    is not added, device_unregister() can not be called in the error
    path, otherwise it will cause a null-ptr-deref because of removing
    not added device.
    
    As comment of device_register() says, it should use put_device() to give
    up the reference in the error path. So split device_unregister() into
    device_del() and put_device(), then goes to put dev when register fails.
    
    Fixes: f204e0b8cedd ("cxl: Driver code for powernv PCIe based cards for userspace access")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
    Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
    Link: https://lore.kernel.org/r/20221111145440.2426970-2-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

cxl: Fix refcount leak in cxl_calc_capp_routing [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Sun Jun 5 10:00:38 2022 +0400

    cxl: Fix refcount leak in cxl_calc_capp_routing
    
    [ Upstream commit 1d09697ff22908ae487fc8c4fbde1811732be523 ]
    
    of_get_next_parent() returns a node pointer with refcount incremented,
    we should use of_node_put() on it when not need anymore.
    This function only calls of_node_put() in normal path,
    missing it in the error path.
    Add missing of_node_put() to avoid refcount leak.
    
    Fixes: f24be42aab37 ("cxl: Add psl9 specific code")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
    Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220605060038.62217-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
debugfs: fix error when writing negative value to atomic_t debugfs file [+ + +]
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Tue Sep 20 02:24:18 2022 +0900

    debugfs: fix error when writing negative value to atomic_t debugfs file
    
    [ Upstream commit d472cf797c4e268613dbce5ec9b95d0bcae19ecb ]
    
    The simple attribute files do not accept a negative value since the commit
    488dac0c9237 ("libfs: fix error cast of negative value in
    simple_attr_write()"), so we have to use a 64-bit value to write a
    negative value for a debugfs file created by debugfs_create_atomic_t().
    
    This restores the previous behaviour by introducing
    DEFINE_DEBUGFS_ATTRIBUTE_SIGNED for a signed value.
    
    Link: https://lkml.kernel.org/r/20220919172418.45257-4-akinobu.mita@gmail.com
    Fixes: 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()")
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Reported-by: Zhao Gongyi <zhaogongyi@huawei.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Rafael J. Wysocki <rafael@kernel.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Wei Yongjun <weiyongjun1@huawei.com>
    Cc: Yicong Yang <yangyicong@hisilicon.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
device_cgroup: Roll back to original exceptions after copy failure [+ + +]
Author: Wang Weiyang <wangweiyang2@huawei.com>
Date:   Tue Oct 25 19:31:01 2022 +0800

    device_cgroup: Roll back to original exceptions after copy failure
    
    commit e68bfbd3b3c3a0ec3cf8c230996ad8cabe90322f upstream.
    
    When add the 'a *:* rwm' entry to devcgroup A's whitelist, at first A's
    exceptions will be cleaned and A's behavior is changed to
    DEVCG_DEFAULT_ALLOW. Then parent's exceptions will be copyed to A's
    whitelist. If copy failure occurs, just return leaving A to grant
    permissions to all devices. And A may grant more permissions than
    parent.
    
    Backup A's whitelist and recover original exceptions after copy
    failure.
    
    Cc: stable@vger.kernel.org
    Fixes: 4cef7299b478 ("device_cgroup: add proper checking when changing default behavior")
    Signed-off-by: Wang Weiyang <wangweiyang2@huawei.com>
    Reviewed-by: Aristeu Rozanski <aris@redhat.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm cache: Fix ABBA deadlock between shrink_slab and dm_cache_metadata_abort [+ + +]
Author: Mike Snitzer <snitzer@kernel.org>
Date:   Wed Nov 30 13:26:32 2022 -0500

    dm cache: Fix ABBA deadlock between shrink_slab and dm_cache_metadata_abort
    
    commit 352b837a5541690d4f843819028cf2b8be83d424 upstream.
    
    Same ABBA deadlock pattern fixed in commit 4b60f452ec51 ("dm thin: Fix
    ABBA deadlock between shrink_slab and dm_pool_abort_metadata") to
    DM-cache's metadata.
    
    Reported-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Cc: stable@vger.kernel.org
    Fixes: 028ae9f76f29 ("dm cache: add fail io mode and needs_check flag")
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dm cache: Fix UAF in destroy() [+ + +]
Author: Luo Meng <luomeng12@huawei.com>
Date:   Tue Nov 29 10:48:49 2022 +0800

    dm cache: Fix UAF in destroy()
    
    commit 6a459d8edbdbe7b24db42a5a9f21e6aa9e00c2aa upstream.
    
    Dm_cache also has the same UAF problem when dm_resume()
    and dm_destroy() are concurrent.
    
    Therefore, cancelling timer again in destroy().
    
    Cc: stable@vger.kernel.org
    Fixes: c6b4fcbad044e ("dm: add cache target")
    Signed-off-by: Luo Meng <luomeng12@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dm cache: set needs_check flag after aborting metadata [+ + +]
Author: Mike Snitzer <snitzer@kernel.org>
Date:   Wed Nov 30 14:02:47 2022 -0500

    dm cache: set needs_check flag after aborting metadata
    
    commit 6b9973861cb2e96dcd0bb0f1baddc5c034207c5c upstream.
    
    Otherwise the commit that will be aborted will be associated with the
    metadata objects that will be torn down.  Must write needs_check flag
    to metadata with a reset block manager.
    
    Found through code-inspection (and compared against dm-thin.c).
    
    Cc: stable@vger.kernel.org
    Fixes: 028ae9f76f29 ("dm cache: add fail io mode and needs_check flag")
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm clone: Fix UAF in clone_dtr() [+ + +]
Author: Luo Meng <luomeng12@huawei.com>
Date:   Tue Nov 29 10:48:48 2022 +0800

    dm clone: Fix UAF in clone_dtr()
    
    commit e4b5957c6f749a501c464f92792f1c8e26b61a94 upstream.
    
    Dm_clone also has the same UAF problem when dm_resume()
    and dm_destroy() are concurrent.
    
    Therefore, cancelling timer again in clone_dtr().
    
    Cc: stable@vger.kernel.org
    Fixes: 7431b7835f554 ("dm: add clone target")
    Signed-off-by: Luo Meng <luomeng12@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm integrity: Fix UAF in dm_integrity_dtr() [+ + +]
Author: Luo Meng <luomeng12@huawei.com>
Date:   Tue Nov 29 10:48:50 2022 +0800

    dm integrity: Fix UAF in dm_integrity_dtr()
    
    commit f50cb2cbabd6c4a60add93d72451728f86e4791c upstream.
    
    Dm_integrity also has the same UAF problem when dm_resume()
    and dm_destroy() are concurrent.
    
    Therefore, cancelling timer again in dm_integrity_dtr().
    
    Cc: stable@vger.kernel.org
    Fixes: 7eada909bfd7a ("dm: add integrity target")
    Signed-off-by: Luo Meng <luomeng12@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Wed Nov 30 21:31:34 2022 +0800

    dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata
    
    commit 8111964f1b8524c4bb56b02cd9c7a37725ea21fd upstream.
    
    Following concurrent processes:
    
              P1(drop cache)                P2(kworker)
    drop_caches_sysctl_handler
     drop_slab
      shrink_slab
       down_read(&shrinker_rwsem)  - LOCK A
       do_shrink_slab
        super_cache_scan
         prune_icache_sb
          dispose_list
           evict
            ext4_evict_inode
             ext4_clear_inode
              ext4_discard_preallocations
               ext4_mb_load_buddy_gfp
                ext4_mb_init_cache
                 ext4_read_block_bitmap_nowait
                  ext4_read_bh_nowait
                   submit_bh
                    dm_submit_bio
                                     do_worker
                                      process_deferred_bios
                                       commit
                                        metadata_operation_failed
                                         dm_pool_abort_metadata
                                          down_write(&pmd->root_lock) - LOCK B
                                          __destroy_persistent_data_objects
                                           dm_block_manager_destroy
                                            dm_bufio_client_destroy
                                             unregister_shrinker
                                              down_write(&shrinker_rwsem)
                     thin_map                            |
                      dm_thin_find_block                 ↓
                       down_read(&pmd->root_lock) --> ABBA deadlock
    
    , which triggers hung task:
    
    [   76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds.
    [   76.976019]       Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910
    [   76.978521] task:kworker/u4:3    state:D stack:0     pid:63    ppid:2
    [   76.978534] Workqueue: dm-thin do_worker
    [   76.978552] Call Trace:
    [   76.978564]  __schedule+0x6ba/0x10f0
    [   76.978582]  schedule+0x9d/0x1e0
    [   76.978588]  rwsem_down_write_slowpath+0x587/0xdf0
    [   76.978600]  down_write+0xec/0x110
    [   76.978607]  unregister_shrinker+0x2c/0xf0
    [   76.978616]  dm_bufio_client_destroy+0x116/0x3d0
    [   76.978625]  dm_block_manager_destroy+0x19/0x40
    [   76.978629]  __destroy_persistent_data_objects+0x5e/0x70
    [   76.978636]  dm_pool_abort_metadata+0x8e/0x100
    [   76.978643]  metadata_operation_failed+0x86/0x110
    [   76.978649]  commit+0x6a/0x230
    [   76.978655]  do_worker+0xc6e/0xd90
    [   76.978702]  process_one_work+0x269/0x630
    [   76.978714]  worker_thread+0x266/0x630
    [   76.978730]  kthread+0x151/0x1b0
    [   76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds.
    [   76.979756]       Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910
    [   76.982111] task:test.sh         state:D stack:0     pid:2646  ppid:2459
    [   76.982128] Call Trace:
    [   76.982139]  __schedule+0x6ba/0x10f0
    [   76.982155]  schedule+0x9d/0x1e0
    [   76.982159]  rwsem_down_read_slowpath+0x4f4/0x910
    [   76.982173]  down_read+0x84/0x170
    [   76.982177]  dm_thin_find_block+0x4c/0xd0
    [   76.982183]  thin_map+0x201/0x3d0
    [   76.982188]  __map_bio+0x5b/0x350
    [   76.982195]  dm_submit_bio+0x2b6/0x930
    [   76.982202]  __submit_bio+0x123/0x2d0
    [   76.982209]  submit_bio_noacct_nocheck+0x101/0x3e0
    [   76.982222]  submit_bio_noacct+0x389/0x770
    [   76.982227]  submit_bio+0x50/0xc0
    [   76.982232]  submit_bh_wbc+0x15e/0x230
    [   76.982238]  submit_bh+0x14/0x20
    [   76.982241]  ext4_read_bh_nowait+0xc5/0x130
    [   76.982247]  ext4_read_block_bitmap_nowait+0x340/0xc60
    [   76.982254]  ext4_mb_init_cache+0x1ce/0xdc0
    [   76.982259]  ext4_mb_load_buddy_gfp+0x987/0xfa0
    [   76.982263]  ext4_discard_preallocations+0x45d/0x830
    [   76.982274]  ext4_clear_inode+0x48/0xf0
    [   76.982280]  ext4_evict_inode+0xcf/0xc70
    [   76.982285]  evict+0x119/0x2b0
    [   76.982290]  dispose_list+0x43/0xa0
    [   76.982294]  prune_icache_sb+0x64/0x90
    [   76.982298]  super_cache_scan+0x155/0x210
    [   76.982303]  do_shrink_slab+0x19e/0x4e0
    [   76.982310]  shrink_slab+0x2bd/0x450
    [   76.982317]  drop_slab+0xcc/0x1a0
    [   76.982323]  drop_caches_sysctl_handler+0xb7/0xe0
    [   76.982327]  proc_sys_call_handler+0x1bc/0x300
    [   76.982331]  proc_sys_write+0x17/0x20
    [   76.982334]  vfs_write+0x3d3/0x570
    [   76.982342]  ksys_write+0x73/0x160
    [   76.982347]  __x64_sys_write+0x1e/0x30
    [   76.982352]  do_syscall_64+0x35/0x80
    [   76.982357]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Function metadata_operation_failed() is called when operations failed
    on dm pool metadata, dm pool will destroy and recreate metadata. So,
    shrinker will be unregistered and registered, which could down write
    shrinker_rwsem under pmd_write_lock.
    
    Fix it by allocating dm_block_manager before locking pmd->root_lock
    and destroying old dm_block_manager after unlocking pmd->root_lock,
    then old dm_block_manager is replaced with new dm_block_manager under
    pmd->root_lock. So, shrinker register/unregister could be done without
    holding pmd->root_lock.
    
    Fetch a reproducer in [Link].
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216676
    Cc: stable@vger.kernel.org #v5.2+
    Fixes: e49e582965b3 ("dm thin: add read only and fail io modes")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dm thin: Fix UAF in run_timer_softirq() [+ + +]
Author: Luo Meng <luomeng12@huawei.com>
Date:   Tue Nov 29 10:48:47 2022 +0800

    dm thin: Fix UAF in run_timer_softirq()
    
    commit 88430ebcbc0ec637b710b947738839848c20feff upstream.
    
    When dm_resume() and dm_destroy() are concurrent, it will
    lead to UAF, as follows:
    
     BUG: KASAN: use-after-free in __run_timers+0x173/0x710
     Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0
    <snip>
     Call Trace:
      <IRQ>
      dump_stack_lvl+0x73/0x9f
      print_report.cold+0x132/0xaa2
      _raw_spin_lock_irqsave+0xcd/0x160
      __run_timers+0x173/0x710
      kasan_report+0xad/0x110
      __run_timers+0x173/0x710
      __asan_store8+0x9c/0x140
      __run_timers+0x173/0x710
      call_timer_fn+0x310/0x310
      pvclock_clocksource_read+0xfa/0x250
      kvm_clock_read+0x2c/0x70
      kvm_clock_get_cycles+0xd/0x20
      ktime_get+0x5c/0x110
      lapic_next_event+0x38/0x50
      clockevents_program_event+0xf1/0x1e0
      run_timer_softirq+0x49/0x90
      __do_softirq+0x16e/0x62c
      __irq_exit_rcu+0x1fa/0x270
      irq_exit_rcu+0x12/0x20
      sysvec_apic_timer_interrupt+0x8e/0xc0
    
    One of the concurrency UAF can be shown as below:
    
            use                                  free
    do_resume                           |
      __find_device_hash_cell           |
        dm_get                          |
          atomic_inc(&md->holders)      |
                                        | dm_destroy
                                        |   __dm_destroy
                                        |     if (!dm_suspended_md(md))
                                        |     atomic_read(&md->holders)
                                        |     msleep(1)
      dm_resume                         |
        __dm_resume                     |
          dm_table_resume_targets       |
            pool_resume                 |
              do_waker  #add delay work |
      dm_put                            |
        atomic_dec(&md->holders)        |
                                        |     dm_table_destroy
                                        |       pool_dtr
                                        |         __pool_dec
                                        |           __pool_destroy
                                        |             destroy_workqueue
                                        |             kfree(pool) # free pool
            time out
    __do_softirq
      run_timer_softirq # pool has already been freed
    
    This can be easily reproduced using:
      1. create thin-pool
      2. dmsetup suspend pool
      3. dmsetup resume pool
      4. dmsetup remove_all # Concurrent with 3
    
    The root cause of this UAF bug is that dm_resume() adds timer after
    dm_destroy() skips cancelling the timer because of suspend status.
    After timeout, it will call run_timer_softirq(), however pool has
    already been freed. The concurrency UAF bug will happen.
    
    Therefore, cancelling timer again in __pool_destroy().
    
    Cc: stable@vger.kernel.org
    Fixes: 991d9fa02da0d ("dm: add thin provisioning target")
    Signed-off-by: Luo Meng <luomeng12@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dm thin: resume even if in FAIL mode [+ + +]
Author: Luo Meng <luomeng12@huawei.com>
Date:   Wed Nov 30 10:09:45 2022 +0800

    dm thin: resume even if in FAIL mode
    
    [ Upstream commit 19eb1650afeb1aa86151f61900e9e5f1de5d8d02 ]
    
    If a thinpool set fail_io while suspending, resume will fail with:
     device-mapper: resume ioctl on vg-thinpool  failed: Invalid argument
    
    The thin-pool also can't be removed if an in-flight bio is in the
    deferred list.
    
    This can be easily reproduced using:
    
      echo "offline" > /sys/block/sda/device/state
      dd if=/dev/zero of=/dev/mapper/thin bs=4K count=1
      dmsetup suspend /dev/mapper/pool
      mkfs.ext4 /dev/mapper/thin
      dmsetup resume /dev/mapper/pool
    
    The root cause is maybe_resize_data_dev() will check fail_io and return
    error before called dm_resume.
    
    Fix this by adding FAIL mode check at the end of pool_preresume().
    
    Cc: stable@vger.kernel.org
    Fixes: da105ed5fd7e ("dm thin metadata: introduce dm_pool_abort_metadata")
    Signed-off-by: Luo Meng <luomeng12@huawei.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dm thin: Use last transaction's pmd->root when commit failed [+ + +]
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Thu Dec 8 22:28:02 2022 +0800

    dm thin: Use last transaction's pmd->root when commit failed
    
    commit 7991dbff6849f67e823b7cc0c15e5a90b0549b9f upstream.
    
    Recently we found a softlock up problem in dm thin pool btree lookup
    code due to corrupted metadata:
    
     Kernel panic - not syncing: softlockup: hung tasks
     CPU: 7 PID: 2669225 Comm: kworker/u16:3
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
     Workqueue: dm-thin do_worker [dm_thin_pool]
     Call Trace:
       <IRQ>
       dump_stack+0x9c/0xd3
       panic+0x35d/0x6b9
       watchdog_timer_fn.cold+0x16/0x25
       __run_hrtimer+0xa2/0x2d0
       </IRQ>
       RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio]
       __bufio_new+0x11f/0x4f0 [dm_bufio]
       new_read+0xa3/0x1e0 [dm_bufio]
       dm_bm_read_lock+0x33/0xd0 [dm_persistent_data]
       ro_step+0x63/0x100 [dm_persistent_data]
       btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data]
       dm_btree_lookup+0x16f/0x210 [dm_persistent_data]
       dm_thin_find_block+0x12c/0x210 [dm_thin_pool]
       __process_bio_read_only+0xc5/0x400 [dm_thin_pool]
       process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool]
       process_one_work+0x3c5/0x730
    
    Following process may generate a broken btree mixed with fresh and
    stale btree nodes, which could get dm thin trapped in an infinite loop
    while looking up data block:
     Transaction 1: pmd->root = A, A->B->C   // One path in btree
                    pmd->root = X, X->Y->Z   // Copy-up
     Transaction 2: X,Z is updated on disk, Y write failed.
                    // Commit failed, dm thin becomes read-only.
                    process_bio_read_only
                     dm_thin_find_block
                      __find_block
                       dm_btree_lookup(pmd->root)
    The pmd->root points to a broken btree, Y may contain stale node
    pointing to any block, for example X, which gets dm thin trapped into
    a dead loop while looking up Z.
    
    Fix this by setting pmd->root in __open_metadata(), so that dm thin
    will use the last transaction's pmd->root if commit failed.
    
    Fetch a reproducer in [Link].
    
    Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790
    Cc: stable@vger.kernel.org
    Fixes: 991d9fa02da0 ("dm: add thin provisioning target")
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Acked-by: Joe Thornber <ejt@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
docs: fault-injection: fix non-working usage of negative values [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Thu Jun 3 14:58:41 2021 +0200

    docs: fault-injection: fix non-working usage of negative values
    
    [ Upstream commit 005747526d4f3c2ec995891e95cb7625161022f9 ]
    
    Fault injection uses debugfs in a way that the provided values via sysfs
    are interpreted as u64. Providing negative numbers results in an error:
    
    /sys/kernel/debug/fail_function# echo -1 > times
    sh: write error: Invalid argument
    
    Update the docs and examples to use "printf %#x <val>" in these cases.
    For "retval", reword the paragraph a little and fix a typo.
    
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Link: https://lore.kernel.org/r/20210603125841.27436-1-wsa+renesas@sang-engineering.com
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Stable-dep-of: d472cf797c4e ("debugfs: fix error when writing negative value to atomic_t debugfs file")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

docs: Fix the docs build with Sphinx 6.0 [+ + +]
Author: Jonathan Corbet <corbet@lwn.net>
Date:   Wed Jan 4 10:47:39 2023 -0700

    docs: Fix the docs build with Sphinx 6.0
    
    commit 0283189e8f3d0917e2ac399688df85211f48447b upstream.
    
    Sphinx 6.0 removed the execfile_() function, which we use as part of the
    configuration process.  They *did* warn us...  Just open-code the
    functionality as is done in Sphinx itself.
    
    Tested (using SPHINX_CONF, since this code is only executed with an
    alternative config file) on various Sphinx versions from 2.5 through 6.0.
    
    Reported-by: Martin Liška <mliska@suse.cz>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
driver core: Fix bus_type.match() error handling in __driver_attach() [+ + +]
Author: Isaac J. Manjarres <isaacmanjarres@google.com>
Date:   Tue Sep 20 17:14:13 2022 -0700

    driver core: Fix bus_type.match() error handling in __driver_attach()
    
    commit 27c0d217340e47ec995557f61423ef415afba987 upstream.
    
    When a driver registers with a bus, it will attempt to match with every
    device on the bus through the __driver_attach() function. Currently, if
    the bus_type.match() function encounters an error that is not
    -EPROBE_DEFER, __driver_attach() will return a negative error code, which
    causes the driver registration logic to stop trying to match with the
    remaining devices on the bus.
    
    This behavior is not correct; a failure while matching a driver to a
    device does not mean that the driver won't be able to match and bind
    with other devices on the bus. Update the logic in __driver_attach()
    to reflect this.
    
    Fixes: 656b8035b0ee ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()")
    Cc: stable@vger.kernel.org
    Cc: Saravana Kannan <saravanak@google.com>
    Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
    Link: https://lore.kernel.org/r/20220921001414.4046492-1-isaacmanjarres@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drivers/md/md-bitmap: check the return value of md_bitmap_get_counter() [+ + +]
Author: Li Zhong <floridsleeves@gmail.com>
Date:   Fri Sep 16 16:33:05 2022 -0700

    drivers/md/md-bitmap: check the return value of md_bitmap_get_counter()
    
    [ Upstream commit 3bd548e5b819b8c0f2c9085de775c5c7bff9052f ]
    
    Check the return value of md_bitmap_get_counter() in case it returns
    NULL pointer, which will result in a null pointer dereference.
    
    v2: update the check to include other dereference
    
    Signed-off-by: Li Zhong <floridsleeves@gmail.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers/net/bonding/bond_3ad: return when there's no aggregator [+ + +]
Author: Daniil Tatianin <d-tatianin@yandex-team.ru>
Date:   Mon Jan 2 12:53:35 2023 +0300

    drivers/net/bonding/bond_3ad: return when there's no aggregator
    
    [ Upstream commit 9c807965483f42df1d053b7436eedd6cf28ece6f ]
    
    Otherwise we would dereference a NULL aggregator pointer when calling
    __set_agg_ports_ready on the line below.
    
    Found by Linux Verification Center (linuxtesting.org) with the SVACE
    static analysis tool.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drivers: dio: fix possible memory leak in dio_init() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Nov 9 14:40:36 2022 +0800

    drivers: dio: fix possible memory leak in dio_init()
    
    [ Upstream commit e63e99397b2613d50a5f4f02ed07307e67a190f1 ]
    
    If device_register() returns error, the 'dev' and name needs be
    freed. Add a release function, and then call put_device() in the
    error path, so the name is freed in kobject_cleanup() and to the
    'dev' is freed in release function.
    
    Fixes: 2e4c77bea3d8 ("m68k: dio - Kill warn_unused_result warnings")
    Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221109064036.1835346-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drivers: mcb: fix resource leak in mcb_probe() [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Fri Dec 2 01:38:49 2022 -0800

    drivers: mcb: fix resource leak in mcb_probe()
    
    [ Upstream commit d7237462561fcd224fa687c56ccb68629f50fc0d ]
    
    When probe hook function failed in mcb_probe(), it doesn't put the device.
    Compiled test only.
    
    Fixes: 7bc364097a89 ("mcb: Acquire reference to device in probe")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Signed-off-by: Johannes Thumshirn <jth@kernel.org>
    Link: https://lore.kernel.org/r/9f87de36bfb85158b506cb78c6fc9db3f6a3bad1.1669624063.git.johannes.thumshirn@wdc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init() [+ + +]
Author: Yuan Can <yuancan@huawei.com>
Date:   Wed Dec 7 08:54:10 2022 +0000

    drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init()
    
    [ Upstream commit 01de1123322e4fe1bbd0fcdf0982511b55519c03 ]
    
    If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp
    needs to be freed.
    
    Fixes: f197a7aa6288 ("qlcnic: VF-PF communication channel implementation")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drivers: soc: ti: knav_qmss_queue: Mark knav_acc_firmwares as static [+ + +]
Author: Chen Jiahao <chenjiahao16@huawei.com>
Date:   Wed Oct 19 23:32:12 2022 +0800

    drivers: soc: ti: knav_qmss_queue: Mark knav_acc_firmwares as static
    
    [ Upstream commit adf85adc2a7199b41e7a4da083bd17274a3d6969 ]
    
    There is a sparse warning shown below:
    
    drivers/soc/ti/knav_qmss_queue.c:70:12: warning: symbol
    'knav_acc_firmwares' was not declared. Should it be static?
    
    Since 'knav_acc_firmwares' is only called within knav_qmss_queue.c,
    mark it as static to fix the warning.
    
    Fixes: 96ee19becc3b ("soc: ti: add firmware file name as part of the driver")
    Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Link: https://lore.kernel.org/r/20221019153212.72350-1-chenjiahao16@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios() [+ + +]
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Tue Nov 22 19:30:43 2022 +0800

    drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios()
    
    [ Upstream commit ca54639c7752edf1304d92ff4d0c049d4efc9ba0 ]
    
    As comment of pci_get_class() says, it returns a pci_device with its
    refcount increased and decreased the refcount for the input parameter
    @from if it is not NULL.
    
    If we break the loop in amdgpu_atrm_get_bios() with 'pdev' not NULL, we
    need to call pci_dev_put() to decrease the refcount. Add the missing
    pci_dev_put() to avoid refcount leak.
    
    Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/connector: send hotplug uevent on connector cleanup [+ + +]
Author: Simon Ser <contact@emersion.fr>
Date:   Mon Oct 17 15:32:01 2022 +0000

    drm/connector: send hotplug uevent on connector cleanup
    
    commit 6fdc2d490ea1369d17afd7e6eb66fecc5b7209bc upstream.
    
    A typical DP-MST unplug removes a KMS connector. However care must
    be taken to properly synchronize with user-space. The expected
    sequence of events is the following:
    
    1. The kernel notices that the DP-MST port is gone.
    2. The kernel marks the connector as disconnected, then sends a
       uevent to make user-space re-scan the connector list.
    3. User-space notices the connector goes from connected to disconnected,
       disables it.
    4. Kernel handles the IOCTL disabling the connector. On success,
       the very last reference to the struct drm_connector is dropped and
       drm_connector_cleanup() is called.
    5. The connector is removed from the list, and a uevent is sent to tell
       user-space that the connector disappeared.
    
    The very last step was missing. As a result, user-space thought the
    connector still existed and could try to disable it again. Since the
    kernel no longer knows about the connector, that would end up with
    EINVAL and confused user-space.
    
    Fix this by sending a hotplug uevent from drm_connector_cleanup().
    
    Signed-off-by: Simon Ser <contact@emersion.fr>
    Cc: stable@vger.kernel.org
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Lyude Paul <lyude@redhat.com>
    Cc: Jonas Ådahl <jadahl@redhat.com>
    Tested-by: Jonas Ådahl <jadahl@redhat.com>
    Reviewed-by: Lyude Paul <lyude@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221017153150.60675-2-contact@emersion.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/etnaviv: add missing quirks for GC300 [+ + +]
Author: Doug Brown <doug@schmorgal.com>
Date:   Sat Sep 10 13:29:38 2022 -0700

    drm/etnaviv: add missing quirks for GC300
    
    [ Upstream commit cc7d3fb446a91f24978a6aa59cbb578f92e22242 ]
    
    The GC300's features register doesn't specify that a 2D pipe is
    available, and like the GC600, its idle register reports zero bits where
    modules aren't present.
    
    Signed-off-by: Doug Brown <doug@schmorgal.com>
    Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Nov 2 08:42:15 2022 -0700

    drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid()
    
    [ Upstream commit 96d845a67b7e406cfed7880a724c8ca6121e022e ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed. A
    proposed warning in clang aims to catch these at compile time, which
    reveals:
    
      drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:74:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .mode_valid = fsl_dcu_drm_connector_mode_valid,
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      1 error generated.
    
    ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
    type of 'enum drm_mode_status', not 'int'. Adjust the return type of
    fsl_dcu_drm_connector_mode_valid() to match the prototype's to resolve
    the warning and CFI failure.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1750
    Reported-by: Sami Tolvanen <samitolvanen@google.com>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221102154215.78059-1-nathan@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915: unpin on error in intel_vgpu_shadow_mm_pin() [+ + +]
Author: Dan Carpenter <error27@gmail.com>
Date:   Tue Nov 15 16:15:18 2022 +0300

    drm/i915: unpin on error in intel_vgpu_shadow_mm_pin()
    
    [ Upstream commit 3792fc508c095abd84b10ceae12bd773e61fdc36 ]
    
    Call intel_vgpu_unpin_mm() on this error path.
    
    Fixes: 418741480809 ("drm/i915/gvt: Adding ppgtt to GVT GEM context after shadow pdps settled.")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/Y3OQ5tgZIVxyQ/WV@kili
    Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/mediatek: Modify dpi power on/off sequence. [+ + +]
Author: Xinlei Lee <xinlei.lee@mediatek.com>
Date:   Wed Nov 9 18:00:59 2022 +0800

    drm/mediatek: Modify dpi power on/off sequence.
    
    [ Upstream commit ff446c0f6290185cefafe3b376bb86063a3a9f6a ]
    
    Modify dpi power on/off sequence so that the first gpio operation will
    take effect.
    
    Fixes: 6bd4763fd532 ("drm/mediatek: set dpi pin mode to gpio low to avoid leakage current")
    Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com>
    Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/msm/adreno: Make adreno quirks not overwrite each other [+ + +]
Author: Konrad Dybcio <konrad.dybcio@linaro.org>
Date:   Mon Jan 2 11:02:00 2023 +0100

    drm/msm/adreno: Make adreno quirks not overwrite each other
    
    commit 13ef096e342b00e30b95a90c6c13eee1f0bec4c5 upstream.
    
    So far the adreno quirks have all been assigned with an OR operator,
    which is problematic, because they were assigned consecutive integer
    values, which makes checking them with an AND operator kind of no bueno..
    
    Switch to using BIT(n) so that only the quirks that the programmer chose
    are taken into account when evaluating info->quirks & ADRENO_QUIRK_...
    
    Fixes: 370063ee427a ("drm/msm/adreno: Add A540 support")
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Reviewed-by: Rob Clark <robdclark@gmail.com>
    Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
    Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
    Patchwork: https://patchwork.freedesktop.org/patch/516456/
    Link: https://lore.kernel.org/r/20230102100201.77286-1-konrad.dybcio@linaro.org
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/panel/panel-sitronix-st7701: Remove panel on DSI attach failure [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Sat Oct 15 01:11:06 2022 +0200

    drm/panel/panel-sitronix-st7701: Remove panel on DSI attach failure
    
    [ Upstream commit c62102165dd79284d42383d2f7ed17301bd8e629 ]
    
    In case mipi_dsi_attach() fails, call drm_panel_remove() to
    avoid memory leak.
    
    Fixes: 849b2e3ff969 ("drm/panel: Add Sitronix ST7701 panel driver")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221014231106.468063-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon: Add the missed acpi_put_table() to fix memory leak [+ + +]
Author: Hanjun Guo <guohanjun@huawei.com>
Date:   Fri Nov 4 17:50:02 2022 +0800

    drm/radeon: Add the missed acpi_put_table() to fix memory leak
    
    [ Upstream commit 10276a20be1115e1f76c189330da2992df980eee ]
    
    When the radeon driver reads the bios information from ACPI
    table in radeon_acpi_vfct_bios(), it misses to call acpi_put_table()
    to release the ACPI memory after the init, so add acpi_put_table()
    properly to fix the memory leak.
    
    v2: fix text formatting (Alex)
    
    Fixes: 268ba0a99f89 ("drm/radeon: implement ACPI VFCT vbios fetch (v3)")
    Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios() [+ + +]
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Tue Nov 22 19:30:42 2022 +0800

    drm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios()
    
    [ Upstream commit 725a521a18734f65de05b8d353b5bd0d3ca4c37a ]
    
    As comment of pci_get_class() says, it returns a pci_device with its
    refcount increased and decreased the refcount for the input parameter
    @from if it is not NULL.
    
    If we break the loop in radeon_atrm_get_bios() with 'pdev' not NULL, we
    need to call pci_dev_put() to decrease the refcount. Add the missing
    pci_dev_put() to avoid refcount leak.
    
    Fixes: d8ade3526b2a ("drm/radeon: handle non-VGA class pci devices with ATRM")
    Fixes: c61e2775873f ("drm/radeon: split ATRM support out from the ATPX handler (v3)")
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/rockchip: Use drm_mode_copy() [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Nov 7 21:25:44 2022 +0200

    drm/rockchip: Use drm_mode_copy()
    
    [ Upstream commit 2bfaa28000d2830d3209161a4541cce0660e1b84 ]
    
    struct drm_display_mode embeds a list head, so overwriting
    the full struct with another one will corrupt the list
    (if the destination mode is on a list). Use drm_mode_copy()
    instead which explicitly preserves the list head of
    the destination mode.
    
    Even if we know the destination mode is not on any list
    using drm_mode_copy() seems decent as it sets a good
    example. Bad examples of not using it might eventually
    get copied into code where preserving the list head
    actually matters.
    
    Obviously one case not covered here is when the mode
    itself is embedded in a larger structure and the whole
    structure is copied. But if we are careful when copying
    into modes embedded in structures I think we can be a
    little more reassured that bogus list heads haven't been
    propagated in.
    
    @is_mode_copy@
    @@
    drm_mode_copy(...)
    {
    ...
    }
    
    @depends on !is_mode_copy@
    struct drm_display_mode *mode;
    expression E, S;
    @@
    (
    - *mode = E
    + drm_mode_copy(mode, &E)
    |
    - memcpy(mode, E, S)
    + drm_mode_copy(mode, E)
    )
    
    @depends on !is_mode_copy@
    struct drm_display_mode mode;
    expression E;
    @@
    (
    - mode = E
    + drm_mode_copy(&mode, &E)
    |
    - memcpy(&mode, E, S)
    + drm_mode_copy(&mode, E)
    )
    
    @@
    struct drm_display_mode *mode;
    @@
    - &*mode
    + mode
    
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Sandy Huang <hjc@rock-chips.com>
    Cc: "Heiko Stübner" <heiko@sntech.de>
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-rockchip@lists.infradead.org
    Link: https://patchwork.freedesktop.org/patch/msgid/20221107192545.9896-7-ville.syrjala@linux.intel.com
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Nov 2 08:56:23 2022 -0700

    drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid()
    
    [ Upstream commit 0ad811cc08a937d875cbad0149c1bab17f84ba05 ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed. A
    proposed warning in clang aims to catch these at compile time, which
    reveals:
    
      drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .mode_valid = sti_hda_connector_mode_valid,
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .mode_valid = sti_dvo_connector_mode_valid,
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)' with an expression of type 'int (struct drm_connector *, struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .mode_valid = sti_hdmi_connector_mode_valid,
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    ->mode_valid() in 'struct drm_connector_helper_funcs' expects a return
    type of 'enum drm_mode_status', not 'int'. Adjust the return type of
    sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype's to
    resolve the warning and CFI failure.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1750
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221102155623.3042869-1-nathan@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/sti: Use drm_mode_copy() [+ + +]
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Nov 7 21:25:45 2022 +0200

    drm/sti: Use drm_mode_copy()
    
    [ Upstream commit 442cf8e22ba25a77cb9092d78733fdbac9844e50 ]
    
    struct drm_display_mode embeds a list head, so overwriting
    the full struct with another one will corrupt the list
    (if the destination mode is on a list). Use drm_mode_copy()
    instead which explicitly preserves the list head of
    the destination mode.
    
    Even if we know the destination mode is not on any list
    using drm_mode_copy() seems decent as it sets a good
    example. Bad examples of not using it might eventually
    get copied into code where preserving the list head
    actually matters.
    
    Obviously one case not covered here is when the mode
    itself is embedded in a larger structure and the whole
    structure is copied. But if we are careful when copying
    into modes embedded in structures I think we can be a
    little more reassured that bogus list heads haven't been
    propagated in.
    
    @is_mode_copy@
    @@
    drm_mode_copy(...)
    {
    ...
    }
    
    @depends on !is_mode_copy@
    struct drm_display_mode *mode;
    expression E, S;
    @@
    (
    - *mode = E
    + drm_mode_copy(mode, &E)
    |
    - memcpy(mode, E, S)
    + drm_mode_copy(mode, E)
    )
    
    @depends on !is_mode_copy@
    struct drm_display_mode mode;
    expression E;
    @@
    (
    - mode = E
    + drm_mode_copy(&mode, &E)
    |
    - memcpy(&mode, E, S)
    + drm_mode_copy(&mode, E)
    )
    
    @@
    struct drm_display_mode *mode;
    @@
    - &*mode
    + mode
    
    Cc: Alain Volmat <alain.volmat@foss.st.com>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221107192545.9896-8-ville.syrjala@linux.intel.com
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/tegra: Add missing clk_disable_unprepare() in tegra_dc_probe() [+ + +]
Author: Zhang Zekun <zhangzekun11@huawei.com>
Date:   Tue Aug 2 08:50:50 2022 +0000

    drm/tegra: Add missing clk_disable_unprepare() in tegra_dc_probe()
    
    [ Upstream commit 7ad4384d53c67672a8720cdc2ef638d7d1710ab8 ]
    
    Add the missing clk_disable_unprepare() before return from
    tegra_dc_probe() in the error handling path.
    
    Fixes: f68ba6912bd2 ("drm/tegra: dc: Link DC1 to DC0 on Tegra20")
    Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/virtio: Fix GEM handle creation UAF [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Fri Dec 16 15:33:55 2022 -0800

    drm/virtio: Fix GEM handle creation UAF
    
    [ Upstream commit 52531258318ed59a2dc5a43df2eaf0eb1d65438e ]
    
    Userspace can guess the handle value and try to race GEM object creation
    with handle close, resulting in a use-after-free if we dereference the
    object after dropping the handle's reference.  For that reason, dropping
    the handle's reference must be done *after* we are done dereferencing
    the object.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
    Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221216233355.542197-2-robdclark@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/vmwgfx: Validate the box size for the snooped cursor [+ + +]
Author: Zack Rusin <zackr@vmware.com>
Date:   Tue Oct 25 23:19:35 2022 -0400

    drm/vmwgfx: Validate the box size for the snooped cursor
    
    commit 4cf949c7fafe21e085a4ee386bb2dade9067316e upstream.
    
    Invalid userspace dma surface copies could potentially overflow
    the memcpy from the surface to the snooped image leading to crashes.
    To fix it the dimensions of the copybox have to be validated
    against the expected size of the snooped cursor.
    
    Signed-off-by: Zack Rusin <zackr@vmware.com>
    Fixes: 2ac863719e51 ("vmwgfx: Snoop DMA transfers with non-covering sizes")
    Cc: <stable@vger.kernel.org> # v3.2+
    Reviewed-by: Michael Banack <banackm@vmware.com>
    Reviewed-by: Martin Krastev <krastevm@vmware.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20221026031936.1004280-1-zack@kde.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
EDAC/device: Fix period calculation in edac_device_reset_delay_period() [+ + +]
Author: Eliav Farber <farbere@amazon.com>
Date:   Thu Oct 20 12:44:58 2022 +0000

    EDAC/device: Fix period calculation in edac_device_reset_delay_period()
    
    commit e84077437902ec99eba0a6b516df772653f142c7 upstream.
    
    Fix period calculation in case user sets a value of 1000.  The input of
    round_jiffies_relative() should be in jiffies and not in milli-seconds.
    
      [ bp: Use the same code pattern as in edac_device_workq_setup() for
        clarity. ]
    
    Fixes: c4cf3b454eca ("EDAC: Rework workqueue handling")
    Signed-off-by: Eliav Farber <farbere@amazon.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/20221020124458.22153-1-farbere@amazon.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Nov 28 14:55:12 2022 +0800

    EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper()
    
    [ Upstream commit 9c8921555907f4d723f01ed2d859b66f2d14f08e ]
    
    As the comment of pci_get_domain_bus_and_slot() says, it returns
    a PCI device with refcount incremented, so it doesn't need to
    call an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCI
    device needs to be put in the error path.
    
    Fixes: d4dc89d069aa ("EDAC, i10nm: Add a driver for Intel 10nm server processors")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Link: https://lore.kernel.org/r/20221128065512.3572550-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
efi: Add iMac Pro 2017 to uefi skip cert quirk [+ + +]
Author: Aditya Garg <gargaditya08@live.com>
Date:   Thu Oct 27 10:01:43 2022 +0000

    efi: Add iMac Pro 2017 to uefi skip cert quirk
    
    commit 0be56a116220f9e5731a6609e66a11accfe8d8e2 upstream.
    
    The iMac Pro 2017 is also a T2 Mac. Thus add it to the list of uefi skip
    cert.
    
    Cc: stable@vger.kernel.org
    Fixes: 155ca952c7ca ("efi: Do not import certificates from UEFI Secure Boot for T2 Macs")
    Link: https://lore.kernel.org/linux-integrity/9D46D92F-1381-4F10-989C-1A12CD2FFDD8@live.com/
    Signed-off-by: Aditya Garg <gargaditya08@live.com>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

efi: fix NULL-deref in init error path [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Mon Dec 19 10:10:04 2022 +0100

    efi: fix NULL-deref in init error path
    
    [ Upstream commit 703c13fe3c9af557d312f5895ed6a5fda2711104 ]
    
    In cases where runtime services are not supported or have been disabled,
    the runtime services workqueue will never have been allocated.
    
    Do not try to destroy the workqueue unconditionally in the unlikely
    event that EFI initialisation fails to avoid dereferencing a NULL
    pointer.
    
    Fixes: 98086df8b70c ("efi: add missed destroy_workqueue when efisubsys_init fails")
    Cc: stable@vger.kernel.org
    Cc: Li Heng <liheng40@huawei.com>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

efi: tpm: Avoid READ_ONCE() for accessing the event log [+ + +]
Author: Ard Biesheuvel <ardb@kernel.org>
Date:   Mon Jan 9 10:44:31 2023 +0100

    efi: tpm: Avoid READ_ONCE() for accessing the event log
    
    commit d3f450533bbcb6dd4d7d59cadc9b61b7321e4ac1 upstream.
    
    Nathan reports that recent kernels built with LTO will crash when doing
    EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a
    misaligned load from the TPM event log, which is annotated with
    READ_ONCE(), and under LTO, this gets translated into a LDAR instruction
    which does not tolerate misaligned accesses.
    
    Interestingly, this does not happen when booting the same kernel
    straight from the UEFI shell, and so the fact that the event log may
    appear misaligned in memory may be caused by a bug in GRUB or SHIM.
    
    However, using READ_ONCE() to access firmware tables is slightly unusual
    in any case, and here, we only need to ensure that 'event' is not
    dereferenced again after it gets unmapped, but this is already taken
    care of by the implicit barrier() semantics of the early_memunmap()
    call.
    
    Cc: <stable@vger.kernel.org>
    Cc: Peter Jones <pjones@redhat.com>
    Cc: Jarkko Sakkinen <jarkko@kernel.org>
    Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    Reported-by: Nathan Chancellor <nathan@kernel.org>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Link: https://github.com/ClangBuiltLinux/linux/issues/1782
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ethernet: s2io: don't call dev_kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Dec 8 20:01:21 2022 +0800

    ethernet: s2io: don't call dev_kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 6cee96e09df54ae17784c0f38a49e0ed8229b825 ]
    
    It is not allowed to call kfree_skb() or consume_skb() from hardware
    interrupt context or with hardware interrupts being disabled.
    
    It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
    The difference between them is free reason, dev_kfree_skb_irq() means
    the SKB is dropped in error and dev_consume_skb_irq() means the SKB
    is consumed in normal.
    
    In this case, dev_kfree_skb() is called in free_tx_buffers() to drop
    the SKBs in tx buffers, when the card is down, so replace it with
    dev_kfree_skb_irq() here.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
eventfd: change int to __u64 in eventfd_signal() ifndef CONFIG_EVENTFD [+ + +]
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Thu Nov 24 22:01:54 2022 +0800

    eventfd: change int to __u64 in eventfd_signal() ifndef CONFIG_EVENTFD
    
    [ Upstream commit fd4e60bf0ef8eb9edcfa12dda39e8b6ee9060492 ]
    
    Commit ee62c6b2dc93 ("eventfd: change int to __u64 in eventfd_signal()")
    forgot to change int to __u64 in the CONFIG_EVENTFD=n stub function.
    
    Link: https://lkml.kernel.org/r/20221124140154.104680-1-zhangqilong3@huawei.com
    Fixes: ee62c6b2dc93 ("eventfd: change int to __u64 in eventfd_signal()")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Cc: Dylan Yudaken <dylany@fb.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Sha Zhengju <handai.szj@taobao.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Wed Oct 26 12:23:09 2022 +0800

    ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode
    
    commit 63b1e9bccb71fe7d7e3ddc9877dbdc85e5d2d023 upstream.
    
    There are many places that will get unhappy (and crash) when ext4_iget()
    returns a bad inode. However, if iget the boot loader inode, allows a bad
    inode to be returned, because the inode may not be initialized. This
    mechanism can be used to bypass some checks and cause panic. To solve this
    problem, we add a special iget flag EXT4_IGET_BAD. Only with this flag
    we'd be returning bad inode from ext4_iget(), otherwise we always return
    the error code if the inode is bad inode.(suggested by Jan Kara)
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jason Yan <yanaijie@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221026042310.3839669-4-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: add helper to check quota inums [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Wed Oct 26 12:23:08 2022 +0800

    ext4: add helper to check quota inums
    
    commit 07342ec259df2a35d6a34aebce010567a80a0e15 upstream.
    
    Before quota is enabled, a check on the preset quota inums in
    ext4_super_block is added to prevent wrong quota inodes from being loaded.
    In addition, when the quota fails to be enabled, the quota type and quota
    inum are printed to facilitate fault locating.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jason Yan <yanaijie@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221026042310.3839669-3-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: add inode table check in __ext4_get_inode_loc to aovid possible infinite loop [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Wed Aug 17 21:27:01 2022 +0800

    ext4: add inode table check in __ext4_get_inode_loc to aovid possible infinite loop
    
    commit eee22187b53611e173161e38f61de1c7ecbeb876 upstream.
    
    In do_writepages, if the value returned by ext4_writepages is "-ENOMEM"
    and "wbc->sync_mode == WB_SYNC_ALL", retry until the condition is not met.
    
    In __ext4_get_inode_loc, if the bh returned by sb_getblk is NULL,
    the function returns -ENOMEM.
    
    In __getblk_slow, if the return value of grow_buffers is less than 0,
    the function returns NULL.
    
    When the three processes are connected in series like the following stack,
    an infinite loop may occur:
    
    do_writepages                                   <--- keep retrying
     ext4_writepages
      mpage_map_and_submit_extent
       mpage_map_one_extent
        ext4_map_blocks
         ext4_ext_map_blocks
          ext4_ext_handle_unwritten_extents
           ext4_ext_convert_to_initialized
            ext4_split_extent
             ext4_split_extent_at
              __ext4_ext_dirty
               __ext4_mark_inode_dirty
                ext4_reserve_inode_write
                 ext4_get_inode_loc
                  __ext4_get_inode_loc              <--- return -ENOMEM
                   sb_getblk
                    __getblk_gfp
                     __getblk_slow                  <--- return NULL
                      grow_buffers
                       grow_dev_page                <--- return -ENXIO
                        ret = (block < end_block) ? 1 : -ENXIO;
    
    In this issue, bg_inode_table_hi is overwritten as an incorrect value.
    As a result, `block < end_block` cannot be met in grow_dev_page.
    Therefore, __ext4_get_inode_loc always returns '-ENOMEM' and do_writepages
    keeps retrying. As a result, the writeback process is in the D state due
    to an infinite loop.
    
    Add a check on inode table block in the __ext4_get_inode_loc function by
    referring to ext4_read_inode_bitmap to avoid this infinite loop.
    
    Cc: stable@kernel.org
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Link: https://lore.kernel.org/r/20220817132701.3015912-3-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: allocate extended attribute value in vmalloc area [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu Dec 8 10:32:31 2022 +0800

    ext4: allocate extended attribute value in vmalloc area
    
    commit cc12a6f25e07ed05d5825a1664b67a970842b2ca upstream.
    
    Now, extended attribute value maximum length is 64K. The memory
    requested here does not need continuous physical addresses, so it is
    appropriate to use kvmalloc to request memory. At the same time, it
    can also cope with the situation that the extended attribute will
    become longer in the future.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221208023233.1231330-3-yebin@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: avoid BUG_ON when creating xattrs [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Mon Nov 21 14:09:29 2022 +0100

    ext4: avoid BUG_ON when creating xattrs
    
    commit b40ebaf63851b3a401b0dc9263843538f64f5ce6 upstream.
    
    Commit fb0a387dcdcd ("ext4: limit block allocations for indirect-block
    files to < 2^32") added code to try to allocate xattr block with 32-bit
    block number for indirect block based files on the grounds that these
    files cannot use larger block numbers. It also added BUG_ON when
    allocated block could not fit into 32 bits. This is however bogus
    reasoning because xattr block is stored in inode->i_file_acl and
    inode->i_file_acl_hi and as such even indirect block based files can
    happily use full 48 bits for xattr block number. The proper handling
    seems to be there basically since 64-bit block number support was added.
    So remove the bogus limitation and BUG_ON.
    
    Cc: Eric Sandeen <sandeen@redhat.com>
    Fixes: fb0a387dcdcd ("ext4: limit block allocations for indirect-block files to < 2^32")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221121130929.32031-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: avoid unaccounted block allocation when expanding inode [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Dec 7 12:59:28 2022 +0100

    ext4: avoid unaccounted block allocation when expanding inode
    
    commit 8994d11395f8165b3deca1971946f549f0822630 upstream.
    
    When expanding inode space in ext4_expand_extra_isize_ea() we may need
    to allocate external xattr block. If quota is not initialized for the
    inode, the block allocation will not be accounted into quota usage. Make
    sure the quota is initialized before we try to expand inode space.
    
    Reported-by: Pengfei Xu <pengfei.xu@intel.com>
    Link: https://lore.kernel.org/all/Y5BT+k6xWqthZc1P@xpf.sh.intel.com
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20221207115937.26601-2-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: correct inconsistent error msg in nojournal mode [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Wed Nov 9 15:43:43 2022 +0800

    ext4: correct inconsistent error msg in nojournal mode
    
    [ Upstream commit 89481b5fa8c0640e62ba84c6020cee895f7ac643 ]
    
    When we used the journal_async_commit mounting option in nojournal mode,
    the kernel told me that "can't mount with journal_checksum", was very
    confusing. I find that when we mount with journal_async_commit, both the
    JOURNAL_ASYNC_COMMIT and EXPLICIT_JOURNAL_CHECKSUM flags are set. However,
    in the error branch, CHECKSUM is checked before ASYNC_COMMIT. As a result,
    the above inconsistency occurs, and the ASYNC_COMMIT branch becomes dead
    code that cannot be executed. Therefore, we exchange the positions of the
    two judgments to make the error msg more accurate.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221109074343.4184862-1-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: don't allow journal inode to have encrypt flag [+ + +]
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Nov 1 22:33:12 2022 -0700

    ext4: don't allow journal inode to have encrypt flag
    
    commit 105c78e12468413e426625831faa7db4284e1fec upstream.
    
    Mounting a filesystem whose journal inode has the encrypt flag causes a
    NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt'
    mount option is used.
    
    The problem is that when jbd2_journal_init_inode() calls bmap(), it
    eventually finds its way into ext4_iomap_begin(), which calls
    fscrypt_limit_io_blocks().  fscrypt_limit_io_blocks() requires that if
    the inode is encrypted, then its encryption key must already be set up.
    That's not the case here, since the journal inode is never "opened" like
    a normal file would be.  Hence the crash.
    
    A reproducer is:
    
        mkfs.ext4 -F /dev/vdb
        debugfs -w /dev/vdb -R "set_inode_field <8> flags 0x80808"
        mount /dev/vdb /mnt -o inlinecrypt
    
    To fix this, make ext4 consider journal inodes with the encrypt flag to
    be invalid.  (Note, maybe other flags should be rejected on the journal
    inode too.  For now, this is just the minimal fix for the above issue.)
    
    I've marked this as fixing the commit that introduced the call to
    fscrypt_limit_io_blocks(), since that's what made an actual crash start
    being possible.  But this fix could be applied to any version of ext4
    that supports the encrypt feature.
    
    Reported-by: syzbot+ba9dac45bc76c490b7c3@syzkaller.appspotmail.com
    Fixes: 38ea50daa7a4 ("ext4: support direct I/O with fscrypt using blk-crypto")
    Cc: stable@vger.kernel.org
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20221102053312.189962-1-ebiggers@kernel.org
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix bug_on in __es_tree_search caused by bad boot loader inode [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Wed Oct 26 12:23:10 2022 +0800

    ext4: fix bug_on in __es_tree_search caused by bad boot loader inode
    
    commit 991ed014de0840c5dc405b679168924afb2952ac upstream.
    
    We got a issue as fllows:
    ==================================================================
     kernel BUG at fs/ext4/extents_status.c:203!
     invalid opcode: 0000 [#1] PREEMPT SMP
     CPU: 1 PID: 945 Comm: cat Not tainted 6.0.0-next-20221007-dirty #349
     RIP: 0010:ext4_es_end.isra.0+0x34/0x42
     RSP: 0018:ffffc9000143b768 EFLAGS: 00010203
     RAX: 0000000000000000 RBX: ffff8881769cd0b8 RCX: 0000000000000000
     RDX: 0000000000000000 RSI: ffffffff8fc27cf7 RDI: 00000000ffffffff
     RBP: ffff8881769cd0bc R08: 0000000000000000 R09: ffffc9000143b5f8
     R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881769cd0a0
     R13: ffff8881768e5668 R14: 00000000768e52f0 R15: 0000000000000000
     FS: 00007f359f7f05c0(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00007f359f5a2000 CR3: 000000017130c000 CR4: 00000000000006e0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
     Call Trace:
      <TASK>
      __es_tree_search.isra.0+0x6d/0xf5
      ext4_es_cache_extent+0xfa/0x230
      ext4_cache_extents+0xd2/0x110
      ext4_find_extent+0x5d5/0x8c0
      ext4_ext_map_blocks+0x9c/0x1d30
      ext4_map_blocks+0x431/0xa50
      ext4_mpage_readpages+0x48e/0xe40
      ext4_readahead+0x47/0x50
      read_pages+0x82/0x530
      page_cache_ra_unbounded+0x199/0x2a0
      do_page_cache_ra+0x47/0x70
      page_cache_ra_order+0x242/0x400
      ondemand_readahead+0x1e8/0x4b0
      page_cache_sync_ra+0xf4/0x110
      filemap_get_pages+0x131/0xb20
      filemap_read+0xda/0x4b0
      generic_file_read_iter+0x13a/0x250
      ext4_file_read_iter+0x59/0x1d0
      vfs_read+0x28f/0x460
      ksys_read+0x73/0x160
      __x64_sys_read+0x1e/0x30
      do_syscall_64+0x35/0x80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      </TASK>
    ==================================================================
    
    In the above issue, ioctl invokes the swap_inode_boot_loader function to
    swap inode<5> and inode<12>. However, inode<5> contain incorrect imode and
    disordered extents, and i_nlink is set to 1. The extents check for inode in
    the ext4_iget function can be bypassed bacause 5 is EXT4_BOOT_LOADER_INO.
    While links_count is set to 1, the extents are not initialized in
    swap_inode_boot_loader. After the ioctl command is executed successfully,
    the extents are swapped to inode<12>, in this case, run the `cat` command
    to view inode<12>. And Bug_ON is triggered due to the incorrect extents.
    
    When the boot loader inode is not initialized, its imode can be one of the
    following:
    1) the imode is a bad type, which is marked as bad_inode in ext4_iget and
       set to S_IFREG.
    2) the imode is good type but not S_IFREG.
    3) the imode is S_IFREG.
    
    The BUG_ON may be triggered by bypassing the check in cases 1 and 2.
    Therefore, when the boot loader inode is bad_inode or its imode is not
    S_IFREG, initialize the inode to avoid triggering the BUG.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jason Yan <yanaijie@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221026042310.3839669-5-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix bug_on in __es_tree_search caused by bad quota inode [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Wed Oct 26 12:23:07 2022 +0800

    ext4: fix bug_on in __es_tree_search caused by bad quota inode
    
    [ Upstream commit d323877484765aaacbb2769b06e355c2041ed115 ]
    
    We got a issue as fllows:
    ==================================================================
     kernel BUG at fs/ext4/extents_status.c:202!
     invalid opcode: 0000 [#1] PREEMPT SMP
     CPU: 1 PID: 810 Comm: mount Not tainted 6.1.0-rc1-next-g9631525255e3 #352
     RIP: 0010:__es_tree_search.isra.0+0xb8/0xe0
     RSP: 0018:ffffc90001227900 EFLAGS: 00010202
     RAX: 0000000000000000 RBX: 0000000077512a0f RCX: 0000000000000000
     RDX: 0000000000000002 RSI: 0000000000002a10 RDI: ffff8881004cd0c8
     RBP: ffff888177512ac8 R08: 47ffffffffffffff R09: 0000000000000001
     R10: 0000000000000001 R11: 00000000000679af R12: 0000000000002a10
     R13: ffff888177512d88 R14: 0000000077512a10 R15: 0000000000000000
     FS: 00007f4bd76dbc40(0000)GS:ffff88842fd00000(0000)knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 00005653bf993cf8 CR3: 000000017bfdf000 CR4: 00000000000006e0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
     Call Trace:
      <TASK>
      ext4_es_cache_extent+0xe2/0x210
      ext4_cache_extents+0xd2/0x110
      ext4_find_extent+0x5d5/0x8c0
      ext4_ext_map_blocks+0x9c/0x1d30
      ext4_map_blocks+0x431/0xa50
      ext4_getblk+0x82/0x340
      ext4_bread+0x14/0x110
      ext4_quota_read+0xf0/0x180
      v2_read_header+0x24/0x90
      v2_check_quota_file+0x2f/0xa0
      dquot_load_quota_sb+0x26c/0x760
      dquot_load_quota_inode+0xa5/0x190
      ext4_enable_quotas+0x14c/0x300
      __ext4_fill_super+0x31cc/0x32c0
      ext4_fill_super+0x115/0x2d0
      get_tree_bdev+0x1d2/0x360
      ext4_get_tree+0x19/0x30
      vfs_get_tree+0x26/0xe0
      path_mount+0x81d/0xfc0
      do_mount+0x8d/0xc0
      __x64_sys_mount+0xc0/0x160
      do_syscall_64+0x35/0x80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      </TASK>
    ==================================================================
    
    Above issue may happen as follows:
    -------------------------------------
    ext4_fill_super
     ext4_orphan_cleanup
      ext4_enable_quotas
       ext4_quota_enable
        ext4_iget --> get error inode <5>
         ext4_ext_check_inode --> Wrong imode makes it escape inspection
         make_bad_inode(inode) --> EXT4_BOOT_LOADER_INO set imode
        dquot_load_quota_inode
         vfs_setup_quota_inode --> check pass
         dquot_load_quota_sb
          v2_check_quota_file
           v2_read_header
            ext4_quota_read
             ext4_bread
              ext4_getblk
               ext4_map_blocks
                ext4_ext_map_blocks
                 ext4_find_extent
                  ext4_cache_extents
                   ext4_es_cache_extent
                    __es_tree_search.isra.0
                     ext4_es_end --> Wrong extents trigger BUG_ON
    
    In the above issue, s_usr_quota_inum is set to 5, but inode<5> contains
    incorrect imode and disordered extents. Because 5 is EXT4_BOOT_LOADER_INO,
    the ext4_ext_check_inode check in the ext4_iget function can be bypassed,
    finally, the extents that are not checked trigger the BUG_ON in the
    __es_tree_search function. To solve this issue, check whether the inode is
    bad_inode in vfs_setup_quota_inode().
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Reviewed-by: Jason Yan <yanaijie@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221026042310.3839669-2-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix corruption when online resizing a 1K bigalloc fs [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Nov 17 12:03:41 2022 +0800

    ext4: fix corruption when online resizing a 1K bigalloc fs
    
    commit 0aeaa2559d6d53358fca3e3fce73807367adca74 upstream.
    
    When a backup superblock is updated in update_backups(), the primary
    superblock's offset in the group (that is, sbi->s_sbh->b_blocknr) is used
    as the backup superblock's offset in its group. However, when the block
    size is 1K and bigalloc is enabled, the two offsets are not equal. This
    causes the backup group descriptors to be overwritten by the superblock
    in update_backups(). Moreover, if meta_bg is enabled, the file system will
    be corrupted because this feature uses backup group descriptors.
    
    To solve this issue, we use a more accurate ext4_group_first_block_no() as
    the offset of the backup superblock in its group.
    
    Fixes: d77147ff443b ("ext4: add support for online resizing with bigalloc")
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20221117040341.1380702-4-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix deadlock due to mbcache entry corruption [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Nov 23 20:39:50 2022 +0100

    ext4: fix deadlock due to mbcache entry corruption
    
    [ Upstream commit a44e84a9b7764c72896f7241a0ec9ac7e7ef38dd ]
    
    When manipulating xattr blocks, we can deadlock infinitely looping
    inside ext4_xattr_block_set() where we constantly keep finding xattr
    block for reuse in mbcache but we are unable to reuse it because its
    reference count is too big. This happens because cache entry for the
    xattr block is marked as reusable (e_reusable set) although its
    reference count is too big. When this inconsistency happens, this
    inconsistent state is kept indefinitely and so ext4_xattr_block_set()
    keeps retrying indefinitely.
    
    The inconsistent state is caused by non-atomic update of e_reusable bit.
    e_reusable is part of a bitfield and e_reusable update can race with
    update of e_referenced bit in the same bitfield resulting in loss of one
    of the updates. Fix the problem by using atomic bitops instead.
    
    This bug has been around for many years, but it became *much* easier
    to hit after commit 65f8b80053a1 ("ext4: fix race when reusing xattr
    blocks").
    
    Cc: stable@vger.kernel.org
    Fixes: 6048c64b2609 ("mbcache: add reusable flag to cache entries")
    Fixes: 65f8b80053a1 ("ext4: fix race when reusing xattr blocks")
    Reported-and-tested-by: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
    Reported-by: Thilo Fromm <t-lo@linux.microsoft.com>
    Link: https://lore.kernel.org/r/c77bf00f-4618-7149-56f1-b8d1664b9d07@linux.microsoft.com/
    Signed-off-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Link: https://lore.kernel.org/r/20221123193950.16758-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline [+ + +]
Author: Eric Whitney <enwlinux@gmail.com>
Date:   Thu Nov 17 10:22:07 2022 -0500

    ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline
    
    commit 131294c35ed6f777bd4e79d42af13b5c41bf2775 upstream.
    
    When converting files with inline data to extents, delayed allocations
    made on a file system created with both the bigalloc and inline options
    can result in invalid extent status cache content, incorrect reserved
    cluster counts, kernel memory leaks, and potential kernel panics.
    
    With bigalloc, the code that determines whether a block must be
    delayed allocated searches the extent tree to see if that block maps
    to a previously allocated cluster.  If not, the block is delayed
    allocated, and otherwise, it isn't.  However, if the inline option is
    also used, and if the file containing the block is marked as able to
    store data inline, there isn't a valid extent tree associated with
    the file.  The current code in ext4_clu_mapped() calls
    ext4_find_extent() to search the non-existent tree for a previously
    allocated cluster anyway, which typically finds nothing, as desired.
    However, a side effect of the search can be to cache invalid content
    from the non-existent tree (garbage) in the extent status tree,
    including bogus entries in the pending reservation tree.
    
    To fix this, avoid searching the extent tree when allocating blocks
    for bigalloc + inline files that are being converted from inline to
    extent mapped.
    
    Signed-off-by: Eric Whitney <enwlinux@gmail.com>
    Link: https://lore.kernel.org/r/20221117152207.2424-1-enwlinux@gmail.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix error code return to user-space in ext4_get_branch() [+ + +]
Author: Luís Henriques <lhenriques@suse.de>
Date:   Wed Nov 9 18:14:45 2022 +0000

    ext4: fix error code return to user-space in ext4_get_branch()
    
    commit 26d75a16af285a70863ba6a81f85d81e7e65da50 upstream.
    
    If a block is out of range in ext4_get_branch(), -ENOMEM will be returned
    to user-space.  Obviously, this error code isn't really useful.  This
    patch fixes it by making sure the right error code (-EFSCORRUPTED) is
    propagated to user-space.  EUCLEAN is more informative than ENOMEM.
    
    Signed-off-by: Luís Henriques <lhenriques@suse.de>
    Link: https://lore.kernel.org/r/20221109181445.17843-1-lhenriques@suse.de
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix inode leak in ext4_xattr_inode_create() on an error path [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu Dec 8 10:32:33 2022 +0800

    ext4: fix inode leak in ext4_xattr_inode_create() on an error path
    
    commit e4db04f7d3dbbe16680e0ded27ea2a65b10f766a upstream.
    
    There is issue as follows when do setxattr with inject fault:
    
    [localhost]# fsck.ext4  -fn  /dev/sda
    e2fsck 1.46.6-rc1 (12-Sep-2022)
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Unattached zero-length inode 15.  Clear? no
    
    Unattached inode 15
    Connect to /lost+found? no
    
    Pass 5: Checking group summary information
    
    /dev/sda: ********** WARNING: Filesystem still has errors **********
    
    /dev/sda: 15/655360 files (0.0% non-contiguous), 66755/2621440 blocks
    
    This occurs in 'ext4_xattr_inode_create()'. If 'ext4_mark_inode_dirty()'
    fails, dropping i_nlink of the inode is needed. Or will lead to inode leak.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221208023233.1231330-5-yebin@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix race when reusing xattr blocks [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:24 2022 +0200

    ext4: fix race when reusing xattr blocks
    
    [ Upstream commit 65f8b80053a1b2fd602daa6814e62d6fa90e5e9b ]
    
    When ext4_xattr_block_set() decides to remove xattr block the following
    race can happen:
    
    CPU1                                    CPU2
    ext4_xattr_block_set()                  ext4_xattr_release_block()
      new_bh = ext4_xattr_block_cache_find()
    
                                              lock_buffer(bh);
                                              ref = le32_to_cpu(BHDR(bh)->h_refcount);
                                              if (ref == 1) {
                                                ...
                                                mb_cache_entry_delete();
                                                unlock_buffer(bh);
                                                ext4_free_blocks();
                                                  ...
                                                  ext4_forget(..., bh, ...);
                                                    jbd2_journal_revoke(..., bh);
    
      ext4_journal_get_write_access(..., new_bh, ...)
        do_get_write_access()
          jbd2_journal_cancel_revoke(..., new_bh);
    
    Later the code in ext4_xattr_block_set() finds out the block got freed
    and cancels reusal of the block but the revoke stays canceled and so in
    case of block reuse and journal replay the filesystem can get corrupted.
    If the race works out slightly differently, we can also hit assertions
    in the jbd2 code.
    
    Fix the problem by making sure that once matching mbcache entry is
    found, code dropping the last xattr block reference (or trying to modify
    xattr block in place) waits until the mbcache entry reference is
    dropped. This way code trying to reuse xattr block is protected from
    someone trying to drop the last reference to xattr block.
    
    Reported-and-tested-by: Ritesh Harjani <ritesh.list@gmail.com>
    CC: stable@vger.kernel.org
    Fixes: 82939d7999df ("ext4: convert to mbcache2")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-5-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: a44e84a9b776 ("ext4: fix deadlock due to mbcache entry corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix reserved cluster accounting in __es_remove_extent() [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu Dec 8 11:34:24 2022 +0800

    ext4: fix reserved cluster accounting in __es_remove_extent()
    
    commit 1da18e38cb97e9521e93d63034521a9649524f64 upstream.
    
    When bigalloc is enabled, reserved cluster accounting for delayed
    allocation is handled in extent_status.c.  With a corrupted file
    system, it's possible for this accounting to be incorrect,
    dsicovered by Syzbot:
    
    EXT4-fs error (device loop0): ext4_validate_block_bitmap:398: comm rep:
            bg 0: block 5: invalid block bitmap
    EXT4-fs (loop0): Delayed block allocation failed for inode 18 at logical
            offset 0 with max blocks 32 with error 28
    EXT4-fs (loop0): This should not happen!! Data will be lost
    
    EXT4-fs (loop0): Total free blocks count 0
    EXT4-fs (loop0): Free/Dirty block details
    EXT4-fs (loop0): free_blocks=0
    EXT4-fs (loop0): dirty_blocks=32
    EXT4-fs (loop0): Block reservation details
    EXT4-fs (loop0): i_reserved_data_blocks=2
    EXT4-fs (loop0): Inode 18 (00000000845cd634):
            i_reserved_data_blocks (1) not cleared!
    
    Above issue happens as follows:
    Assume:
    sbi->s_cluster_ratio = 16
    Step1:
    Insert delay block [0, 31] -> ei->i_reserved_data_blocks=2
    Step2:
    ext4_writepages
      mpage_map_and_submit_extent -> return failed
      mpage_release_unused_pages -> to release [0, 30]
        ext4_es_remove_extent -> remove lblk=0 end=30
          __es_remove_extent -> len1=0 len2=31-30=1
     __es_remove_extent:
     ...
     if (len2 > 0) {
      ...
              if (len1 > 0) {
                      ...
              } else {
                    es->es_lblk = end + 1;
                    es->es_len = len2;
                    ...
              }
            if (count_reserved)
                    count_rsvd(inode, lblk, ...);
            goto out; -> will return but didn't calculate 'reserved'
     ...
    Step3:
    ext4_destroy_inode -> trigger "i_reserved_data_blocks (1) not cleared!"
    
    To solve above issue if 'len2>0' call 'get_rsvd()' before goto out.
    
    Reported-by: syzbot+05a0f0ccab4a25626e38@syzkaller.appspotmail.com
    Fixes: 8fcc3a580651 ("ext4: rework reserved cluster accounting when invalidating pages")
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Eric Whitney <enwlinux@gmail.com>
    Link: https://lore.kernel.org/r/20221208033426.1832460-2-yebin@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix undefined behavior in bit shift for ext4_check_flag_values [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Mon Oct 31 13:58:33 2022 +0800

    ext4: fix undefined behavior in bit shift for ext4_check_flag_values
    
    commit 3bf678a0f9c017c9ba7c581541dbc8453452a7ae upstream.
    
    Shifting signed 32-bit value by 31 bits is undefined, so changing
    significant bit to unsigned. The UBSAN warning calltrace like below:
    
    UBSAN: shift-out-of-bounds in fs/ext4/ext4.h:591:2
    left shift of 1 by 31 places cannot be represented in type 'int'
    Call Trace:
     <TASK>
     dump_stack_lvl+0x7d/0xa5
     dump_stack+0x15/0x1b
     ubsan_epilogue+0xe/0x4e
     __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
     ext4_init_fs+0x5a/0x277
     do_one_initcall+0x76/0x430
     kernel_init_freeable+0x3b3/0x422
     kernel_init+0x24/0x1e0
     ret_from_fork+0x1f/0x30
     </TASK>
    
    Fixes: 9a4c80194713 ("ext4: ensure Inode flags consistency are checked at build time")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221031055833.3966222-1-cuigaosheng1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: fix uninititialized value in 'ext4_evict_inode' [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Thu Nov 17 15:36:03 2022 +0800

    ext4: fix uninititialized value in 'ext4_evict_inode'
    
    [ Upstream commit 7ea71af94eaaaf6d9aed24bc94a05b977a741cb9 ]
    
    Syzbot found the following issue:
    =====================================================
    BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180
     ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180
     evict+0x365/0x9a0 fs/inode.c:664
     iput_final fs/inode.c:1747 [inline]
     iput+0x985/0xdd0 fs/inode.c:1773
     __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361
     ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844
     vfs_mknod+0x79d/0x830 fs/namei.c:3914
     do_mknodat+0x47d/0xaa0
     __do_sys_mknodat fs/namei.c:3992 [inline]
     __se_sys_mknodat fs/namei.c:3989 [inline]
     __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989
     do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
     __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
     do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203
     do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246
     entry_SYSENTER_compat_after_hwframe+0x70/0x82
    
    Uninit was created at:
     __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578
     alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285
     alloc_slab_page mm/slub.c:1794 [inline]
     allocate_slab+0x1b5/0x1010 mm/slub.c:1939
     new_slab mm/slub.c:1992 [inline]
     ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180
     __slab_alloc mm/slub.c:3279 [inline]
     slab_alloc_node mm/slub.c:3364 [inline]
     slab_alloc mm/slub.c:3406 [inline]
     __kmem_cache_alloc_lru mm/slub.c:3413 [inline]
     kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429
     alloc_inode_sb include/linux/fs.h:3117 [inline]
     ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321
     alloc_inode+0x83/0x440 fs/inode.c:259
     new_inode_pseudo fs/inode.c:1018 [inline]
     new_inode+0x3b/0x430 fs/inode.c:1046
     __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959
     ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992
     vfs_mkdir+0x62a/0x870 fs/namei.c:4035
     do_mkdirat+0x466/0x7b0 fs/namei.c:4060
     __do_sys_mkdirat fs/namei.c:4075 [inline]
     __se_sys_mkdirat fs/namei.c:4073 [inline]
     __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073
     do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
     __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
     do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203
     do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246
     entry_SYSENTER_compat_after_hwframe+0x70/0x82
    
    CPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    =====================================================
    
    Now, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failed
    before set 'ei->i_flags' in '__ext4_new_inode()', then do 'iput()'. As after
    6bc0d63dad7f commit will access 'ei->i_flags' in 'ext4_evict_inode()' which
    will lead to access uninit-value.
    To solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'.
    
    Reported-by: syzbot+57b25da729eb0b88177d@syzkaller.appspotmail.com
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Fixes: 6bc0d63dad7f ("ext4: remove EA inode entry from mbcache on inode eviction")
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20221117073603.2598882-1-yebin@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix use-after-free in ext4_orphan_cleanup [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Wed Nov 2 16:06:33 2022 +0800

    ext4: fix use-after-free in ext4_orphan_cleanup
    
    [ Upstream commit a71248b1accb2b42e4980afef4fa4a27fa0e36f5 ]
    
    I caught a issue as follows:
    ==================================================================
     BUG: KASAN: use-after-free in __list_add_valid+0x28/0x1a0
     Read of size 8 at addr ffff88814b13f378 by task mount/710
    
     CPU: 1 PID: 710 Comm: mount Not tainted 6.1.0-rc3-next #370
     Call Trace:
      <TASK>
      dump_stack_lvl+0x73/0x9f
      print_report+0x25d/0x759
      kasan_report+0xc0/0x120
      __asan_load8+0x99/0x140
      __list_add_valid+0x28/0x1a0
      ext4_orphan_cleanup+0x564/0x9d0 [ext4]
      __ext4_fill_super+0x48e2/0x5300 [ext4]
      ext4_fill_super+0x19f/0x3a0 [ext4]
      get_tree_bdev+0x27b/0x450
      ext4_get_tree+0x19/0x30 [ext4]
      vfs_get_tree+0x49/0x150
      path_mount+0xaae/0x1350
      do_mount+0xe2/0x110
      __x64_sys_mount+0xf0/0x190
      do_syscall_64+0x35/0x80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      </TASK>
     [...]
    ==================================================================
    
    Above issue may happen as follows:
    -------------------------------------
    ext4_fill_super
      ext4_orphan_cleanup
       --- loop1: assume last_orphan is 12 ---
        list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan)
        ext4_truncate --> return 0
          ext4_inode_attach_jinode --> return -ENOMEM
        iput(inode) --> free inode<12>
       --- loop2: last_orphan is still 12 ---
        list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan);
        // use inode<12> and trigger UAF
    
    To solve this issue, we need to propagate the return value of
    ext4_inode_attach_jinode() appropriately.
    
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221102080633.1630225-1-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: goto right label 'failed_mount3a' [+ + +]
Author: Jason Yan <yanaijie@huawei.com>
Date:   Fri Sep 16 22:15:12 2022 +0800

    ext4: goto right label 'failed_mount3a'
    
    [ Upstream commit 43bd6f1b49b61f43de4d4e33661b8dbe8c911f14 ]
    
    Before these two branches neither loaded the journal nor created the
    xattr cache. So the right label to goto is 'failed_mount3a'. Although
    this did not cause any issues because the error handler validated if the
    pointer is null. However this still made me confused when reading
    the code. So it's still worth to modify to goto the right label.
    
    Signed-off-by: Jason Yan <yanaijie@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
    Link: https://lore.kernel.org/r/20220916141527.1012715-2-yanaijie@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 89481b5fa8c0 ("ext4: correct inconsistent error msg in nojournal mode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: init quota for 'old.inode' in 'ext4_rename' [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Mon Nov 7 09:53:35 2022 +0800

    ext4: init quota for 'old.inode' in 'ext4_rename'
    
    commit fae381a3d79bb94aa2eb752170d47458d778b797 upstream.
    
    Syzbot found the following issue:
    ext4_parse_param: s_want_extra_isize=128
    ext4_inode_info_init: s_want_extra_isize=32
    ext4_rename: old.inode=ffff88823869a2c8 old.dir=ffff888238699828 new.inode=ffff88823869d7e8 new.dir=ffff888238699828
    __ext4_mark_inode_dirty: inode=ffff888238699828 ea_isize=32 want_ea_size=128
    __ext4_mark_inode_dirty: inode=ffff88823869a2c8 ea_isize=32 want_ea_size=128
    ext4_xattr_block_set: inode=ffff88823869a2c8
    ------------[ cut here ]------------
    WARNING: CPU: 13 PID: 2234 at fs/ext4/xattr.c:2070 ext4_xattr_block_set.cold+0x22/0x980
    Modules linked in:
    RIP: 0010:ext4_xattr_block_set.cold+0x22/0x980
    RSP: 0018:ffff888227d3f3b0 EFLAGS: 00010202
    RAX: 0000000000000001 RBX: ffff88823007a000 RCX: 0000000000000000
    RDX: 0000000000000a03 RSI: 0000000000000040 RDI: ffff888230078178
    RBP: 0000000000000000 R08: 000000000000002c R09: ffffed1075c7df8e
    R10: ffff8883ae3efc6b R11: ffffed1075c7df8d R12: 0000000000000000
    R13: ffff88823869a2c8 R14: ffff8881012e0460 R15: dffffc0000000000
    FS:  00007f350ac1f740(0000) GS:ffff8883ae200000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f350a6ed6a0 CR3: 0000000237456000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     ? ext4_xattr_set_entry+0x3b7/0x2320
     ? ext4_xattr_block_set+0x0/0x2020
     ? ext4_xattr_set_entry+0x0/0x2320
     ? ext4_xattr_check_entries+0x77/0x310
     ? ext4_xattr_ibody_set+0x23b/0x340
     ext4_xattr_move_to_block+0x594/0x720
     ext4_expand_extra_isize_ea+0x59a/0x10f0
     __ext4_expand_extra_isize+0x278/0x3f0
     __ext4_mark_inode_dirty.cold+0x347/0x410
     ext4_rename+0xed3/0x174f
     vfs_rename+0x13a7/0x2510
     do_renameat2+0x55d/0x920
     __x64_sys_rename+0x7d/0xb0
     do_syscall_64+0x3b/0xa0
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
    
    As 'ext4_rename' will modify 'old.inode' ctime and mark inode dirty,
    which may trigger expand 'extra_isize' and allocate block. If inode
    didn't init quota will lead to warning.  To solve above issue, init
    'old.inode' firstly in 'ext4_rename'.
    
    Reported-by: syzbot+98346927678ac3059c77@syzkaller.appspotmail.com
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221107015335.2524319-1-yebin@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: initialize quota before expanding inode in setproject ioctl [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Dec 7 12:59:27 2022 +0100

    ext4: initialize quota before expanding inode in setproject ioctl
    
    commit 1485f726c6dec1a1f85438f2962feaa3d585526f upstream.
    
    Make sure we initialize quotas before possibly expanding inode space
    (and thus maybe needing to allocate external xattr block) in
    ext4_ioctl_setproject(). This prevents not accounting the necessary
    block allocation.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Cc: stable@kernel.org
    Link: https://lore.kernel.org/r/20221207115937.26601-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ext4: lost matching-pair of trace in ext4_truncate [+ + +]
Author: zhengliang <zhengliang6@huawei.com>
Date:   Wed Jul 1 16:30:27 2020 +0800

    ext4: lost matching-pair of trace in ext4_truncate
    
    [ Upstream commit 9a5d265fed014115f35e598022c956e5d2fb863e ]
    
    It should call trace exit in all return path for ext4_truncate.
    
    Signed-off-by: zhengliang <zhengliang6@huawei.com>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Reviewed-by: Ritesh Harjani <riteshh@linux.ibm.com>
    Link: https://lore.kernel.org/r/20200701083027.45996-1-zhengliang6@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: a71248b1accb ("ext4: fix use-after-free in ext4_orphan_cleanup")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: remove EA inode entry from mbcache on inode eviction [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:22 2022 +0200

    ext4: remove EA inode entry from mbcache on inode eviction
    
    [ Upstream commit 6bc0d63dad7f9f54d381925ee855b402f652fa39 ]
    
    Currently we remove EA inode from mbcache as soon as its xattr refcount
    drops to zero. However there can be pending attempts to reuse the inode
    and thus refcount handling code has to handle the situation when
    refcount increases from zero anyway. So save some work and just keep EA
    inode in mbcache until it is getting evicted. At that moment we are sure
    following iget() of EA inode will fail anyway (or wait for eviction to
    finish and load things from the disk again) and so removing mbcache
    entry at that moment is fine and simplifies the code a bit.
    
    CC: stable@vger.kernel.org
    Fixes: 82939d7999df ("ext4: convert to mbcache2")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-3-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: a44e84a9b776 ("ext4: fix deadlock due to mbcache entry corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: unindent codeblock in ext4_xattr_block_set() [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:23 2022 +0200

    ext4: unindent codeblock in ext4_xattr_block_set()
    
    [ Upstream commit fd48e9acdf26d0cbd80051de07d4a735d05d29b2 ]
    
    Remove unnecessary else (and thus indentation level) from a code block
    in ext4_xattr_block_set(). It will also make following code changes
    easier. No functional changes.
    
    CC: stable@vger.kernel.org
    Fixes: 82939d7999df ("ext4: convert to mbcache2")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-4-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: a44e84a9b776 ("ext4: fix deadlock due to mbcache entry corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: use kmemdup() to replace kmalloc + memcpy [+ + +]
Author: Shuqi Zhang <zhangshuqi3@huawei.com>
Date:   Wed May 25 11:01:20 2022 +0800

    ext4: use kmemdup() to replace kmalloc + memcpy
    
    [ Upstream commit 4efd9f0d120c55b08852ee5605dbb02a77089a5d ]
    
    Replace kmalloc + memcpy with kmemdup()
    
    Signed-off-by: Shuqi Zhang <zhangshuqi3@huawei.com>
    Reviewed-by: Ritesh Harjani <ritesh.list@gmail.com>
    Link: https://lore.kernel.org/r/20220525030120.803330-1-zhangshuqi3@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: a44e84a9b776 ("ext4: fix deadlock due to mbcache entry corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: use memcpy_to_page() in pagecache_write() [+ + +]
Author: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Date:   Sun Feb 7 11:04:23 2021 -0800

    ext4: use memcpy_to_page() in pagecache_write()
    
    [ Upstream commit bd256fda92efe97b692dc72e246d35fa724d42d8 ]
    
    Signed-off-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Link: https://lore.kernel.org/r/20210207190425.38107-7-chaitanya.kulkarni@wdc.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: 956510c0c743 ("fs: ext4: initialize fsdata in pagecache_write()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
f2fs: avoid victim selection from previous victim section [+ + +]
Author: Yonggil Song <yonggil.song@samsung.com>
Date:   Tue Nov 22 18:03:20 2022 +0900

    f2fs: avoid victim selection from previous victim section
    
    [ Upstream commit e219aecfd4b766c4e878a3769057e9809f7fcadc ]
    
    When f2fs chooses GC victim in large section & LFS mode,
    next_victim_seg[gc_type] is referenced first. After segment is freed,
    next_victim_seg[gc_type] has the next segment number.
    However, next_victim_seg[gc_type] still has the last segment number
    even after the last segment of section is freed. In this case, when f2fs
    chooses a victim for the next GC round, the last segment of previous victim
    section is chosen as a victim.
    
    Initialize next_victim_seg[gc_type] to NULL_SEGNO for the last segment in
    large section.
    
    Fixes: e3080b0120a1 ("f2fs: support subsectional garbage collection")
    Signed-off-by: Yonggil Song <yonggil.song@samsung.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: fix normal discard process [+ + +]
Author: Dongdong Zhang <zhangdongdong1@oppo.com>
Date:   Tue Oct 25 17:40:36 2022 +0800

    f2fs: fix normal discard process
    
    [ Upstream commit b5f1a218ae5e4339130d6e733f0e63d623e09a2c ]
    
    In the DPOLICY_BG mode, there is a conflict between
    the two conditions "i + 1 < dpolicy->granularity" and
    "i < DEFAULT_DISCARD_GRANULARITY". If i = 15, the first
    condition is false, it will enter the second condition
    and dispatch all small granularity discards in function
     __issue_discard_cmd_orderly. The restrictive effect
    of the first condition to small discards will be
    invalidated. These two conditions should align.
    
    Fixes: 20ee4382322c ("f2fs: issue small discard by LBA order")
    Signed-off-by: Dongdong Zhang <zhangdongdong1@oppo.com>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

f2fs: should put a page when checking the summary info [+ + +]
Author: Pavel Machek <pavel@denx.de>
Date:   Mon Oct 24 19:30:12 2022 +0200

    f2fs: should put a page when checking the summary info
    
    commit c3db3c2fd9992c08f49aa93752d3c103c3a4f6aa upstream.
    
    The commit introduces another bug.
    
    Cc: stable@vger.kernel.org
    Fixes: c6ad7fd16657e ("f2fs: fix to do sanity check on summary info")
    Signed-off-by: Pavel Machek <pavel@denx.de>
    Reviewed-by: Chao Yu <chao@kernel.org>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fbdev: pm2fb: fix missing pci_disable_device() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Sat Nov 12 17:55:10 2022 +0800

    fbdev: pm2fb: fix missing pci_disable_device()
    
    [ Upstream commit ed359a464846b48f76ea6cc5cd8257e545ac97f4 ]
    
    Add missing pci_disable_device() in error path of probe() and remove() path.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: ssd1307fb: Drop optional dependency [+ + +]
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Nov 1 17:09:46 2022 +0200

    fbdev: ssd1307fb: Drop optional dependency
    
    [ Upstream commit 025e3b507a3a8e1ee96a3112bb67495c77d6cdb6 ]
    
    Only a single out of three devices need a PWM, so from driver it's
    optional. Moreover it's a single driver in the entire kernel that
    currently selects PWM. Unfortunately this selection is a root cause
    of the circular dependencies when we want to enable optional PWM
    for some other drivers that select GPIOLIB.
    
    Fixes: a2ed00da5047 ("drivers/video: add support for the Solomon SSD1307 OLED Controller")
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: uvesafb: Fixes an error handling path in uvesafb_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Dec 10 12:35:22 2022 +0100

    fbdev: uvesafb: Fixes an error handling path in uvesafb_probe()
    
    [ Upstream commit a94371040712031ba129c7e9d8ff04a06a2f8207 ]
    
    If an error occurs after a successful uvesafb_init_mtrr() call, it must be
    undone by a corresponding arch_phys_wc_del() call, as already done in the
    remove function.
    
    This has been added in the remove function in commit 63e28a7a5ffc
    ("uvesafb: Clean up MTRR code")
    
    Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: vermilion: decrease reference count in error path [+ + +]
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Mon Nov 14 16:56:54 2022 +0800

    fbdev: vermilion: decrease reference count in error path
    
    [ Upstream commit 001f2cdb952a9566c77fb4b5470cc361db5601bb ]
    
    pci_get_device() will increase the reference count for the returned
    pci_dev. For the error path, we need to use pci_dev_put() to decrease
    the reference count.
    
    Fixes: dbe7e429fedb ("vmlfb: framebuffer driver for Intel Vermilion Range")
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fbdev: via: Fix error in via_core_init() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Mon Nov 14 09:08:52 2022 +0800

    fbdev: via: Fix error in via_core_init()
    
    [ Upstream commit 5886b130de953cfb8826f7771ec8640a79934a7f ]
    
    via_core_init() won't exit the driver when pci_register_driver() failed.
    Exit the viafb-i2c and the viafb-gpio in failed path to prevent error.
    
    VIA Graphics Integration Chipset framebuffer 2.4 initializing
    Error: Driver 'viafb-i2c' is already registered, aborting...
    Error: Driver 'viafb-gpio' is already registered, aborting...
    
    Fixes: 7582eb9be85f ("viafb: Turn GPIO and i2c into proper platform devices")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs: don't audit the capability check in simple_xattr_list() [+ + +]
Author: Ondrej Mosnacek <omosnace@redhat.com>
Date:   Thu Nov 3 16:12:05 2022 +0100

    fs: don't audit the capability check in simple_xattr_list()
    
    [ Upstream commit e7eda157c4071cd1e69f4b1687b0fbe1ae5e6f46 ]
    
    The check being unconditional may lead to unwanted denials reported by
    LSMs when a process has the capability granted by DAC, but denied by an
    LSM. In the case of SELinux such denials are a problem, since they can't
    be effectively filtered out via the policy and when not silenced, they
    produce noise that may hide a true problem or an attack.
    
    Checking for the capability only if any trusted xattr is actually
    present wouldn't really address the issue, since calling listxattr(2) on
    such node on its own doesn't indicate an explicit attempt to see the
    trusted xattrs. Additionally, it could potentially leak the presence of
    trusted xattrs to an unprivileged user if they can check for the denials
    (e.g. through dmesg).
    
    Therefore, it's best (and simplest) to keep the check unconditional and
    instead use ns_capable_noaudit() that will silence any associated LSM
    denials.
    
    Fixes: 38f38657444d ("xattr: extract simple_xattr code from tmpfs")
    Reported-by: Martin Pitt <mpitt@redhat.com>
    Suggested-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
    Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Reviewed-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: ext4: initialize fsdata in pagecache_write() [+ + +]
Author: Alexander Potapenko <glider@google.com>
Date:   Mon Nov 21 12:21:30 2022 +0100

    fs: ext4: initialize fsdata in pagecache_write()
    
    [ Upstream commit 956510c0c7439e90b8103aaeaf4da92878c622f0 ]
    
    When aops->write_begin() does not initialize fsdata, KMSAN reports
    an error passing the latter to aops->write_end().
    
    Fix this by unconditionally initializing fsdata.
    
    Cc: Eric Biggers <ebiggers@kernel.org>
    Fixes: c93d8f885809 ("ext4: add basic fs-verity support")
    Reported-by: syzbot+9767be679ef5016b6082@syzkaller.appspotmail.com
    Signed-off-by: Alexander Potapenko <glider@google.com>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20221121112134.407362-1-glider@google.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: jfs: fix shift-out-of-bounds in dbAllocAG [+ + +]
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date:   Tue Oct 18 08:48:07 2022 -0500

    fs: jfs: fix shift-out-of-bounds in dbAllocAG
    
    [ Upstream commit 898f706695682b9954f280d95e49fa86ffa55d08 ]
    
    Syzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. The
    underlying bug is the missing check of bmp->db_agl2size. The field can
    be greater than 64 and trigger the shift-out-of-bounds.
    
    Fix this bug by adding a check of bmp->db_agl2size in dbMount since this
    field is used in many following functions. The upper bound for this
    field is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.
    Note that, for maintenance, I reorganized error handling code of dbMount.
    
    Reported-by: syzbot+15342c1aa6a00fb7a438@syzkaller.appspotmail.com
    Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: jfs: fix shift-out-of-bounds in dbDiscardAG [+ + +]
Author: Hoi Pok Wu <wuhoipok@gmail.com>
Date:   Tue Oct 25 23:20:45 2022 +0800

    fs: jfs: fix shift-out-of-bounds in dbDiscardAG
    
    [ Upstream commit 25e70c6162f207828dd405b432d8f2a98dbf7082 ]
    
    This should be applied to most URSAN bugs found recently by syzbot,
    by guarding the dbMount. As syzbot feeding rubbish into the bmap
    descriptor.
    
    Signed-off-by: Hoi Pok Wu <wuhoipok@gmail.com>
    Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: sysv: Fix sysv_nblocks() returns wrong value [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Fri Dec 9 18:04:48 2022 +0800

    fs: sysv: Fix sysv_nblocks() returns wrong value
    
    [ Upstream commit e0c49bd2b4d3cd1751491eb2d940bce968ac65e9 ]
    
    sysv_nblocks() returns 'blocks' rather than 'res', which only counting
    the number of triple-indirect blocks and causing sysv_getattr() gets a
    wrong result.
    
    [AV: this is actually a sysv counterpart of minixfs fix -
    0fcd426de9d0 "[PATCH] minix block usage counting fix" in
    historical tree; mea culpa, should've thought to check
    fs/sysv back then...]
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
gcov: add support for checksum field [+ + +]
Author: Rickard x Andersson <rickaran@axis.com>
Date:   Tue Dec 20 11:23:18 2022 +0100

    gcov: add support for checksum field
    
    commit e96b95c2b7a63a454b6498e2df67aac14d046d13 upstream.
    
    In GCC version 12.1 a checksum field was added.
    
    This patch fixes a kernel crash occurring during boot when using
    gcov-kernel with GCC version 12.2.  The crash occurred on a system running
    on i.MX6SX.
    
    Link: https://lkml.kernel.org/r/20221220102318.3418501-1-rickaran@axis.com
    Fixes: 977ef30a7d88 ("gcov: support GCC 12.1 and newer compilers")
    Signed-off-by: Rickard x Andersson <rickaran@axis.com>
    Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Tested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
    Reviewed-by: Martin Liska <mliska@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
genirq/irqdesc: Don't try to remove non-existing sysfs files [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Nov 28 23:16:12 2022 +0800

    genirq/irqdesc: Don't try to remove non-existing sysfs files
    
    [ Upstream commit 9049e1ca41983ab773d7ea244bee86d7835ec9f5 ]
    
    Fault injection tests trigger warnings like this:
    
      kernfs: can not remove 'chip_name', no directory
      WARNING: CPU: 0 PID: 253 at fs/kernfs/dir.c:1616 kernfs_remove_by_name_ns+0xce/0xe0
      RIP: 0010:kernfs_remove_by_name_ns+0xce/0xe0
      Call Trace:
       <TASK>
       remove_files.isra.1+0x3f/0xb0
       sysfs_remove_group+0x68/0xe0
       sysfs_remove_groups+0x41/0x70
       __kobject_del+0x45/0xc0
       kobject_del+0x29/0x40
       free_desc+0x42/0x70
       irq_free_descs+0x5e/0x90
    
    The reason is that the interrupt descriptor sysfs handling does not roll
    back on a failing kobject_add() during allocation. If the descriptor is
    freed later on, kobject_del() is invoked with a not added kobject resulting
    in the above warnings.
    
    A proper rollback in case of a kobject_add() failure would be the straight
    forward solution. But this is not possible due to the way how interrupt
    descriptor sysfs handling works.
    
    Interrupt descriptors are allocated before sysfs becomes available. So the
    sysfs files for the early allocated descriptors are added later in the boot
    process. At this point there can be nothing useful done about a failing
    kobject_add(). For consistency the interrupt descriptor allocation always
    treats kobject_add() failures as non-critical and just emits a warning.
    
    To solve this problem, keep track in the interrupt descriptor whether
    kobject_add() was successful or not and make the invocation of
    kobject_del() conditional on that.
    
    [ tglx: Massage changelog, comments and use a state bit. ]
    
    Fixes: ecb3f394c5db ("genirq: Expose interrupt information through sysfs")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20221128151612.1786122-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hamradio: baycom_epp: Fix return type of baycom_send_packet() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Nov 2 09:06:10 2022 -0700

    hamradio: baycom_epp: Fix return type of baycom_send_packet()
    
    [ Upstream commit c5733e5b15d91ab679646ec3149e192996a27d5d ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed. A
    proposed warning in clang aims to catch these at compile time, which
    reveals:
    
      drivers/net/hamradio/baycom_epp.c:1119:25: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .ndo_start_xmit      = baycom_send_packet,
                                    ^~~~~~~~~~~~~~~~~~
      1 error generated.
    
    ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
    'netdev_tx_t', not 'int'. Adjust the return type of baycom_send_packet()
    to match the prototype's to resolve the warning and CFI failure.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1750
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221102160610.1186145-1-nathan@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hamradio: don't call dev_kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Dec 8 22:21:46 2022 +0800

    hamradio: don't call dev_kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 3727f742915f04f6fc550b80cf406999bd4e90d0 ]
    
    It is not allowed to call kfree_skb() or consume_skb() from hardware
    interrupt context or with hardware interrupts being disabled.
    
    It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
    The difference between them is free reason, dev_kfree_skb_irq() means
    the SKB is dropped in error and dev_consume_skb_irq() means the SKB
    is consumed in normal.
    
    In scc_discard_buffers(), dev_kfree_skb() is called to discard the SKBs,
    so replace it with dev_kfree_skb_irq().
    
    In scc_net_tx(), dev_kfree_skb() is called to drop the SKB that exceed
    queue length, so replace it with dev_kfree_skb_irq().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hfs/hfsplus: avoid WARN_ON() for sanity check, use proper error handling [+ + +]
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Jan 4 11:06:28 2023 -0800

    hfs/hfsplus: avoid WARN_ON() for sanity check, use proper error handling
    
    commit cb7a95af78d29442b8294683eca4897544b8ef46 upstream.
    
    Commit 55d1cbbbb29e ("hfs/hfsplus: use WARN_ON for sanity check") fixed
    a build warning by turning a comment into a WARN_ON(), but it turns out
    that syzbot then complains because it can trigger said warning with a
    corrupted hfs image.
    
    The warning actually does warn about a bad situation, but we are much
    better off just handling it as the error it is.  So rather than warn
    about us doing bad things, stop doing the bad things and return -EIO.
    
    While at it, also fix a memory leak that was introduced by an earlier
    fix for a similar syzbot warning situation, and add a check for one case
    that historically wasn't handled at all (ie neither comment nor
    subsequent WARN_ON).
    
    Reported-by: syzbot+7bb7cd3595533513a9e7@syzkaller.appspotmail.com
    Fixes: 55d1cbbbb29e ("hfs/hfsplus: use WARN_ON for sanity check")
    Fixes: 8d824e69d9f3 ("hfs: fix OOB Read in __hfs_brec_find")
    Link: https://lore.kernel.org/lkml/000000000000dbce4e05f170f289@google.com/
    Tested-by: Michael Schmitz <schmitzmic@gmail.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Viacheslav Dubeyko <slava@dubeyko.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

hfs/hfsplus: use WARN_ON for sanity check [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Nov 8 18:35:04 2021 -0800

    hfs/hfsplus: use WARN_ON for sanity check
    
    commit 55d1cbbbb29e6656c662ee8f73ba1fc4777532eb upstream.
    
    gcc warns about a couple of instances in which a sanity check exists but
    the author wasn't sure how to react to it failing, which makes it look
    like a possible bug:
    
      fs/hfsplus/inode.c: In function 'hfsplus_cat_read_inode':
      fs/hfsplus/inode.c:503:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
        503 |                         /* panic? */;
            |                                     ^
      fs/hfsplus/inode.c:524:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
        524 |                         /* panic? */;
            |                                     ^
      fs/hfsplus/inode.c: In function 'hfsplus_cat_write_inode':
      fs/hfsplus/inode.c:582:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
        582 |                         /* panic? */;
            |                                     ^
      fs/hfsplus/inode.c:608:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
        608 |                         /* panic? */;
            |                                     ^
      fs/hfs/inode.c: In function 'hfs_write_inode':
      fs/hfs/inode.c:464:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
        464 |                         /* panic? */;
            |                                     ^
      fs/hfs/inode.c:485:37: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body]
        485 |                         /* panic? */;
            |                                     ^
    
    panic() is probably not the correct choice here, but a WARN_ON
    seems appropriate and avoids the compile-time warning.
    
    Link: https://lkml.kernel.org/r/20210927102149.1809384-1-arnd@kernel.org
    Link: https://lore.kernel.org/all/20210322223249.2632268-1-arnd@kernel.org/
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Christian Brauner <christian.brauner@ubuntu.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Jan Kara <jack@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hfs: fix OOB Read in __hfs_brec_find [+ + +]
Author: ZhangPeng <zhangpeng362@huawei.com>
Date:   Wed Nov 30 06:59:59 2022 +0000

    hfs: fix OOB Read in __hfs_brec_find
    
    [ Upstream commit 8d824e69d9f3fa3121b2dda25053bae71e2460d2 ]
    
    Syzbot reported a OOB read bug:
    
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190
    fs/hfs/string.c:84
    Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11
    CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted
    6.1.0-rc6-syzkaller-00308-g644e9524388a #0
    Workqueue: writeback wb_workfn (flush-7:0)
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
     print_address_description+0x74/0x340 mm/kasan/report.c:284
     print_report+0x107/0x1f0 mm/kasan/report.c:395
     kasan_report+0xcd/0x100 mm/kasan/report.c:495
     hfs_strcmp+0x117/0x190 fs/hfs/string.c:84
     __hfs_brec_find+0x213/0x5c0 fs/hfs/bfind.c:75
     hfs_brec_find+0x276/0x520 fs/hfs/bfind.c:138
     hfs_write_inode+0x34c/0xb40 fs/hfs/inode.c:462
     write_inode fs/fs-writeback.c:1440 [inline]
    
    If the input inode of hfs_write_inode() is incorrect:
    struct inode
      struct hfs_inode_info
        struct hfs_cat_key
          struct hfs_name
            u8 len # len is greater than HFS_NAMELEN(31) which is the
    maximum length of an HFS filename
    
    OOB read occurred:
    hfs_write_inode()
      hfs_brec_find()
        __hfs_brec_find()
          hfs_cat_keycmp()
            hfs_strcmp() # OOB read occurred due to len is too large
    
    Fix this by adding a Check on len in hfs_write_inode() before calling
    hfs_brec_find().
    
    Link: https://lkml.kernel.org/r/20221130065959.2168236-1-zhangpeng362@huawei.com
    Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
    Reported-by: <syzbot+e836ff7133ac02be825f@syzkaller.appspotmail.com>
    Cc: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Cc: Ira Weiny <ira.weiny@intel.com>
    Cc: Jeff Layton <jlayton@kernel.org>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Nanyong Sun <sunnanyong@huawei.com>
    Cc: Viacheslav Dubeyko <slava@dubeyko.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hfs: Fix OOB Write in hfs_asc2mac [+ + +]
Author: ZhangPeng <zhangpeng362@huawei.com>
Date:   Fri Dec 2 03:00:38 2022 +0000

    hfs: Fix OOB Write in hfs_asc2mac
    
    [ Upstream commit c53ed55cb275344086e32a7080a6b19cb183650b ]
    
    Syzbot reported a OOB Write bug:
    
    loop0: detected capacity change from 0 to 64
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in hfs_asc2mac+0x467/0x9a0
    fs/hfs/trans.c:133
    Write of size 1 at addr ffff88801848314e by task syz-executor391/3632
    
    Call Trace:
     <TASK>
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
     print_address_description+0x74/0x340 mm/kasan/report.c:284
     print_report+0x107/0x1f0 mm/kasan/report.c:395
     kasan_report+0xcd/0x100 mm/kasan/report.c:495
     hfs_asc2mac+0x467/0x9a0 fs/hfs/trans.c:133
     hfs_cat_build_key+0x92/0x170 fs/hfs/catalog.c:28
     hfs_lookup+0x1ab/0x2c0 fs/hfs/dir.c:31
     lookup_open fs/namei.c:3391 [inline]
     open_last_lookups fs/namei.c:3481 [inline]
     path_openat+0x10e6/0x2df0 fs/namei.c:3710
     do_filp_open+0x264/0x4f0 fs/namei.c:3740
    
    If in->len is much larger than HFS_NAMELEN(31) which is the maximum
    length of an HFS filename, a OOB write could occur in hfs_asc2mac(). In
    that case, when the dst reaches the boundary, the srclen is still
    greater than 0, which causes a OOB write.
    Fix this by adding a check on dstlen in while() before writing to dst
    address.
    
    Link: https://lkml.kernel.org/r/20221202030038.1391945-1-zhangpeng362@huawei.com
    Fixes: 328b92278650 ("[PATCH] hfs: NLS support")
    Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
    Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
    Reported-by: <syzbot+dc3b1cf9111ab5fe98e7@syzkaller.appspotmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hfsplus: fix bug causing custom uid and gid being unable to be assigned with mount [+ + +]
Author: Aditya Garg <gargaditya08@live.com>
Date:   Wed Dec 7 03:05:40 2022 +0000

    hfsplus: fix bug causing custom uid and gid being unable to be assigned with mount
    
    commit 9f2b5debc07073e6dfdd774e3594d0224b991927 upstream.
    
    Despite specifying UID and GID in mount command, the specified UID and GID
    were not being assigned. This patch fixes this issue.
    
    Link: https://lkml.kernel.org/r/C0264BF5-059C-45CF-B8DA-3A3BD2C803A2@live.com
    Signed-off-by: Aditya Garg <gargaditya08@live.com>
    Reviewed-by: Viacheslav Dubeyko <slava@dubeyko.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HID: hid-sensor-custom: set fixed size for custom attributes [+ + +]
Author: Marcus Folkesson <marcus.folkesson@gmail.com>
Date:   Thu Nov 17 13:13:26 2022 +0100

    HID: hid-sensor-custom: set fixed size for custom attributes
    
    [ Upstream commit 9d013910df22de91333a0acc81d1dbb115bd76f6 ]
    
    This is no bugfix (so no Fixes: tag is necessary) as it is
    taken care of in hid_sensor_custom_add_attributes().
    
    The motivation for this patch is that:
    hid_sensor_custom_field.attr_name and
    hid_sensor_custom_field.attrs
    has the size of HID_CUSTOM_TOTAL_ATTRS and used in same context.
    
    We compare against HID_CUSTOM_TOTAL_ATTRS when
    looping through hid_custom_attrs.
    
    We will silent the smatch error:
    hid_sensor_custom_add_attributes() error: buffer overflow
    'hid_custom_attrs' 8 <= 10
    
    Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
    Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: ite: Add support for Acer S1002 keyboard-dock [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Nov 25 23:37:45 2020 +0100

    HID: ite: Add support for Acer S1002 keyboard-dock
    
    [ Upstream commit c961facb5b19634eee5bcdd91fc5bf3f1c545bc5 ]
    
    Make the hid-ite driver handle the Acer S1002 keyboard-dock, this
    leads to 2 improvements:
    
    1. The non working wifi-toggle hotkey now works.
    2. Toggling the touchpad on of with the hotkey will no show OSD
    notifications in e.g. GNOME3. The actual toggling is handled inside
    the keyboard, this adds support for notifying evdev listeners about this.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Stable-dep-of: 9ad6645a9dce ("HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch V 10")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch 10E [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Sat Feb 6 21:53:27 2021 +0100

    HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch 10E
    
    [ Upstream commit b7c20f3815985570ac71c39b1a3e68c201109578 ]
    
    The Acer Aspire Switch 10E (SW3-016)'s keyboard-dock uses the same USB-ids
    as the Acer One S1003 keyboard-dock. Yet they are not entirely the same:
    
    1. The S1003 keyboard-dock has the same report descriptors as the
    S1002 keyboard-dock (which has different USB-ids)
    
    2. The Acer Aspire Switch 10E's keyboard-dock has different
    report descriptors from the S1002/S1003 keyboard docks and it
    sends 0x00880078 / 0x00880079 usage events when the touchpad is
    toggled on/off (which is handled internally).
    
    This means that all Acer kbd-docks handled by the hid-ite.c drivers
    report their touchpad being toggled on/off through these custom
    usage-codes with the exception of the S1003 dock, which likely is
    a bug of that dock.
    
    Add a QUIRK_TOUCHPAD_ON_OFF_REPORT quirk for the Aspire Switch 10E / S1003
    usb-id so that the touchpad toggling will get reported to userspace on
    the Aspire Switch 10E.
    
    Since the Aspire Switch 10E's kbd-dock has different report-descriptors,
    this also requires adding support for fixing those to ite_report_fixup().
    
    Setting the quirk will also cause ite_report_fixup() to hit the
    S1002/S1003 descriptors path on the S1003. Since the S1003 kbd-dock
    never generates any input-reports for the fixed up part of the
    descriptors this does not matter; and if there are versions out there
    which do actually send input-reports for the touchpad-toggle then the
    fixup should actually help to make things work.
    
    This was tested on both an Acer Aspire Switch 10E and on an Acer One S1003.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Stable-dep-of: 9ad6645a9dce ("HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch V 10")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch V 10 [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Nov 8 16:13:50 2022 +0100

    HID: ite: Enable QUIRK_TOUCHPAD_ON_OFF_REPORT on Acer Aspire Switch V 10
    
    [ Upstream commit 9ad6645a9dce4d0e42daca6ebf32a154401c59d3 ]
    
    The Acer Aspire Switch V 10 (SW5-017)'s keyboard-dock uses the same
    ITE controller setup as other Acer Switch 2-in-1's.
    
    This needs special handling for the wifi on/off toggle hotkey as well as
    to properly report touchpad on/off keypresses.
    
    Add the USB-ids for the SW5-017's keyboard-dock with a quirk setting of
    QUIRK_TOUCHPAD_ON_OFF_REPORT to fix both issues.
    
    Cc: Rudolf Polzer <rpolzer@google.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: multitouch: fix Asus ExpertBook P2 P2451FA trackpoint [+ + +]
Author: José Expósito <jose.exposito89@gmail.com>
Date:   Mon Nov 28 17:57:05 2022 +0100

    HID: multitouch: fix Asus ExpertBook P2 P2451FA trackpoint
    
    [ Upstream commit 4eab1c2fe06c98a4dff258dd64800b6986c101e9 ]
    
    The HID descriptor of this device contains two mouse collections, one
    for mouse emulation and the other for the trackpoint.
    
    Both collections get merged and, because the first one defines X and Y,
    the movemenent events reported by the trackpoint collection are
    ignored.
    
    Set the MT_CLS_WIN_8_FORCE_MULTI_INPUT class for this device to be able
    to receive its reports.
    
    This fix is similar to/based on commit 40d5bb87377a ("HID: multitouch:
    enable multi-input as a quirk for some devices").
    
    Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/825
    Reported-by: Akito <the@akito.ooo>
    Tested-by: Akito <the@akito.ooo>
    Signed-off-by: José Expósito <jose.exposito89@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: plantronics: Additional PIDs for double volume key presses quirk [+ + +]
Author: Terry Junge <linuxhid@cosmicgizmosystems.com>
Date:   Thu Dec 8 15:05:06 2022 -0800

    HID: plantronics: Additional PIDs for double volume key presses quirk
    
    [ Upstream commit 3d57f36c89d8ba32b2c312f397a37fd1a2dc7cfc ]
    
    I no longer work for Plantronics (aka Poly, aka HP) and do not have
    access to the headsets in order to test. However, as noted by Maxim,
    the other 32xx models that share the same base code set as the 3220
    would need the same quirk. This patch adds the PIDs for the rest of
    the Blackwire 32XX product family that require the quirk.
    
    Plantronics Blackwire 3210 Series (047f:c055)
    Plantronics Blackwire 3215 Series (047f:c057)
    Plantronics Blackwire 3225 Series (047f:c058)
    
    Quote from previous patch by Maxim Mikityanskiy
    Plantronics Blackwire 3220 Series (047f:c056) sends HID reports twice
    for each volume key press. This patch adds a quirk to hid-plantronics
    for this product ID, which will ignore the second volume key press if
    it happens within 5 ms from the last one that was handled.
    
    The patch was tested on the mentioned model only, it shouldn't affect
    other models, however, this quirk might be needed for them too.
    Auto-repeat (when a key is held pressed) is not affected, because the
    rate is about 3 times per second, which is far less frequent than once
    in 5 ms.
    End quote
    
    Signed-off-by: Terry Junge <linuxhid@cosmicgizmosystems.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirk [+ + +]
Author: José Expósito <jose.exposito89@gmail.com>
Date:   Thu Nov 10 18:40:56 2022 +0100

    HID: uclogic: Add HID_QUIRK_HIDINPUT_FORCE quirk
    
    [ Upstream commit 3405a4beaaa852f3ed2a5eb3b5149932d5c3779b ]
    
    Commit f7d8e387d9ae ("HID: uclogic: Switch to Digitizer usage for
    styluses") changed the usage used in UCLogic from "Pen" to "Digitizer".
    
    However, the IS_INPUT_APPLICATION() macro evaluates to false for
    HID_DG_DIGITIZER causing issues with the XP-Pen Star G640 tablet.
    
    Add the HID_QUIRK_HIDINPUT_FORCE quirk to bypass the
    IS_INPUT_APPLICATION() check.
    
    Reported-by: Torge Matthies <openglfreak@googlemail.com>
    Reported-by: Alexander Zhang <alex@alexyzhang.dev>
    Tested-by: Alexander Zhang <alex@alexyzhang.dev>
    Signed-off-by: José Expósito <jose.exposito89@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HID: wacom: Ensure bootloader PID is usable in hidraw mode [+ + +]
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Thu Dec 1 15:11:41 2022 -0800

    HID: wacom: Ensure bootloader PID is usable in hidraw mode
    
    commit 1db1f392591aff13fd643f0ec7c1d5e27391d700 upstream.
    
    Some Wacom devices have a special "bootloader" mode that is used for
    firmware flashing. When operating in this mode, the device cannot be
    used for input, and the HID descriptor is not able to be processed by
    the driver. The driver generates an "Unknown device_type" warning and
    then returns an error code from wacom_probe(). This is a problem because
    userspace still needs to be able to interact with the device via hidraw
    to perform the firmware flash.
    
    This commit adds a non-generic device definition for 056a:0094 which
    is used when devices are in "bootloader" mode. It marks the devices
    with a special BOOTLOADER type that is recognized by wacom_probe() and
    wacom_raw_event(). When we see this type we ensure a hidraw device is
    created and otherwise keep our hands off so that userspace is in full
    control.
    
    Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
    Tested-by: Tatsunosuke Tobita <tatsunosuke.tobita@wacom.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HSI: omap_ssi_core: Fix error handling in ssi_init() [+ + +]
Author: Yuan Can <yuancan@huawei.com>
Date:   Thu Nov 24 11:33:32 2022 +0000

    HSI: omap_ssi_core: Fix error handling in ssi_init()
    
    [ Upstream commit 3ffa9f713c39a213a08d9ff13ab983a8aa5d8b5d ]
    
    The ssi_init() returns the platform_driver_register() directly without
    checking its return value, if platform_driver_register() failed, the
    ssi_pdriver is not unregistered.
    Fix by unregister ssi_pdriver when the last platform_driver_register()
    failed.
    
    Fixes: 0fae198988b8 ("HSI: omap_ssi: built omap_ssi and omap_ssi_port into one module")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HSI: omap_ssi_core: fix possible memory leak in ssi_probe() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Oct 31 15:43:37 2022 +0800

    HSI: omap_ssi_core: fix possible memory leak in ssi_probe()
    
    [ Upstream commit 1aff514e1d2bd47854dbbdf867970b9d463d4c57 ]
    
    If ssi_add_controller() returns error, it should call hsi_put_controller()
    to give up the reference that was set in hsi_alloc_controller(), so that
    it can call hsi_controller_release() to free controller and ports that
    allocated in hsi_alloc_controller().
    
    Fixes: b209e047bc74 ("HSI: Introduce OMAP SSI driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

HSI: omap_ssi_core: fix unbalanced pm_runtime_disable() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 1 11:41:18 2022 +0800

    HSI: omap_ssi_core: fix unbalanced pm_runtime_disable()
    
    [ Upstream commit f5181c35ed7ba0ceb6e42872aad1334d994b0175 ]
    
    In error label 'out1' path in ssi_probe(), the pm_runtime_enable()
    has not been called yet, so pm_runtime_disable() is not needed.
    
    Fixes: b209e047bc74 ("HSI: Introduce OMAP SSI driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hsr: Avoid double remove of a node. [+ + +]
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Nov 29 17:48:10 2022 +0100

    hsr: Avoid double remove of a node.
    
    [ Upstream commit 0c74d9f79ec4299365bbe803baa736ae0068179e ]
    
    Due to the hashed-MAC optimisation one problem become visible:
    hsr_handle_sup_frame() walks over the list of available nodes and merges
    two node entries into one if based on the information in the supervision
    both MAC addresses belong to one node. The list-walk happens on a RCU
    protected list and delete operation happens under a lock.
    
    If the supervision arrives on both slave interfaces at the same time
    then this delete operation can occur simultaneously on two CPUs. The
    result is the first-CPU deletes the from the list and the second CPUs
    BUGs while attempting to dereference a poisoned list-entry. This happens
    more likely with the optimisation because a new node for the mac_B entry
    is created once a packet has been received and removed (merged) once the
    supervision frame has been received.
    
    Avoid removing/ cleaning up a hsr_node twice by adding a `removed' field
    which is set to true after the removal and checked before the removal.
    
    Fixes: f266a683a4804 ("net/hsr: Better frame dispatch")
    Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param() [+ + +]
Author: Hawkins Jiawei <yin31149@gmail.com>
Date:   Fri Oct 21 07:16:08 2022 +0800

    hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param()
    
    [ Upstream commit 26215b7ee923b9251f7bb12c4e5f09dc465d35f2 ]
    
    Syzkaller reports a null-ptr-deref bug as follows:
    ======================================================
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380
    [...]
    Call Trace:
     <TASK>
     vfs_parse_fs_param fs/fs_context.c:148 [inline]
     vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129
     vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191
     generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231
     do_new_mount fs/namespace.c:3036 [inline]
     path_mount+0x12de/0x1e20 fs/namespace.c:3370
     do_mount fs/namespace.c:3383 [inline]
     __do_sys_mount fs/namespace.c:3591 [inline]
     __se_sys_mount fs/namespace.c:3568 [inline]
     __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
     [...]
     </TASK>
    ======================================================
    
    According to commit "vfs: parse: deal with zero length string value",
    kernel will set the param->string to null pointer in vfs_parse_fs_string()
    if fs string has zero length.
    
    Yet the problem is that, hugetlbfs_parse_param() will dereference the
    param->string, without checking whether it is a null pointer.  To be more
    specific, if hugetlbfs_parse_param() parses an illegal mount parameter,
    such as "size=,", kernel will constructs struct fs_parameter with null
    pointer in vfs_parse_fs_string(), then passes this struct fs_parameter to
    hugetlbfs_parse_param(), which triggers the above null-ptr-deref bug.
    
    This patch solves it by adding sanity check on param->string
    in hugetlbfs_parse_param().
    
    Link: https://lkml.kernel.org/r/20221020231609.4810-1-yin31149@gmail.com
    Reported-by: syzbot+a3e6acd85ded5c16a709@syzkaller.appspotmail.com
    Tested-by: syzbot+a3e6acd85ded5c16a709@syzkaller.appspotmail.com
      Link: https://lore.kernel.org/all/0000000000005ad00405eb7148c6@google.com/
    Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
    Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
    Cc: Hawkins Jiawei <yin31149@gmail.com>
    Cc: Muchun Song <songmuchun@bytedance.com>
    Cc: Ian Kent <raven@themaw.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hvc/xen: lock console list traversal [+ + +]
Author: Roger Pau Monne <roger.pau@citrix.com>
Date:   Wed Nov 30 17:36:02 2022 +0100

    hvc/xen: lock console list traversal
    
    [ Upstream commit c0dccad87cf68fc6012aec7567e354353097ec1a ]
    
    The currently lockless access to the xen console list in
    vtermno_to_xencons() is incorrect, as additions and removals from the
    list can happen anytime, and as such the traversal of the list to get
    the private console data for a given termno needs to happen with the
    lock held.  Note users that modify the list already do so with the
    lock taken.
    
    Adjust current lock takers to use the _irq{save,restore} helpers,
    since the context in which vtermno_to_xencons() is called can have
    interrupts disabled.  Use the _irq{save,restore} set of helpers to
    switch the current callers to disable interrupts in the locked region.
    I haven't checked if existing users could instead use the _irq
    variant, as I think it's safer to use _irq{save,restore} upfront.
    
    While there switch from using list_for_each_entry_safe to
    list_for_each_entry: the current entry cursor won't be removed as
    part of the code in the loop body, so using the _safe variant is
    pointless.
    
    Fixes: 02e19f9c7cac ('hvc_xen: implement multiconsole support')
    Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
    Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
    Link: https://lore.kernel.org/r/20221130163611.14686-1-roger.pau@citrix.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwrng: amd - Fix PCI device refcount leak [+ + +]
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Fri Dec 2 21:22:33 2022 +0800

    hwrng: amd - Fix PCI device refcount leak
    
    [ Upstream commit ecadb5b0111ea19fc7c240bb25d424a94471eb7d ]
    
    for_each_pci_dev() is implemented by pci_get_device(). The comment of
    pci_get_device() says that it will increase the reference count for the
    returned pci_dev and also decrease the reference count for the input
    pci_dev @from if it is not NULL.
    
    If we break for_each_pci_dev() loop with pdev not NULL, we need to call
    pci_dev_put() to decrease the reference count. Add the missing
    pci_dev_put() for the normal and error path.
    
    Fixes: 96d63c0297cc ("[PATCH] Add AMD HW RNG driver")
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

hwrng: geode - Fix PCI device refcount leak [+ + +]
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Fri Dec 2 21:22:34 2022 +0800

    hwrng: geode - Fix PCI device refcount leak
    
    [ Upstream commit 9f6ec8dc574efb7f4f3d7ee9cd59ae307e78f445 ]
    
    for_each_pci_dev() is implemented by pci_get_device(). The comment of
    pci_get_device() says that it will increase the reference count for the
    returned pci_dev and also decrease the reference count for the input
    pci_dev @from if it is not NULL.
    
    If we break for_each_pci_dev() loop with pdev not NULL, we need to call
    pci_dev_put() to decrease the reference count. We add a new struct
    'amd_geode_priv' to record pointer of the pci_dev and membase, and then
    add missing pci_dev_put() for the normal and error path.
    
    Fixes: ef5d862734b8 ("[PATCH] Add Geode HW RNG driver")
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i2c: ismt: Fix an out-of-bounds bug in ismt_access() [+ + +]
Author: Zheyu Ma <zheyuma97@gmail.com>
Date:   Fri Jul 29 19:02:16 2022 +0800

    i2c: ismt: Fix an out-of-bounds bug in ismt_access()
    
    [ Upstream commit 39244cc754829bf707dccd12e2ce37510f5b1f8d ]
    
    When the driver does not check the data from the user, the variable
    'data->block[0]' may be very large to cause an out-of-bounds bug.
    
    The following log can reveal it:
    
    [   33.995542] i2c i2c-1: ioctl, cmd=0x720, arg=0x7ffcb3dc3a20
    [   33.995978] ismt_smbus 0000:00:05.0: I2C_SMBUS_BLOCK_DATA:  WRITE
    [   33.996475] ==================================================================
    [   33.996995] BUG: KASAN: out-of-bounds in ismt_access.cold+0x374/0x214b
    [   33.997473] Read of size 18446744073709551615 at addr ffff88810efcfdb1 by task ismt_poc/485
    [   33.999450] Call Trace:
    [   34.001849]  memcpy+0x20/0x60
    [   34.002077]  ismt_access.cold+0x374/0x214b
    [   34.003382]  __i2c_smbus_xfer+0x44f/0xfb0
    [   34.004007]  i2c_smbus_xfer+0x10a/0x390
    [   34.004291]  i2cdev_ioctl_smbus+0x2c8/0x710
    [   34.005196]  i2cdev_ioctl+0x5ec/0x74c
    
    Fix this bug by checking the size of 'data->block[0]' first.
    
    Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller")
    Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

i2c: pxa-pci: fix missing pci_disable_device() on error in ce4100_i2c_probe [+ + +]
Author: Hui Tang <tanghui20@huawei.com>
Date:   Mon Nov 14 17:25:40 2022 +0800

    i2c: pxa-pci: fix missing pci_disable_device() on error in ce4100_i2c_probe
    
    [ Upstream commit d78a167332e1ca8113268ed922c1212fd71b73ad ]
    
    Using pcim_enable_device() to avoid missing pci_disable_device().
    
    Fixes: 7e94dd154e93 ("i2c-pxa2xx: Add PCI support for PXA I2C controller")
    Signed-off-by: Hui Tang <tanghui20@huawei.com>
    Signed-off-by: Wolfram Sang <wsa@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/IPoIB: Fix queue count inconsistency for PKEY child interfaces [+ + +]
Author: Dragos Tatulea <dtatulea@nvidia.com>
Date:   Thu Dec 8 09:52:54 2022 +0200

    IB/IPoIB: Fix queue count inconsistency for PKEY child interfaces
    
    [ Upstream commit dbc94a0fb81771a38733c0e8f2ea8c4fa6934dc1 ]
    
    There are 2 ways to create IPoIB PKEY child interfaces:
    1) Writing a PKEY to /sys/class/net/<ib parent interface>/create_child.
    2) Using netlink with iproute.
    
    While with sysfs the child interface has the same number of tx and
    rx queues as the parent, with netlink there will always be 1 tx
    and 1 rx queue for the child interface. That's because the
    get_num_tx/rx_queues() netlink ops are missing and the default value
    of 1 is taken for the number of queues (in rtnl_create_link()).
    
    This change adds the get_num_tx/rx_queues() ops which allows for
    interfaces with multiple queues to be created over netlink. This
    constant only represents the max number of tx and rx queues on that
    net device.
    
    Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
    Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
    Link: https://lore.kernel.org/r/f4a42c8aa43c02d5ae5559a60c3e5e0f18c82531.1670485816.git.leonro@nvidia.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
igb: Do not free q_vector unless new one was allocated [+ + +]
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Oct 18 02:25:24 2022 -0700

    igb: Do not free q_vector unless new one was allocated
    
    [ Upstream commit 0668716506ca66f90d395f36ccdaebc3e0e84801 ]
    
    Avoid potential use-after-free condition under memory pressure. If the
    kzalloc() fails, q_vector will be freed but left in the original
    adapter->q_vector[v_idx] array position.
    
    Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: intel-wired-lan@lists.osuosl.org
    Cc: netdev@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

igb: Initialize mailbox message for VF reset [+ + +]
Author: Tony Nguyen <anthony.l.nguyen@intel.com>
Date:   Mon Dec 12 11:00:31 2022 -0800

    igb: Initialize mailbox message for VF reset
    
    commit de5dc44370fbd6b46bd7f1a1e00369be54a041c8 upstream.
    
    When a MAC address is not assigned to the VF, that portion of the message
    sent to the VF is not set. The memory, however, is allocated from the
    stack meaning that information may be leaked to the VM. Initialize the
    message buffer to 0 so that no information is passed to the VM in this
    case.
    
    Fixes: 6ddbc4cf1f4d ("igb: Indicate failure on vf reset for empty mac address")
    Reported-by: Akihiko Odaki <akihiko.odaki@daynix.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/20221212190031.3983342-1-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
iio: adc128s052: add proper .data members in adc128_of_match table [+ + +]
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Tue Nov 15 14:23:23 2022 +0100

    iio: adc128s052: add proper .data members in adc128_of_match table
    
    commit e2af60f5900c6ade53477b494ffb54690eee11f5 upstream.
    
    Prior to commit bd5d54e4d49d ("iio: adc128s052: add ACPI _HID
    AANT1280"), the driver unconditionally used spi_get_device_id() to get
    the index into the adc128_config array.
    
    However, with that commit, OF-based boards now incorrectly treat all
    supported sensors as if they are an adc128s052, because all the .data
    members of the adc128_of_match table are implicitly 0. Our board,
    which has an adc122s021, thus exposes 8 channels whereas it really
    only has two.
    
    Fixes: bd5d54e4d49d ("iio: adc128s052: add ACPI _HID AANT1280")
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Link: https://lore.kernel.org/r/20221115132324.1078169-1-linux@rasmusvillemoes.dk
    Cc: <Stable@vger.kernel.org>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iio: adc: ad_sigma_delta: do not use internal iio_dev lock [+ + +]
Author: Nuno Sá <nuno.sa@analog.com>
Date:   Tue Sep 20 13:28:07 2022 +0200

    iio: adc: ad_sigma_delta: do not use internal iio_dev lock
    
    commit 20228a1d5a55e7db0c6720840f2c7d2b48c55f69 upstream.
    
    Drop 'mlock' usage by making use of iio_device_claim_direct_mode().
    This change actually makes sure we cannot do a single conversion while
    buffering is enable. Note there was a potential race in the previous
    code since we were only acquiring the lock after checking if the bus is
    enabled.
    
    Fixes: af3008485ea0 ("iio:adc: Add common code for ADI Sigma Delta devices")
    Signed-off-by: Nuno Sá <nuno.sa@analog.com>
    Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Cc: <Stable@vger.kernel.org> #No rush as race is very old.
    Link: https://lore.kernel.org/r/20220920112821.975359-2-nuno.sa@analog.com
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ima: Fix a potential NULL pointer access in ima_restore_measurement_list [+ + +]
Author: Huaxin Lu <luhuaxin1@huawei.com>
Date:   Thu Nov 3 00:09:49 2022 +0800

    ima: Fix a potential NULL pointer access in ima_restore_measurement_list
    
    commit 11220db412edae8dba58853238f53258268bdb88 upstream.
    
    In restore_template_fmt, when kstrdup fails, a non-NULL value will still be
    returned, which causes a NULL pointer access in template_desc_init_fields.
    
    Fixes: c7d09367702e ("ima: support restoring multiple template formats")
    Cc: stable@kernel.org
    Co-developed-by: Jiaming Li <lijiaming30@huawei.com>
    Signed-off-by: Jiaming Li <lijiaming30@huawei.com>
    Signed-off-by: Huaxin Lu <luhuaxin1@huawei.com>
    Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ima: Fix fall-through warnings for Clang [+ + +]
Author: Gustavo A. R. Silva <gustavoars@kernel.org>
Date:   Fri Nov 20 12:25:46 2020 -0600

    ima: Fix fall-through warnings for Clang
    
    [ Upstream commit 28073eb09c5aa29e879490edb88cfd3e7073821e ]
    
    In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
    warnings by explicitly adding multiple break statements instead of just
    letting the code fall through to the next case.
    
    Link: https://github.com/KSPP/linux/issues/115
    Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Stable-dep-of: c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ima: Fix misuse of dereference of pointer in template_desc_init_fields() [+ + +]
Author: Xiu Jianfeng <xiujianfeng@huawei.com>
Date:   Sat Nov 12 17:27:19 2022 +0800

    ima: Fix misuse of dereference of pointer in template_desc_init_fields()
    
    [ Upstream commit 25369175ce84813dd99d6604e710dc2491f68523 ]
    
    The input parameter @fields is type of struct ima_template_field ***, so
    when allocates array memory for @fields, the size of element should be
    sizeof(**field) instead of sizeof(*field).
    
    Actually the original code would not cause any runtime error, but it's
    better to make it logically right.
    
    Fixes: adf53a778a0a ("ima: new templates management mechanism")
    Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
    Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ima: Handle -ESTALE returned by ima_filter_rule_match() [+ + +]
Author: GUO Zihua <guozihua@huawei.com>
Date:   Wed Sep 21 20:58:04 2022 +0800

    ima: Handle -ESTALE returned by ima_filter_rule_match()
    
    [ Upstream commit c7423dbdbc9ecef7fff5239d144cad4b9887f4de ]
    
    IMA relies on the blocking LSM policy notifier callback to update the
    LSM based IMA policy rules.
    
    When SELinux update its policies, IMA would be notified and starts
    updating all its lsm rules one-by-one. During this time, -ESTALE would
    be returned by ima_filter_rule_match() if it is called with a LSM rule
    that has not yet been updated. In ima_match_rules(), -ESTALE is not
    handled, and the LSM rule is considered a match, causing extra files
    to be measured by IMA.
    
    Fix it by re-initializing a temporary rule if -ESTALE is returned by
    ima_filter_rule_match(). The origin rule in the rule list would be
    updated by the LSM policy notifier callback.
    
    Fixes: b16942455193 ("ima: use the lsm policy update notifier")
    Signed-off-by: GUO Zihua <guozihua@huawei.com>
    Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ima: Rename internal filter rule functions [+ + +]
Author: Tyler Hicks <tyhicks@linux.microsoft.com>
Date:   Fri Jul 10 15:37:50 2020 -0500

    ima: Rename internal filter rule functions
    
    [ Upstream commit b8867eedcf76caef8ae6412da97cd9abfd092ff8 ]
    
    Rename IMA's internal filter rule functions from security_filter_rule_*()
    to ima_filter_rule_*(). This avoids polluting the security_* namespace,
    which is typically reserved for general security subsystem
    infrastructure.
    
    Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
    Suggested-by: Casey Schaufler <casey@schaufler-ca.com>
    [zohar@linux.ibm.com: reword using the term "filter", not "audit"]
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Stable-dep-of: c7423dbdbc9e ("ima: Handle -ESTALE returned by ima_filter_rule_match()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
include/uapi/linux/swab: Fix potentially missing __always_inline [+ + +]
Author: Matt Redfearn <matt.redfearn@mips.com>
Date:   Tue Sep 27 14:52:56 2022 -0700

    include/uapi/linux/swab: Fix potentially missing __always_inline
    
    [ Upstream commit defbab270d45e32b068e7e73c3567232d745c60f ]
    
    Commit bc27fb68aaad ("include/uapi/linux/byteorder, swab: force inlining
    of some byteswap operations") added __always_inline to swab functions
    and commit 283d75737837 ("uapi/linux/stddef.h: Provide __always_inline to
    userspace headers") added a definition of __always_inline for use in
    exported headers when the kernel's compiler.h is not available.
    
    However, since swab.h does not include stddef.h, if the header soup does
    not indirectly include it, the definition of __always_inline is missing,
    resulting in a compilation failure, which was observed compiling the
    perf tool using exported headers containing this commit:
    
    In file included from /usr/include/linux/byteorder/little_endian.h:12:0,
                     from /usr/include/asm/byteorder.h:14,
                     from tools/include/uapi/linux/perf_event.h:20,
                     from perf.h:8,
                     from builtin-bench.c:18:
    /usr/include/linux/swab.h:160:8: error: unknown type name `__always_inline'
     static __always_inline __u16 __swab16p(const __u16 *p)
    
    Fix this by replacing the inclusion of linux/compiler.h with
    linux/stddef.h to ensure that we pick up that definition if required,
    without relying on it's indirect inclusion. compiler.h is then included
    indirectly, via stddef.h.
    
    Fixes: 283d75737837 ("uapi/linux/stddef.h: Provide __always_inline to userspace headers")
    Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Tested-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Petr Vaněk <arkamar@atlas.cz>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Input: elants_i2c - properly handle the reset GPIO when power is off [+ + +]
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Nov 17 21:49:19 2022 -0800

    Input: elants_i2c - properly handle the reset GPIO when power is off
    
    [ Upstream commit a85fbd6498441694475716a4d5c65f9d3e073faf ]
    
    As can be seen in elants_i2c_power_off(), we want the reset GPIO
    asserted when power is off. The reset GPIO is active low so we need
    the reset line logic low when power is off to avoid leakage.
    
    We have a problem, though, at probe time. At probe time we haven't
    powered the regulators on yet but we have:
    
      devm_gpiod_get(&client->dev, "reset", GPIOD_OUT_LOW);
    
    While that _looks_ right, it turns out that it's not. The
    GPIOD_OUT_LOW doesn't mean to init the GPIO to low. It means init the
    GPIO to "not asserted". Since this is an active low GPIO that inits it
    to be high.
    
    Let's fix this to properly init the GPIO. Now after both probe and
    power off the state of the GPIO is consistent (it's "asserted" or
    level low).
    
    Once we fix this, we can see that at power on time we no longer to
    assert the reset GPIO as the first thing. The reset GPIO is _always_
    asserted before powering on. Let's fix powering on to account for
    this.
    
    Fixes: afe10358e47a ("Input: elants_i2c - wire up regulator support")
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://lore.kernel.org/r/20221117123805.1.I9959ac561dd6e1e8e1ce7085e4de6167b27c574f@changeid
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
integrity: Fix memory leakage in keyring allocation error path [+ + +]
Author: GUO Zihua <guozihua@huawei.com>
Date:   Fri Nov 11 18:13:17 2022 +0800

    integrity: Fix memory leakage in keyring allocation error path
    
    [ Upstream commit 39419ef7af0916cc3620ecf1ed42d29659109bf3 ]
    
    Key restriction is allocated in integrity_init_keyring(). However, if
    keyring allocation failed, it is not freed, causing memory leaks.
    
    Fixes: 2b6aa412ff23 ("KEYS: Use structure to capture key restriction function and data")
    Signed-off-by: GUO Zihua <guozihua@huawei.com>
    Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/amd: Fix ivrs_acpihid cmdline parsing code [+ + +]
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Mon Sep 19 10:56:37 2022 -0500

    iommu/amd: Fix ivrs_acpihid cmdline parsing code
    
    commit 5f18e9f8868c6d4eae71678e7ebd4977b7d8c8cf upstream.
    
    The second (UID) strcmp in acpi_dev_hid_uid_match considers
    "0" and "00" different, which can prevent device registration.
    
    Have the AMD IOMMU driver's ivrs_acpihid parsing code remove
    any leading zeroes to make the UID strcmp succeed.  Now users
    can safely specify "AMDxxxxx:00" or "AMDxxxxx:0" and expect
    the same behaviour.
    
    Fixes: ca3bf5d47cec ("iommu/amd: Introduces ivrs_acpihid kernel parameter")
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Cc: stable@vger.kernel.org
    Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
    Cc: Joerg Roedel <jroedel@suse.de>
    Link: https://lore.kernel.org/r/20220919155638.391481-1-kim.phillips@amd.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

iommu/amd: Fix pci device refcount leak in ppr_notifier() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Nov 18 17:36:04 2022 +0800

    iommu/amd: Fix pci device refcount leak in ppr_notifier()
    
    [ Upstream commit 6cf0981c2233f97d56938d9d61845383d6eb227c ]
    
    As comment of pci_get_domain_bus_and_slot() says, it returns
    a pci device with refcount increment, when finish using it,
    the caller must decrement the reference count by calling
    pci_dev_put(). So call it before returning from ppr_notifier()
    to avoid refcount leak.
    
    Fixes: daae2d25a477 ("iommu/amd: Don't copy GCR3 table root pointer")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221118093604.216371-1-yangyingliang@huawei.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/fsl_pamu: Fix resource leak in fsl_pamu_probe() [+ + +]
Author: Yuan Can <yuancan@huawei.com>
Date:   Mon Nov 21 08:20:22 2022 +0000

    iommu/fsl_pamu: Fix resource leak in fsl_pamu_probe()
    
    [ Upstream commit 73f5fc5f884ad0c5f7d57f66303af64f9f002526 ]
    
    The fsl_pamu_probe() returns directly when create_csd() failed, leaving
    irq and memories unreleased.
    Fix by jumping to error if create_csd() returns error.
    
    Fixes: 695093e38c3e ("iommu/fsl: Freescale PAMU driver and iommu implementation.")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Link: https://lore.kernel.org/r/20221121082022.19091-1-yuancan@huawei.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
iommu/mediatek-v1: Add error handle for mtk_iommu_probe [+ + +]
Author: Yong Wu <yong.wu@mediatek.com>
Date:   Mon Apr 12 14:48:43 2021 +0800

    iommu/mediatek-v1: Add error handle for mtk_iommu_probe
    
    [ Upstream commit ac304c070c54413efabf29f9e73c54576d329774 ]
    
    In the original code, we lack the error handle. This patch adds them.
    
    Signed-off-by: Yong Wu <yong.wu@mediatek.com>
    Link: https://lore.kernel.org/r/20210412064843.11614-2-yong.wu@mediatek.com
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Stable-dep-of: 142e821f68cf ("iommu/mediatek-v1: Fix an error handling path in mtk_iommu_v1_probe()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

iommu/mediatek-v1: Fix an error handling path in mtk_iommu_v1_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Dec 19 19:06:22 2022 +0100

    iommu/mediatek-v1: Fix an error handling path in mtk_iommu_v1_probe()
    
    [ Upstream commit 142e821f68cf5da79ce722cb9c1323afae30e185 ]
    
    A clk, prepared and enabled in mtk_iommu_v1_hw_init(), is not released in
    the error handling path of mtk_iommu_v1_probe().
    
    Add the corresponding clk_disable_unprepare(), as already done in the
    remove function.
    
    Fixes: b17336c55d89 ("iommu/mediatek: add support for mtk iommu generation one HW")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Reviewed-by: Yong Wu <yong.wu@mediatek.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
    Link: https://lore.kernel.org/r/593e7b7d97c6e064b29716b091a9d4fd122241fb.1671473163.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Joerg Roedel <jroedel@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipmi: fix long wait in unload when IPMI disconnect [+ + +]
Author: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>
Date:   Fri Oct 7 17:26:16 2022 +0800

    ipmi: fix long wait in unload when IPMI disconnect
    
    commit f6f1234d98cce69578bfac79df147a1f6660596c upstream.
    
    When fixing the problem mentioned in PATCH1, we also found
    the following problem:
    
    If the IPMI is disconnected and in the sending process, the
    uninstallation driver will be stuck for a long time.
    
    The main problem is that uninstalling the driver waits for curr_msg to
    be sent or HOSED. After stopping tasklet, the only place to trigger the
    timeout mechanism is the circular poll in shutdown_smi.
    
    The poll function delays 10us and calls smi_event_handler(smi_info,10).
    Smi_event_handler deducts 10us from kcs->ibf_timeout.
    
    But the poll func is followed by schedule_timeout_uninterruptible(1).
    The time consumed here is not counted in kcs->ibf_timeout.
    
    So when 10us is deducted from kcs->ibf_timeout, at least 1 jiffies has
    actually passed. The waiting time has increased by more than a
    hundredfold.
    
    Now instead of calling poll(). call smi_event_handler() directly and
    calculate the elapsed time.
    
    For verification, you can directly use ebpf to check the kcs->
    ibf_timeout for each call to kcs_event() when IPMI is disconnected.
    Decrement at normal rate before unloading. The decrement rate becomes
    very slow after unloading.
    
      $ bpftrace -e 'kprobe:kcs_event {printf("kcs->ibftimeout : %d\n",
          *(arg0+584));}'
    
    Signed-off-by: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>
    Message-Id: <20221007092617.87597-3-zhangyuchen.lcr@bytedance.com>
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ipmi: fix memleak when unload ipmi driver [+ + +]
Author: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>
Date:   Fri Oct 7 17:26:17 2022 +0800

    ipmi: fix memleak when unload ipmi driver
    
    [ Upstream commit 36992eb6b9b83f7f9cdc8e74fb5799d7b52e83e9 ]
    
    After the IPMI disconnect problem, the memory kept rising and we tried
    to unload the driver to free the memory. However, only part of the
    free memory is recovered after the driver is uninstalled. Using
    ebpf to hook free functions, we find that neither ipmi_user nor
    ipmi_smi_msg is free, only ipmi_recv_msg is free.
    
    We find that the deliver_smi_err_response call in clean_smi_msgs does
    the destroy processing on each message from the xmit_msg queue without
    checking the return value and free ipmi_smi_msg.
    
    deliver_smi_err_response is called only at this location. Adding the
    free handling has no effect.
    
    To verify, try using ebpf to trace the free function.
    
      $ bpftrace -e 'kretprobe:ipmi_alloc_recv_msg {printf("alloc rcv
          %p\n",retval);} kprobe:free_recv_msg {printf("free recv %p\n",
          arg0)} kretprobe:ipmi_alloc_smi_msg {printf("alloc smi %p\n",
            retval);} kprobe:free_smi_msg {printf("free smi  %p\n",arg0)}'
    
    Signed-off-by: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>
    Message-Id: <20221007092617.87597-4-zhangyuchen.lcr@bytedance.com>
    [Fixed the comment above handle_one_recv_msg().]
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ipmi: fix use after free in _ipmi_destroy_user() [+ + +]
Author: Dan Carpenter <error27@gmail.com>
Date:   Tue Nov 15 16:17:43 2022 +0300

    ipmi: fix use after free in _ipmi_destroy_user()
    
    commit a92ce570c81dc0feaeb12a429b4bc65686d17967 upstream.
    
    The intf_free() function frees the "intf" pointer so we cannot
    dereference it again on the next line.
    
    Fixes: cbb79863fc31 ("ipmi: Don't allow device module unload when in use")
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Message-Id: <Y3M8xa1drZv4CToE@kili>
    Cc: <stable@vger.kernel.org> # 5.5+
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ipv6: raw: Deduct extension header length in rawv6_push_pending_frames [+ + +]
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Jan 10 08:59:06 2023 +0800

    ipv6: raw: Deduct extension header length in rawv6_push_pending_frames
    
    commit cb3e9864cdbe35ff6378966660edbcbac955fe17 upstream.
    
    The total cork length created by ip6_append_data includes extension
    headers, so we must exclude them when comparing them against the
    IPV6_CHECKSUM offset which does not include extension headers.
    
    Reported-by: Kyle Zeng <zengyhkyle@gmail.com>
    Fixes: 357b40a18b04 ("[IPV6]: IPV6_CHECKSUM socket option can corrupt kernel memory")
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
irqchip: gic-pm: Use pm_runtime_resume_and_get() in gic_probe() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Thu Nov 24 14:51:50 2022 +0800

    irqchip: gic-pm: Use pm_runtime_resume_and_get() in gic_probe()
    
    [ Upstream commit f9ee20c85b3a3ba0afd3672630ec4f93d339f015 ]
    
    gic_probe() calls pm_runtime_get_sync() and added fail path as
    rpm_put to put usage_counter. However, pm_runtime_get_sync()
    will increment usage_counter even it failed. Fix it by replacing it with
    pm_runtime_resume_and_get() to keep usage counter balanced.
    
    Fixes: 9c8edddfc992 ("irqchip/gic: Add platform driver for non-root GICs that require RPM")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/20221124065150.22809-1-shangxiaojing@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ixgbe: fix pci device refcount leak [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 29 09:57:48 2022 +0800

    ixgbe: fix pci device refcount leak
    
    commit b93fb4405fcb5112c5739c5349afb52ec7f15c07 upstream.
    
    As the comment of pci_get_domain_bus_and_slot() says, it
    returns a PCI device with refcount incremented, when finish
    using it, the caller must decrement the reference count by
    calling pci_dev_put().
    
    In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),
    pci_dev_put() is called to avoid leak.
    
    Fixes: 8fa10ef01260 ("ixgbe: register a mdiobus")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
jbd2: use the correct print format [+ + +]
Author: Bixuan Cui <cuibixuan@linux.alibaba.com>
Date:   Tue Oct 11 19:33:44 2022 +0800

    jbd2: use the correct print format
    
    [ Upstream commit d87a7b4c77a997d5388566dd511ca8e6b8e8a0a8 ]
    
    The print format error was found when using ftrace event:
        <...>-1406 [000] .... 23599442.895823: jbd2_end_commit: dev 252,8 transaction -1866216965 sync 0 head -1866217368
        <...>-1406 [000] .... 23599442.896299: jbd2_start_commit: dev 252,8 transaction -1866216964 sync 0
    
    Use the correct print format for transaction, head and tid.
    
    Fixes: 879c5e6b7cb4 ('jbd2: convert instrumentation from markers to tracepoints')
    Signed-off-by: Bixuan Cui <cuibixuan@linux.alibaba.com>
    Reviewed-by: Jason Yan <yanaijie@huawei.com>
    Link: https://lore.kernel.org/r/1665488024-95172-1-git-send-email-cuibixuan@linux.alibaba.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kest.pl: Fix grub2 menu handling for rebooting [+ + +]
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Wed Nov 30 17:54:34 2022 -0500

    kest.pl: Fix grub2 menu handling for rebooting
    
    commit 26df05a8c1420ad3de314fdd407e7fc2058cc7aa upstream.
    
    grub2 has submenus where to use grub-reboot, it requires:
    
      grub-reboot X>Y
    
    where X is the main index and Y is the submenu. Thus if you have:
    
    menuentry 'Debian GNU/Linux' --class debian --class gnu-linux ...
            [...]
    }
    submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option ...
            menuentry 'Debian GNU/Linux, with Linux 6.0.0-4-amd64' --class debian --class gnu-linux ...
                    [...]
            }
            menuentry 'Debian GNU/Linux, with Linux 6.0.0-4-amd64 (recovery mode)' --class debian --class gnu-linux ...
                    [...]
            }
            menuentry 'Debian GNU/Linux, with Linux test' --class debian --class gnu-linux ...
                    [...]
            }
    
    And wanted to boot to the "Linux test" kernel, you need to run:
    
     # grub-reboot 1>2
    
    As 1 is the second top menu (the submenu) and 2 is the third of the sub
    menu entries.
    
    Have the grub.cfg parsing for grub2 handle such cases.
    
    Cc: stable@vger.kernel.org
    Fixes: a15ba91361d46 ("ktest: Add support for grub2")
    Reviewed-by: John 'Warthog9' Hawley (VMware) <warthog9@eaglescrag.net>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ktest.pl minconfig: Unset configs instead of just removing them [+ + +]
Author: Steven Rostedt <rostedt@goodmis.org>
Date:   Fri Dec 2 11:59:36 2022 -0500

    ktest.pl minconfig: Unset configs instead of just removing them
    
    commit ef784eebb56425eed6e9b16e7d47e5c00dcf9c38 upstream.
    
    After a full run of a make_min_config test, I noticed there were a lot of
    CONFIGs still enabled that really should not be. Looking at them, I
    noticed they were all defined as "default y". The issue is that the test
    simple removes the config and re-runs make oldconfig, which enables it
    again because it is set to default 'y'. Instead, explicitly disable the
    config with writing "# CONFIG_FOO is not set" to the file to keep it from
    being set again.
    
    With this change, one of my box's minconfigs went from 768 configs set,
    down to 521 configs set.
    
    Link: https://lkml.kernel.org/r/20221202115936.016fce23@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Fixes: 0a05c769a9de5 ("ktest: Added config_bisect test type")
    Reviewed-by: John 'Warthog9' Hawley (VMware) <warthog9@eaglescrag.net>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KVM: arm64: Fix S1PTW handling on RO memslots [+ + +]
Author: Marc Zyngier <maz@kernel.org>
Date:   Tue Dec 20 14:03:52 2022 +0000

    KVM: arm64: Fix S1PTW handling on RO memslots
    
    commit 406504c7b0405d74d74c15a667cd4c4620c3e7a9 upstream.
    
    A recent development on the EFI front has resulted in guests having
    their page tables baked in the firmware binary, and mapped into the
    IPA space as part of a read-only memslot. Not only is this legitimate,
    but it also results in added security, so thumbs up.
    
    It is possible to take an S1PTW translation fault if the S1 PTs are
    unmapped at stage-2. However, KVM unconditionally treats S1PTW as a
    write to correctly handle hardware AF/DB updates to the S1 PTs.
    Furthermore, KVM injects an exception into the guest for S1PTW writes.
    In the aforementioned case this results in the guest taking an abort
    it won't recover from, as the S1 PTs mapping the vectors suffer from
    the same problem.
    
    So clearly our handling is... wrong.
    
    Instead, switch to a two-pronged approach:
    
    - On S1PTW translation fault, handle the fault as a read
    
    - On S1PTW permission fault, handle the fault as a write
    
    This is of no consequence to SW that *writes* to its PTs (the write
    will trigger a non-S1PTW fault), and SW that uses RO PTs will not
    use HW-assisted AF/DB anyway, as that'd be wrong.
    
    Only in the case described in c4ad98e4b72c ("KVM: arm64: Assume write
    fault on S1PTW permission fault on instruction fetch") do we end-up
    with two back-to-back faults (page being evicted and faulted back).
    I don't think this is a case worth optimising for.
    
    Fixes: c4ad98e4b72c ("KVM: arm64: Assume write fault on S1PTW permission fault on instruction fetch")
    Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Regression-tested-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1 [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Dec 13 06:23:03 2022 +0000

    KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1
    
    [ Upstream commit 31de69f4eea77b28a9724b3fa55aae104fc91fc7 ]
    
    Set ENABLE_USR_WAIT_PAUSE in KVM's supported VMX MSR configuration if the
    feature is supported in hardware and enabled in KVM's base, non-nested
    configuration, i.e. expose ENABLE_USR_WAIT_PAUSE to L1 if it's supported.
    This fixes a bug where saving/restoring, i.e. migrating, a vCPU will fail
    if WAITPKG (the associated CPUID feature) is enabled for the vCPU, and
    obviously allows L1 to enable the feature for L2.
    
    KVM already effectively exposes ENABLE_USR_WAIT_PAUSE to L1 by stuffing
    the allowed-1 control ina vCPU's virtual MSR_IA32_VMX_PROCBASED_CTLS2 when
    updating secondary controls in response to KVM_SET_CPUID(2), but (a) that
    depends on flawed code (KVM shouldn't touch VMX MSRs in response to CPUID
    updates) and (b) runs afoul of vmx_restore_control_msr()'s restriction
    that the guest value must be a strict subset of the supported host value.
    
    Although no past commit explicitly enabled nested support for WAITPKG,
    doing so is safe and functionally correct from an architectural
    perspective as no additional KVM support is needed to virtualize TPAUSE,
    UMONITOR, and UMWAIT for L2 relative to L1, and KVM already forwards
    VM-Exits to L1 as necessary (commit bf653b78f960, "KVM: vmx: Introduce
    handle_unexpected_vmexit and handle WAITPKG vmexit").
    
    Note, KVM always keeps the hosts MSR_IA32_UMWAIT_CONTROL resident in
    hardware, i.e. always runs both L1 and L2 with the host's power management
    settings for TPAUSE and UMWAIT.  See commit bf09fb6cba4f ("KVM: VMX: Stop
    context switching MSR_IA32_UMWAIT_CONTROL") for more details.
    
    Fixes: e69e72faa3a0 ("KVM: x86: Add support for user wait instructions")
    Cc: stable@vger.kernel.org
    Reported-by: Aaron Lewis <aaronlewis@google.com>
    Reported-by: Yu Zhang <yu.c.zhang@linux.intel.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Reviewed-by: Jim Mattson <jmattson@google.com>
    Message-Id: <20221213062306.667649-2-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers [+ + +]
Author: Andrea Arcangeli <aarcange@redhat.com>
Date:   Mon Nov 4 17:59:59 2019 -0500

    KVM: retpolines: x86: eliminate retpoline from vmx.c exit handlers
    
    [ Upstream commit 4289d2728664fc1fb49cfc76a6a7d96d913b921f ]
    
    It's enough to check the exit value and issue a direct call to avoid
    the retpoline for all the common vmexit reasons.
    
    Of course CONFIG_RETPOLINE already forbids gcc to use indirect jumps
    while compiling all switch() statements, however switch() would still
    allow the compiler to bisect the case value. It's more efficient to
    prioritize the most frequent vmexits instead.
    
    The halt may be slow paths from the point of the guest, but not
    necessarily so from the point of the host if the host runs at full CPU
    capacity and no host CPU is ever left idle.
    
    Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Stable-dep-of: 31de69f4eea7 ("KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: VMX: Fix the spelling of CPU_BASED_USE_TSC_OFFSETTING [+ + +]
Author: Xiaoyao Li <xiaoyao.li@intel.com>
Date:   Fri Dec 6 16:45:26 2019 +0800

    KVM: VMX: Fix the spelling of CPU_BASED_USE_TSC_OFFSETTING
    
    [ Upstream commit 5e3d394fdd9e6b49cd8b28d85adff100a5bddc66 ]
    
    The mis-spelling is found by checkpatch.pl, so fix them.
    
    Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Stable-dep-of: 31de69f4eea7 ("KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: VMX: Rename INTERRUPT_PENDING to INTERRUPT_WINDOW [+ + +]
Author: Xiaoyao Li <xiaoyao.li@intel.com>
Date:   Fri Dec 6 16:45:24 2019 +0800

    KVM: VMX: Rename INTERRUPT_PENDING to INTERRUPT_WINDOW
    
    [ Upstream commit 9dadc2f918df26e64aa04794cdb4d8667c934f47 ]
    
    Rename interrupt-windown exiting related definitions to match the
    latest Intel SDM. No functional changes.
    
    Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Stable-dep-of: 31de69f4eea7 ("KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: VMX: Rename NMI_PENDING to NMI_WINDOW [+ + +]
Author: Xiaoyao Li <xiaoyao.li@intel.com>
Date:   Fri Dec 6 16:45:25 2019 +0800

    KVM: VMX: Rename NMI_PENDING to NMI_WINDOW
    
    [ Upstream commit 4e2a0bc56ad197e5ccfab8395649b681067fe8cb ]
    
    Rename the NMI-window exiting related definitions to match the latest
    Intel SDM. No functional changes.
    
    Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Stable-dep-of: 31de69f4eea7 ("KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: x86: optimize more exit handlers in vmx.c [+ + +]
Author: Andrea Arcangeli <aarcange@redhat.com>
Date:   Mon Nov 4 17:59:58 2019 -0500

    KVM: x86: optimize more exit handlers in vmx.c
    
    [ Upstream commit f399e60c45f6b6e6ad6dfcedff1dd6386e086b0b ]
    
    Eliminate wasteful call/ret non RETPOLINE case and unnecessary fentry
    dynamic tracing hooking points.
    
    Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Stable-dep-of: 31de69f4eea7 ("KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
lib/fonts: fix undefined behavior in bit shift for get_default_font [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Mon Oct 31 19:38:29 2022 +0800

    lib/fonts: fix undefined behavior in bit shift for get_default_font
    
    [ Upstream commit 6fe888c4d2fb174408e4540bb2d5602b9f507f90 ]
    
    Shifting signed 32-bit value by 31 bits is undefined, so changing
    significant bit to unsigned.  The UBSAN warning calltrace like below:
    
    UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20
    left shift of 1 by 31 places cannot be represented in type 'int'
     <TASK>
     dump_stack_lvl+0x7d/0xa5
     dump_stack+0x15/0x1b
     ubsan_epilogue+0xe/0x4e
     __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
     get_default_font+0x1c7/0x1f0
     fbcon_startup+0x347/0x3a0
     do_take_over_console+0xce/0x270
     do_fbcon_takeover+0xa1/0x170
     do_fb_registered+0x2a8/0x340
     fbcon_fb_registered+0x47/0xe0
     register_framebuffer+0x294/0x4a0
     __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper]
     drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper]
     drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper]
     drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper]
     bochs_pci_probe+0x6ca/0x772 [bochs]
     local_pci_probe+0x4d/0xb0
     pci_device_probe+0x119/0x320
     really_probe+0x181/0x550
     __driver_probe_device+0xc6/0x220
     driver_probe_device+0x32/0x100
     __driver_attach+0x195/0x200
     bus_for_each_dev+0xbb/0x120
     driver_attach+0x27/0x30
     bus_add_driver+0x22e/0x2f0
     driver_register+0xa9/0x190
     __pci_register_driver+0x90/0xa0
     bochs_pci_driver_init+0x52/0x1000 [bochs]
     do_one_initcall+0x76/0x430
     do_init_module+0x61/0x28a
     load_module+0x1f82/0x2e50
     __do_sys_finit_module+0xf8/0x190
     __x64_sys_finit_module+0x23/0x30
     do_syscall_64+0x58/0x80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
     </TASK>
    
    Link: https://lkml.kernel.org/r/20221031113829.4183153-1-cuigaosheng1@huawei.com
    Fixes: c81f717cb9e0 ("fbcon: Fix typo and bogus logic in get_default_font")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
lib/notifier-error-inject: fix error when writing -errno to debugfs file [+ + +]
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Tue Sep 20 02:24:17 2022 +0900

    lib/notifier-error-inject: fix error when writing -errno to debugfs file
    
    [ Upstream commit f883c3edd2c432a2931ec8773c70a570115a50fe ]
    
    The simple attribute files do not accept a negative value since the commit
    488dac0c9237 ("libfs: fix error cast of negative value in
    simple_attr_write()").
    
    This restores the previous behaviour by using newly introduced
    DEFINE_SIMPLE_ATTRIBUTE_SIGNED instead of DEFINE_SIMPLE_ATTRIBUTE.
    
    Link: https://lkml.kernel.org/r/20220919172418.45257-3-akinobu.mita@gmail.com
    Fixes: 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()")
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Reported-by: Zhao Gongyi <zhaogongyi@huawei.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Rafael J. Wysocki <rafael@kernel.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Wei Yongjun <weiyongjun1@huawei.com>
    Cc: Yicong Yang <yangyicong@hisilicon.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
libfs: add DEFINE_SIMPLE_ATTRIBUTE_SIGNED for signed value [+ + +]
Author: Akinobu Mita <akinobu.mita@gmail.com>
Date:   Tue Sep 20 02:24:16 2022 +0900

    libfs: add DEFINE_SIMPLE_ATTRIBUTE_SIGNED for signed value
    
    [ Upstream commit 2e41f274f9aa71cdcc69dc1f26a3f9304a651804 ]
    
    Patch series "fix error when writing negative value to simple attribute
    files".
    
    The simple attribute files do not accept a negative value since the commit
    488dac0c9237 ("libfs: fix error cast of negative value in
    simple_attr_write()"), but some attribute files want to accept a negative
    value.
    
    This patch (of 3):
    
    The simple attribute files do not accept a negative value since the commit
    488dac0c9237 ("libfs: fix error cast of negative value in
    simple_attr_write()"), so we have to use a 64-bit value to write a
    negative value.
    
    This adds DEFINE_SIMPLE_ATTRIBUTE_SIGNED for a signed value.
    
    Link: https://lkml.kernel.org/r/20220919172418.45257-1-akinobu.mita@gmail.com
    Link: https://lkml.kernel.org/r/20220919172418.45257-2-akinobu.mita@gmail.com
    Fixes: 488dac0c9237 ("libfs: fix error cast of negative value in simple_attr_write()")
    Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
    Reported-by: Zhao Gongyi <zhaogongyi@huawei.com>
    Reviewed-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: Rafael J. Wysocki <rafael@kernel.org>
    Cc: Shuah Khan <shuah@kernel.org>
    Cc: Wei Yongjun <weiyongjun1@huawei.com>
    Cc: Yicong Yang <yangyicong@hisilicon.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.4.229 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Jan 18 11:42:07 2023 +0100

    Linux 5.4.229
    
    Link: https://lore.kernel.org/r/20230116154909.645460653@linuxfoundation.org
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Link: https://lore.kernel.org/r/20230117124648.308618956@linuxfoundation.org
    Tested-by: Florian Fainelli <f.fainelli@gmail.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
macintosh/macio-adb: check the return value of ioremap() [+ + +]
Author: Xie Shaowen <studentxswpy@163.com>
Date:   Tue Aug 2 15:41:48 2022 +0800

    macintosh/macio-adb: check the return value of ioremap()
    
    [ Upstream commit dbaa3105736d4d73063ea0a3b01cd7fafce924e6 ]
    
    The function ioremap() in macio_init() can fail, so its return value
    should be checked.
    
    Fixes: 36874579dbf4c ("[PATCH] powerpc: macio-adb build fix")
    Reported-by: Hacash Robot <hacashRobot@santino.com>
    Signed-off-by: Xie Shaowen <studentxswpy@163.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20220802074148.3213659-1-studentxswpy@163.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
macintosh: fix possible memory leak in macio_add_one_device() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Nov 4 11:25:51 2022 +0800

    macintosh: fix possible memory leak in macio_add_one_device()
    
    [ Upstream commit 5ca86eae55a2f006e6c1edd2029b2cacb6979515 ]
    
    Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
    bus_id string array"), the name of device is allocated dynamically. It
    needs to be freed when of_device_register() fails. Call put_device() to
    give up the reference that's taken in device_initialize(), so that it
    can be freed in kobject_cleanup() when the refcount hits 0.
    
    macio device is freed in macio_release_dev(), so the kfree() can be
    removed.
    
    Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221104032551.1075335-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mailbox: zynq-ipi: fix error handling while device_register() fails [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Nov 10 23:08:22 2022 +0800

    mailbox: zynq-ipi: fix error handling while device_register() fails
    
    [ Upstream commit a6792a0cdef0b1c2d77920246283a72537e60e94 ]
    
    If device_register() fails, it has two issues:
    1. The name allocated by dev_set_name() is leaked.
    2. The parent of device is not NULL, device_unregister() is called
       in zynqmp_ipi_free_mboxes(), it will lead a kernel crash because
       of removing not added device.
    
    Call put_device() to give up the reference, so the name is freed in
    kobject_cleanup(). Add device registered check in zynqmp_ipi_free_mboxes()
    to avoid null-ptr-deref.
    
    Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mbcache: add functions to delete entry if unused [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:21 2022 +0200

    mbcache: add functions to delete entry if unused
    
    [ Upstream commit 3dc96bba65f53daa217f0a8f43edad145286a8f5 ]
    
    Add function mb_cache_entry_delete_or_get() to delete mbcache entry if
    it is unused and also add a function to wait for entry to become unused
    - mb_cache_entry_wait_unused(). We do not share code between the two
    deleting function as one of them will go away soon.
    
    CC: stable@vger.kernel.org
    Fixes: 82939d7999df ("ext4: convert to mbcache2")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-2-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: a44e84a9b776 ("ext4: fix deadlock due to mbcache entry corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mbcache: automatically delete entries from cache on freeing [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:29 2022 +0200

    mbcache: automatically delete entries from cache on freeing
    
    [ Upstream commit 307af6c879377c1c63e71cbdd978201f9c7ee8df ]
    
    Use the fact that entries with elevated refcount are not removed from
    the hash and just move removal of the entry from the hash to the entry
    freeing time. When doing this we also change the generic code to hold
    one reference to the cache entry, not two of them, which makes code
    somewhat more obvious.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-10-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: a44e84a9b776 ("ext4: fix deadlock due to mbcache entry corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mbcache: Avoid nesting of cache->c_list_lock under bit locks [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Thu Sep 8 11:10:32 2022 +0200

    mbcache: Avoid nesting of cache->c_list_lock under bit locks
    
    commit 5fc4cbd9fde5d4630494fd6ffc884148fb618087 upstream.
    
    Commit 307af6c87937 ("mbcache: automatically delete entries from cache
    on freeing") started nesting cache->c_list_lock under the bit locks
    protecting hash buckets of the mbcache hash table in
    mb_cache_entry_create(). This causes problems for real-time kernels
    because there spinlocks are sleeping locks while bitlocks stay atomic.
    Luckily the nesting is easy to avoid by holding entry reference until
    the entry is added to the LRU list. This makes sure we cannot race with
    entry deletion.
    
    Cc: stable@kernel.org
    Fixes: 307af6c87937 ("mbcache: automatically delete entries from cache on freeing")
    Reported-by: Mike Galbraith <efault@gmx.de>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220908091032.10513-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mbcache: don't reclaim used entries [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Tue Jul 12 12:54:20 2022 +0200

    mbcache: don't reclaim used entries
    
    [ Upstream commit 58318914186c157477b978b1739dfe2f1b9dc0fe ]
    
    Do not reclaim entries that are currently used by somebody from a
    shrinker. Firstly, these entries are likely useful. Secondly, we will
    need to keep such entries to protect pending increment of xattr block
    refcount.
    
    CC: stable@vger.kernel.org
    Fixes: 82939d7999df ("ext4: convert to mbcache2")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20220712105436.32204-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Stable-dep-of: a44e84a9b776 ("ext4: fix deadlock due to mbcache entry corruption")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mcb: mcb-parse: fix error handing in chameleon_parse_gdd() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Dec 2 01:38:50 2022 -0800

    mcb: mcb-parse: fix error handing in chameleon_parse_gdd()
    
    [ Upstream commit 728ac3389296caf68638628c987aeae6c8851e2d ]
    
    If mcb_device_register() returns error in chameleon_parse_gdd(), the refcount
    of bus and device name are leaked. Fix this by calling put_device() to give up
    the reference, so they can be released in mcb_release_dev() and kobject_cleanup().
    
    Fixes: 3764e82e5150 ("drivers: Introduce MEN Chameleon Bus")
    Reviewed-by: Johannes Thumshirn <jth@kernel.org>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Johannes Thumshirn <jth@kernel.org>
    Link: https://lore.kernel.org/r/ebfb06e39b19272f0197fa9136b5e4b6f34ad732.1669624063.git.johannes.thumshirn@wdc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md/bitmap: Fix bitmap chunk size overflow issues [+ + +]
Author: Florian-Ewald Mueller <florian-ewald.mueller@ionos.com>
Date:   Tue Oct 25 09:37:05 2022 +0200

    md/bitmap: Fix bitmap chunk size overflow issues
    
    commit 4555211190798b6b6fa2c37667d175bf67945c78 upstream.
    
    - limit bitmap chunk size internal u64 variable to values not overflowing
      the u32 bitmap superblock structure variable stored on persistent media
    - assign bitmap chunk size internal u64 variable from unsigned values to
      avoid possible sign extension artifacts when assigning from a s32 value
    
    The bug has been there since at least kernel 4.0.
    Steps to reproduce it:
    1: mdadm -C /dev/mdx -l 1 --bitmap=internal --bitmap-chunk=256M -e 1.2
    -n2 /dev/rnbd1 /dev/rnbd2
    2 resize member device rnbd1 and rnbd2 to 8 TB
    3 mdadm --grow /dev/mdx --size=max
    
    The bitmap_chunksize will overflow without patch.
    
    Cc: stable@vger.kernel.org
    
    Signed-off-by: Florian-Ewald Mueller <florian-ewald.mueller@ionos.com>
    Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
md/raid1: stop mdx_raid1 thread when raid1 array run failed [+ + +]
Author: Jiang Li <jiang.li@ugreen.com>
Date:   Mon Nov 7 22:16:59 2022 +0800

    md/raid1: stop mdx_raid1 thread when raid1 array run failed
    
    [ Upstream commit b611ad14006e5be2170d9e8e611bf49dff288911 ]
    
    fail run raid1 array when we assemble array with the inactive disk only,
    but the mdx_raid1 thread were not stop, Even if the associated resources
    have been released. it will caused a NULL dereference when we do poweroff.
    
    This causes the following Oops:
        [  287.587787] BUG: kernel NULL pointer dereference, address: 0000000000000070
        [  287.594762] #PF: supervisor read access in kernel mode
        [  287.599912] #PF: error_code(0x0000) - not-present page
        [  287.605061] PGD 0 P4D 0
        [  287.607612] Oops: 0000 [#1] SMP NOPTI
        [  287.611287] CPU: 3 PID: 5265 Comm: md0_raid1 Tainted: G     U            5.10.146 #0
        [  287.619029] Hardware name: xxxxxxx/To be filled by O.E.M, BIOS 5.19 06/16/2022
        [  287.626775] RIP: 0010:md_check_recovery+0x57/0x500 [md_mod]
        [  287.632357] Code: fe 01 00 00 48 83 bb 10 03 00 00 00 74 08 48 89 ......
        [  287.651118] RSP: 0018:ffffc90000433d78 EFLAGS: 00010202
        [  287.656347] RAX: 0000000000000000 RBX: ffff888105986800 RCX: 0000000000000000
        [  287.663491] RDX: ffffc90000433bb0 RSI: 00000000ffffefff RDI: ffff888105986800
        [  287.670634] RBP: ffffc90000433da0 R08: 0000000000000000 R09: c0000000ffffefff
        [  287.677771] R10: 0000000000000001 R11: ffffc90000433ba8 R12: ffff888105986800
        [  287.684907] R13: 0000000000000000 R14: fffffffffffffe00 R15: ffff888100b6b500
        [  287.692052] FS:  0000000000000000(0000) GS:ffff888277f80000(0000) knlGS:0000000000000000
        [  287.700149] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        [  287.705897] CR2: 0000000000000070 CR3: 000000000320a000 CR4: 0000000000350ee0
        [  287.713033] Call Trace:
        [  287.715498]  raid1d+0x6c/0xbbb [raid1]
        [  287.719256]  ? __schedule+0x1ff/0x760
        [  287.722930]  ? schedule+0x3b/0xb0
        [  287.726260]  ? schedule_timeout+0x1ed/0x290
        [  287.730456]  ? __switch_to+0x11f/0x400
        [  287.734219]  md_thread+0xe9/0x140 [md_mod]
        [  287.738328]  ? md_thread+0xe9/0x140 [md_mod]
        [  287.742601]  ? wait_woken+0x80/0x80
        [  287.746097]  ? md_register_thread+0xe0/0xe0 [md_mod]
        [  287.751064]  kthread+0x11a/0x140
        [  287.754300]  ? kthread_park+0x90/0x90
        [  287.757974]  ret_from_fork+0x1f/0x30
    
    In fact, when raid1 array run fail, we need to do
    md_unregister_thread() before raid1_free().
    
    Signed-off-by: Jiang Li <jiang.li@ugreen.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
md: fix a crash in mempool_free [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Fri Nov 4 09:53:38 2022 -0400

    md: fix a crash in mempool_free
    
    commit 341097ee53573e06ab9fc675d96a052385b851fa upstream.
    
    There's a crash in mempool_free when running the lvm test
    shell/lvchange-rebuild-raid.sh.
    
    The reason for the crash is this:
    * super_written calls atomic_dec_and_test(&mddev->pending_writes) and
      wake_up(&mddev->sb_wait). Then it calls rdev_dec_pending(rdev, mddev)
      and bio_put(bio).
    * so, the process that waited on sb_wait and that is woken up is racing
      with bio_put(bio).
    * if the process wins the race, it calls bioset_exit before bio_put(bio)
      is executed.
    * bio_put(bio) attempts to free a bio into a destroyed bio set - causing
      a crash in mempool_free.
    
    We fix this bug by moving bio_put before atomic_dec_and_test.
    
    We also move rdev_dec_pending before atomic_dec_and_test as suggested by
    Neil Brown.
    
    The function md_end_flush has a similar bug - we must call bio_put before
    we decrement the number of in-progress bios.
    
     BUG: kernel NULL pointer dereference, address: 0000000000000000
     #PF: supervisor write access in kernel mode
     #PF: error_code(0x0002) - not-present page
     PGD 11557f0067 P4D 11557f0067 PUD 0
     Oops: 0002 [#1] PREEMPT SMP
     CPU: 0 PID: 73 Comm: kworker/0:1 Not tainted 6.1.0-rc3 #5
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
     Workqueue: kdelayd flush_expired_bios [dm_delay]
     RIP: 0010:mempool_free+0x47/0x80
     Code: 48 89 ef 5b 5d ff e0 f3 c3 48 89 f7 e8 32 45 3f 00 48 63 53 08 48 89 c6 3b 53 04 7d 2d 48 8b 43 10 8d 4a 01 48 89 df 89 4b 08 <48> 89 2c d0 e8 b0 45 3f 00 48 8d 7b 30 5b 5d 31 c9 ba 01 00 00 00
     RSP: 0018:ffff88910036bda8 EFLAGS: 00010093
     RAX: 0000000000000000 RBX: ffff8891037b65d8 RCX: 0000000000000001
     RDX: 0000000000000000 RSI: 0000000000000202 RDI: ffff8891037b65d8
     RBP: ffff8891447ba240 R08: 0000000000012908 R09: 00000000003d0900
     R10: 0000000000000000 R11: 0000000000173544 R12: ffff889101a14000
     R13: ffff8891562ac300 R14: ffff889102b41440 R15: ffffe8ffffa00d05
     FS:  0000000000000000(0000) GS:ffff88942fa00000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 0000001102e99000 CR4: 00000000000006b0
     Call Trace:
      <TASK>
      clone_endio+0xf4/0x1c0 [dm_mod]
      clone_endio+0xf4/0x1c0 [dm_mod]
      __submit_bio+0x76/0x120
      submit_bio_noacct_nocheck+0xb6/0x2a0
      flush_expired_bios+0x28/0x2f [dm_delay]
      process_one_work+0x1b4/0x300
      worker_thread+0x45/0x3e0
      ? rescuer_thread+0x380/0x380
      kthread+0xc2/0x100
      ? kthread_complete_and_exit+0x20/0x20
      ret_from_fork+0x1f/0x30
      </TASK>
     Modules linked in: brd dm_delay dm_raid dm_mod af_packet uvesafb cfbfillrect cfbimgblt cn cfbcopyarea fb font fbdev tun autofs4 binfmt_misc configfs ipv6 virtio_rng virtio_balloon rng_core virtio_net pcspkr net_failover failover qemu_fw_cfg button mousedev raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx raid1 raid0 md_mod sd_mod t10_pi crc64_rocksoft crc64 virtio_scsi scsi_mod evdev psmouse bsg scsi_common [last unloaded: brd]
     CR2: 0000000000000000
     ---[ end trace 0000000000000000 ]---
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Song Liu <song@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
media: c8sectpfe: Add of_node_put() when breaking out of loop [+ + +]
Author: Liang He <windhl@126.com>
Date:   Tue Jul 19 22:10:23 2022 +0800

    media: c8sectpfe: Add of_node_put() when breaking out of loop
    
    [ Upstream commit 63ff05a1ad242a5a0f897921c87b70d601bda59c ]
    
    In configure_channels(), we should call of_node_put() when breaking
    out of for_each_child_of_node() which will automatically increase
    and decrease the refcount.
    
    Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")
    Signed-off-by: Liang He <windhl@126.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: camss: Clean up received buffers on failed start of streaming [+ + +]
Author: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Date:   Mon Jul 4 10:44:37 2022 +0100

    media: camss: Clean up received buffers on failed start of streaming
    
    [ Upstream commit c8f3582345e6a69da65ab588f7c4c2d1685b0e80 ]
    
    It is required to return the received buffers, if streaming can not be
    started. For instance media_pipeline_start() may fail with EPIPE, if
    a link validation between entities is not passed, and in such a case
    a user gets a kernel warning:
    
      WARNING: CPU: 1 PID: 520 at drivers/media/common/videobuf2/videobuf2-core.c:1592 vb2_start_streaming+0xec/0x160
      <snip>
      Call trace:
       vb2_start_streaming+0xec/0x160
       vb2_core_streamon+0x9c/0x1a0
       vb2_ioctl_streamon+0x68/0xbc
       v4l_streamon+0x30/0x3c
       __video_do_ioctl+0x184/0x3e0
       video_usercopy+0x37c/0x7b0
       video_ioctl2+0x24/0x40
       v4l2_ioctl+0x4c/0x70
    
    The fix is to correct the error path in video_start_streaming() of camss.
    
    Fixes: 0ac2586c410f ("media: camss: Add files which handle the video device nodes")
    Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
    Reviewed-by: Robert Foss <robert.foss@linaro.org>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: coda: Add check for dcoda_iram_alloc [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Thu Nov 17 14:56:52 2022 +0800

    media: coda: Add check for dcoda_iram_alloc
    
    [ Upstream commit 6b8082238fb8bb20f67e46388123e67a5bbc558d ]
    
    As the coda_iram_alloc may return NULL pointer,
    it should be better to check the return value
    in order to avoid NULL poineter dereference,
    same as the others.
    
    Fixes: b313bcc9a467 ("[media] coda: simplify IRAM setup")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: coda: Add check for kmalloc [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Thu Nov 17 15:02:36 2022 +0800

    media: coda: Add check for kmalloc
    
    [ Upstream commit 6e5e5defdb8b0186312c2f855ace175aee6daf9b ]
    
    As the kmalloc may return NULL pointer,
    it should be better to check the return value
    in order to avoid NULL poineter dereference,
    same as the others.
    
    Fixes: cb1d3a336371 ("[media] coda: add CODA7541 JPEG support")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb-core: Fix double free in dvb_register_device() [+ + +]
Author: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
Date:   Tue Apr 26 06:29:19 2022 +0100

    media: dvb-core: Fix double free in dvb_register_device()
    
    commit 6b0d0477fce747d4137aa65856318b55fba72198 upstream.
    
    In function dvb_register_device() -> dvb_register_media_device() ->
    dvb_create_media_entity(), dvb->entity is allocated and initialized. If
    the initialization fails, it frees the dvb->entity, and return an error
    code. The caller takes the error code and handles the error by calling
    dvb_media_device_free(), which unregisters the entity and frees the
    field again if it is not NULL. As dvb->entity may not NULLed in
    dvb_create_media_entity() when the allocation of dvbdev->pad fails, a
    double free may occur. This may also cause an Use After free in
    media_device_unregister_entity().
    
    Fix this by storing NULL to dvb->entity when it is freed.
    
    Link: https://lore.kernel.org/linux-media/20220426052921.2088416-1-keitasuzuki.park@sslab.ics.keio.ac.jp
    Fixes: fcd5ce4b3936 ("media: dvb-core: fix a memory leak bug")
    Cc: stable@vger.kernel.org
    Cc: Wenwen Wang <wenwen@cs.uga.edu>
    Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: dvb-core: Fix ignored return value in dvb_register_frontend() [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Tue Nov 8 03:30:05 2022 +0000

    media: dvb-core: Fix ignored return value in dvb_register_frontend()
    
    [ Upstream commit a574359e2e71ce16be212df3a082ed60a4bd2c5f ]
    
    In dvb_register_frontend(), dvb_register_device() is possible to fail
    but its return value is ignored.
    
    It will cause use-after-free when module is removed, because in
    dvb_unregister_frontend() it tries to unregister a not registered
    device.
    
    BUG: KASAN: use-after-free in dvb_remove_device+0x18b/0x1f0 [dvb_core]
    Read of size 4 at addr ffff88800dff4824 by task rmmod/428
    CPU: 3 PID: 428 Comm: rmmod
    Call Trace:
     <TASK>
     ...
     dvb_remove_device+0x18b/0x1f0 [dvb_core]
     dvb_unregister_frontend+0x7b/0x130 [dvb_core]
     vidtv_bridge_remove+0x6e/0x160 [dvb_vidtv_bridge]
     ...
    
    Fix this by catching return value of dvb_register_device().
    However the fe->refcount can't be put to zero immediately, because
    there are still modules calling dvb_frontend_detach() when
    dvb_register_frontend() fails.
    
    Link: https://lore.kernel.org/linux-media/20221108033005.169095-1-chenzhongjin@huawei.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb-core: Fix UAF due to refcount races at releasing [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Oct 31 11:02:45 2022 +0100

    media: dvb-core: Fix UAF due to refcount races at releasing
    
    commit fd3d91ab1c6ab0628fe642dd570b56302c30a792 upstream.
    
    The dvb-core tries to sync the releases of opened files at
    dvb_dmxdev_release() with two refcounts: dvbdev->users and
    dvr_dvbdev->users.  A problem is present in those two syncs: when yet
    another dvb_demux_open() is called during those sync waits,
    dvb_demux_open() continues to process even if the device is being
    closed.  This includes the increment of the former refcount, resulting
    in the leftover refcount after the sync of the latter refcount at
    dvb_dmxdev_release().  It ends up with use-after-free, since the
    function believes that all usages were gone and releases the
    resources.
    
    This patch addresses the problem by adding the check of dmxdev->exit
    flag at dvb_demux_open(), just like dvb_dvr_open() already does.  With
    the exit flag check, the second call of dvb_demux_open() fails, hence
    the further corruption can be avoided.
    
    Also for avoiding the races of the dmxdev->exit flag reference, this
    patch serializes the dmxdev->exit set up and the sync waits with the
    dmxdev->mutex lock at dvb_dmxdev_release().  Without the mutex lock,
    dvb_demux_open() (or dvb_dvr_open()) may run concurrently with
    dvb_dmxdev_release(), which allows to skip the exit flag check and
    continue the open process that is being closed.
    
    CVE-2022-41218 is assigned to those bugs above.
    
    Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/20220908132754.30532-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: dvb-frontends: fix leak of memory fw [+ + +]
Author: Yan Lei <yan_lei@dahuatech.com>
Date:   Sun Apr 10 07:19:25 2022 +0100

    media: dvb-frontends: fix leak of memory fw
    
    [ Upstream commit a15fe8d9f1bf460a804bcf18a890bfd2cf0d5caa ]
    
    Link: https://lore.kernel.org/linux-media/20220410061925.4107-1-chinayanlei2002@163.com
    Signed-off-by: Yan Lei <yan_lei@dahuatech.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer() [+ + +]
Author: Baisong Zhong <zhongbaisong@huawei.com>
Date:   Sun Nov 20 06:59:18 2022 +0000

    media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()
    
    [ Upstream commit 0ed554fd769a19ea8464bb83e9ac201002ef74ad ]
    
    Wei Chen reports a kernel bug as blew:
    
    general protection fault, probably for non-canonical address
    KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
    ...
    Call Trace:
    <TASK>
    __i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109
    i2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170
    i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297
    i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458
    vfs_ioctl fs/ioctl.c:51 [inline]
    __do_sys_ioctl fs/ioctl.c:870 [inline]
    __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856
    do_syscall_x64 arch/x86/entry/common.c:50 [inline]
    do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
    entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7fd834a8bded
    
    In az6027_i2c_xfer(), if msg[i].addr is 0x99,
    a null-ptr-deref will caused when accessing msg[i].buf.
    For msg[i].len is 0 and msg[i].buf is null.
    
    Fix this by checking msg[i].len in az6027_i2c_xfer().
    
    Link: https://lore.kernel.org/lkml/CAO4mrfcPHB5aQJO=mpqV+p8mPLNg-Fok0gw8gZ=zemAfMGTzMg@mail.gmail.com/
    
    Link: https://lore.kernel.org/linux-media/20221120065918.2160782-1-zhongbaisong@huawei.com
    Fixes: 76f9a820c867 ("V4L/DVB: AZ6027: Initial import of the driver")
    Reported-by: Wei Chen <harperchen1110@gmail.com>
    Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvb-usb: fix memory leak in dvb_usb_adapter_init() [+ + +]
Author: Mazin Al Haddad <mazinalhaddad05@gmail.com>
Date:   Wed Aug 24 02:21:52 2022 +0100

    media: dvb-usb: fix memory leak in dvb_usb_adapter_init()
    
    [ Upstream commit 94d90fb06b94a90c176270d38861bcba34ce377d ]
    
    Syzbot reports a memory leak in "dvb_usb_adapter_init()".
    The leak is due to not accounting for and freeing current iteration's
    adapter->priv in case of an error. Currently if an error occurs,
    it will exit before incrementing "num_adapters_initalized",
    which is used as a reference counter to free all adap->priv
    in "dvb_usb_adapter_exit()". There are multiple error paths that
    can exit from before incrementing the counter. Including the
    error handling paths for "dvb_usb_adapter_stream_init()",
    "dvb_usb_adapter_dvb_init()" and "dvb_usb_adapter_frontend_init()"
    within "dvb_usb_adapter_init()".
    
    This means that in case of an error in any of these functions the
    current iteration is not accounted for and the current iteration's
    adap->priv is not freed.
    
    Fix this by freeing the current iteration's adap->priv in the
    "stream_init_err:" label in the error path. The rest of the
    (accounted for) adap->priv objects are freed in dvb_usb_adapter_exit()
    as expected using the num_adapters_initalized variable.
    
    Syzbot report:
    
    BUG: memory leak
    unreferenced object 0xffff8881172f1a00 (size 512):
      comm "kworker/0:2", pid 139, jiffies 4294994873 (age 10.960s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    backtrace:
        [<ffffffff844af012>] dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:75 [inline]
        [<ffffffff844af012>] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:184 [inline]
        [<ffffffff844af012>] dvb_usb_device_init.cold+0x4e5/0x79e drivers/media/usb/dvb-usb/dvb-usb-init.c:308
        [<ffffffff830db21d>] dib0700_probe+0x8d/0x1b0 drivers/media/usb/dvb-usb/dib0700_core.c:883
        [<ffffffff82d3fdc7>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
        [<ffffffff8274ab37>] call_driver_probe drivers/base/dd.c:542 [inline]
        [<ffffffff8274ab37>] really_probe.part.0+0xe7/0x310 drivers/base/dd.c:621
        [<ffffffff8274ae6c>] really_probe drivers/base/dd.c:583 [inline]
        [<ffffffff8274ae6c>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:752
        [<ffffffff8274af6a>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:782
        [<ffffffff8274b786>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:899
        [<ffffffff82747c87>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
        [<ffffffff8274b352>] __device_attach+0x122/0x260 drivers/base/dd.c:970
        [<ffffffff827498f6>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
        [<ffffffff82745cdb>] device_add+0x5fb/0xdf0 drivers/base/core.c:3405
        [<ffffffff82d3d202>] usb_set_configuration+0x8f2/0xb80 drivers/usb/core/message.c:2170
        [<ffffffff82d4dbfc>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238
        [<ffffffff82d3f49c>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293
        [<ffffffff8274ab37>] call_driver_probe drivers/base/dd.c:542 [inline]
        [<ffffffff8274ab37>] really_probe.part.0+0xe7/0x310 drivers/base/dd.c:621
        [<ffffffff8274ae6c>] really_probe drivers/base/dd.c:583 [inline]
        [<ffffffff8274ae6c>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:752
    
    Link: https://syzkaller.appspot.com/bug?extid=f66dd31987e6740657be
    Reported-and-tested-by: syzbot+f66dd31987e6740657be@syzkaller.appspotmail.com
    
    Link: https://lore.kernel.org/linux-media/20220824012152.539788-1-mazinalhaddad05@gmail.com
    Signed-off-by: Mazin Al Haddad <mazinalhaddad05@gmail.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvbdev: adopts refcnt to avoid UAF [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Sun Aug 7 15:59:52 2022 +0100

    media: dvbdev: adopts refcnt to avoid UAF
    
    [ Upstream commit 0fc044b2b5e2d05a1fa1fb0d7f270367a7855d79 ]
    
    dvb_unregister_device() is known that prone to use-after-free.
    That is, the cleanup from dvb_unregister_device() releases the dvb_device
    even if there are pointers stored in file->private_data still refer to it.
    
    This patch adds a reference counter into struct dvb_device and delays its
    deallocation until no pointer refers to the object.
    
    Link: https://lore.kernel.org/linux-media/20220807145952.10368-1-linma@zju.edu.cn
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: dvbdev: fix build warning due to comments [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Mon Nov 28 08:39:03 2022 +0000

    media: dvbdev: fix build warning due to comments
    
    commit 3edfd14bb50fa6f94ed1a37bbb17d9f1c2793b57 upstream.
    
    Previous commit that introduces reference counter does not add proper
    comments, which will lead to warning when building htmldocs. Fix them.
    
    Reported-by: "Stephen Rothwell" <sfr@canb.auug.org.au>
    Fixes: 0fc044b2b5e2 ("media: dvbdev: adopts refcnt to avoid UAF")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: dvbdev: fix refcnt bug [+ + +]
Author: Lin Ma <linma@zju.edu.cn>
Date:   Mon Nov 28 16:21:59 2022 +0000

    media: dvbdev: fix refcnt bug
    
    commit 3a664569b71b0a52be5ffb9fb87cc4f83d29bd71 upstream.
    
    Previous commit initialize the dvbdev->ref before the template copy,
    which will overwrite the reference and cause refcnt bug.
    
    refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25
    Modules linked in:
    CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc6-next-20221128-syzkaller #0
    ...
    RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25
    RSP: 0000:ffffc900000678d0 EFLAGS: 00010282
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
    RDX: ffff88813ff58000 RSI: ffffffff81660e7c RDI: fffff5200000cf0c
    RBP: ffff888022a45010 R08: 0000000000000005 R09: 0000000000000000
    R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001
    FS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffff88823ffff000 CR3: 000000000c48e000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     __refcount_add include/linux/refcount.h:199 [inline]
     __refcount_inc include/linux/refcount.h:250 [inline]
     refcount_inc include/linux/refcount.h:267 [inline]
     kref_get include/linux/kref.h:45 [inline]
     dvb_device_get drivers/media/dvb-core/dvbdev.c:585 [inline]
     dvb_register_device+0xe83/0x16e0 drivers/media/dvb-core/dvbdev.c:517
    ...
    
    Just place the kref_init at correct position.
    
    Reported-by: syzbot+fce48a3dd3368645bd6c@syzkaller.appspotmail.com
    Fixes: 0fc044b2b5e2 ("media: dvbdev: adopts refcnt to avoid UAF")
    Signed-off-by: Lin Ma <linma@zju.edu.cn>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: i2c: ad5820: Fix error path [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Wed Sep 21 13:38:00 2022 +0200

    media: i2c: ad5820: Fix error path
    
    [ Upstream commit 9fce241660f37d9e95e93c0ae6fba8cfefa5797b ]
    
    Error path seems to be swaped. Fix the order and provide some meaningful
    names.
    
    Fixes: bee3d5115611 ("[media] ad5820: Add driver for auto-focus coil")
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: imon: fix a race condition in send_packet() [+ + +]
Author: Gautam Menghani <gautammenghani201@gmail.com>
Date:   Wed Oct 19 06:02:14 2022 +0100

    media: imon: fix a race condition in send_packet()
    
    [ Upstream commit 813ceef062b53d68f296aa3cb944b21a091fabdb ]
    
    The function send_packet() has a race condition as follows:
    
    func send_packet()
    {
        // do work
        call usb_submit_urb()
        mutex_unlock()
        wait_for_event_interruptible()  <-- lock gone
        mutex_lock()
    }
    
    func vfd_write()
    {
        mutex_lock()
        call send_packet()  <- prev call is not completed
        mutex_unlock()
    }
    
    When the mutex is unlocked and the function send_packet() waits for the
    call to complete, vfd_write() can start another call, which leads to the
    "URB submitted while active" warning in usb_submit_urb().
    Fix this by removing the mutex_unlock() call in send_packet() and using
    mutex_lock_interruptible().
    
    Link: https://syzkaller.appspot.com/bug?id=e378e6a51fbe6c5cc43e34f131cc9a315ef0337e
    
    Fixes: 21677cfc562a ("V4L/DVB: ir-core: add imon driver")
    Reported-by: syzbot+0c3cb6dc05fbbdc3ad66@syzkaller.appspotmail.com
    Signed-off-by: Gautam Menghani <gautammenghani201@gmail.com>
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: platform: exynos4-is: Fix error handling in fimc_md_init() [+ + +]
Author: Yuan Can <yuancan@huawei.com>
Date:   Fri Nov 11 06:08:53 2022 +0000

    media: platform: exynos4-is: Fix error handling in fimc_md_init()
    
    [ Upstream commit b434422c45282a0573d8123239abc41fa72665d4 ]
    
    A problem about modprobe s5p_fimc failed is triggered with the
    following log given:
    
     [  272.075275] Error: Driver 'exynos4-fimc' is already registered, aborting...
     modprobe: ERROR: could not insert 's5p_fimc': Device or resource busy
    
    The reason is that fimc_md_init() returns platform_driver_register()
    directly without checking its return value, if platform_driver_register()
    failed, it returns without unregister fimc_driver, resulting the
    s5p_fimc can never be installed later.
    A simple call graph is shown as below:
    
     fimc_md_init()
       fimc_register_driver() # register fimc_driver
       platform_driver_register()
         platform_driver_register()
           driver_register()
             bus_add_driver()
               dev = kzalloc(...) # OOM happened
       # return without unregister fimc_driver
    
    Fix by unregister fimc_driver when platform_driver_register() returns
    error.
    
    Fixes: d3953223b090 ("[media] s5p-fimc: Add the media device driver")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: s5p-mfc: Add variant data for MFC v7 hardware for Exynos 3250 SoC [+ + +]
Author: Aakarsh Jain <aakarsh.jain@samsung.com>
Date:   Mon Nov 14 11:50:23 2022 +0000

    media: s5p-mfc: Add variant data for MFC v7 hardware for Exynos 3250 SoC
    
    [ Upstream commit f50ebe10f5d8092c37e2bd430c78e03bf38b1e20 ]
    
    Commit 5441e9dafdfc6dc40 ("[media] s5p-mfc: Core support for MFC v7")
    which adds mfc v7 support for Exynos3250 and use the same compatible
    string as used by Exynos5240 but both the IPs are a bit different in
    terms of IP clock.
    Add variant driver data based on the new compatible string
    "samsung,exynos3250-mfc" for Exynos3250 SoC.
    
    Suggested-by: Alim Akhtar <alim.akhtar@samsung.com>
    Fixes: 5441e9dafdfc ("[media] s5p-mfc: Core support for MFC v7")
    Signed-off-by: Aakarsh Jain <aakarsh.jain@samsung.com>
    Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: s5p-mfc: Clear workbit to handle error condition [+ + +]
Author: Smitha T Murthy <smitha.t@samsung.com>
Date:   Wed Sep 7 16:02:26 2022 +0530

    media: s5p-mfc: Clear workbit to handle error condition
    
    [ Upstream commit d3f3c2fe54e30b0636496d842ffbb5ad3a547f9b ]
    
    During error on CLOSE_INSTANCE command, ctx_work_bits was not getting
    cleared. During consequent mfc execution NULL pointer dereferencing of
    this context led to kernel panic. This patch fixes this issue by making
    sure to clear ctx_work_bits always.
    
    Fixes: 818cd91ab8c6 ("[media] s5p-mfc: Extract open/close MFC instance commands")
    Cc: stable@vger.kernel.org
    Cc: linux-fsd@tesla.com
    Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: s5p-mfc: Fix in register read and write for H264 [+ + +]
Author: Smitha T Murthy <smitha.t@samsung.com>
Date:   Wed Sep 7 16:02:25 2022 +0530

    media: s5p-mfc: Fix in register read and write for H264
    
    [ Upstream commit 06710cd5d2436135046898d7e4b9408c8bb99446 ]
    
    Few of the H264 encoder registers written were not getting reflected
    since the read values were not stored and getting overwritten.
    
    Fixes: 6a9c6f681257 ("[media] s5p-mfc: Add variants to access mfc registers")
    
    Cc: stable@vger.kernel.org
    Cc: linux-fsd@tesla.com
    Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: s5p-mfc: Fix to handle reference queue during finishing [+ + +]
Author: Smitha T Murthy <smitha.t@samsung.com>
Date:   Wed Sep 7 16:02:27 2022 +0530

    media: s5p-mfc: Fix to handle reference queue during finishing
    
    [ Upstream commit d8a46bc4e1e0446459daa77c4ce14218d32dacf9 ]
    
    On receiving last buffer driver puts MFC to MFCINST_FINISHING state which
    in turn skips transferring of frame from SRC to REF queue. This causes
    driver to stop MFC encoding and last frame is lost.
    
    This patch guarantees safe handling of frames during MFCINST_FINISHING and
    correct clearing of workbit to avoid early stopping of encoding.
    
    Fixes: af9357467810 ("[media] MFC: Add MFC 5.1 V4L2 driver")
    
    Cc: stable@vger.kernel.org
    Cc: linux-fsd@tesla.com
    Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: saa7164: fix missing pci_disable_device() [+ + +]
Author: Liu Shixin <liushixin2@huawei.com>
Date:   Sat Nov 26 11:31:26 2022 +0000

    media: saa7164: fix missing pci_disable_device()
    
    [ Upstream commit 57fb35d7542384cac8f198cd1c927540ad38b61a ]
    
    Add missing pci_disable_device() in the error path in saa7164_initdev().
    
    Fixes: 443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon")
    Signed-off-by: Liu Shixin <liushixin2@huawei.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: si470x: Fix use-after-free in si470x_int_in_callback() [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Wed Nov 23 03:51:59 2022 +0900

    media: si470x: Fix use-after-free in si470x_int_in_callback()
    
    [ Upstream commit 7d21e0b1b41b21d628bf2afce777727bd4479aa5 ]
    
    syzbot reported use-after-free in si470x_int_in_callback() [1].  This
    indicates that urb->context, which contains struct si470x_device
    object, is freed when si470x_int_in_callback() is called.
    
    The cause of this issue is that si470x_int_in_callback() is called for
    freed urb.
    
    si470x_usb_driver_probe() calls si470x_start_usb(), which then calls
    usb_submit_urb() and si470x_start().  If si470x_start_usb() fails,
    si470x_usb_driver_probe() doesn't kill urb, but it just frees struct
    si470x_device object, as depicted below:
    
    si470x_usb_driver_probe()
      ...
      si470x_start_usb()
        ...
        usb_submit_urb()
        retval = si470x_start()
        return retval
      if (retval < 0)
        free struct si470x_device object, but don't kill urb
    
    This patch fixes this issue by killing urb when si470x_start_usb()
    fails and urb is submitted.  If si470x_start_usb() fails and urb is
    not submitted, i.e. submitting usb fails, it just frees struct
    si470x_device object.
    
    Reported-by: syzbot+9ca7a12fd736d93e0232@syzkaller.appspotmail.com
    Link: https://syzkaller.appspot.com/bug?id=94ed6dddd5a55e90fd4bab942aa4bb297741d977 [1]
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: solo6x10: fix possible memory leak in solo_sysfs_init() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Nov 10 16:24:23 2022 +0800

    media: solo6x10: fix possible memory leak in solo_sysfs_init()
    
    [ Upstream commit 7f5866dd96d95b74e439f6ee17b8abd8195179fb ]
    
    If device_register() returns error in solo_sysfs_init(), the
    name allocated by dev_set_name() need be freed. As comment of
    device_register() says, it should use put_device() to give up
    the reference in the error path. So fix this by calling
    put_device(), then the name can be freed in kobject_cleanup().
    
    Fixes: dcae5dacbce5 ("[media] solo6x10: sync to latest code from Bluecherry's git repo")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: stv0288: use explicitly signed char [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Mon Oct 24 17:23:43 2022 +0200

    media: stv0288: use explicitly signed char
    
    commit 7392134428c92a4cb541bd5c8f4f5c8d2e88364d upstream.
    
    With char becoming unsigned by default, and with `char` alone being
    ambiguous and based on architecture, signed chars need to be marked
    explicitly as such. Use `s8` and `u8` types here, since that's what
    surrounding code does. This fixes:
    
    drivers/media/dvb-frontends/stv0288.c:471 stv0288_set_frontend() warn: assigning (-9) to unsigned variable 'tm'
    drivers/media/dvb-frontends/stv0288.c:471 stv0288_set_frontend() warn: we never enter this loop
    
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: linux-media@vger.kernel.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

media: videobuf-dma-contig: use dma_mmap_coherent [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed Dec 18 11:39:07 2019 +0100

    media: videobuf-dma-contig: use dma_mmap_coherent
    
    [ Upstream commit b3dc3f8e49577840dc8ac8a365c5b3da4edb10b8 ]
    
    dma_alloc_coherent does not return a physical address, but a DMA address,
    which might be remapped or have an offset.  Passing the DMA address to
    vm_iomap_memory is thus broken.
    
    Use the proper dma_mmap_coherent helper instead, and stop passing
    __GFP_COMP to dma_alloc_coherent, as the memory management inside the
    DMA allocator is hidden from the callers and does not require it.
    
    With this the gfp_t argument to __videobuf_dc_alloc can be removed and
    hard coded to GFP_KERNEL.
    
    Fixes: a8f3c203e19b ("[media] videobuf-dma-contig: add cache support")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: vivid: fix compose size exceed boundary [+ + +]
Author: Liu Shixin <liushixin2@huawei.com>
Date:   Thu Oct 27 20:38:55 2022 +0800

    media: vivid: fix compose size exceed boundary
    
    [ Upstream commit 94a7ad9283464b75b12516c5512541d467cefcf8 ]
    
    syzkaller found a bug:
    
     BUG: unable to handle page fault for address: ffffc9000a3b1000
     #PF: supervisor write access in kernel mode
     #PF: error_code(0x0002) - not-present page
     PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0
     Oops: 0002 [#1] PREEMPT SMP
     CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512
     Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
     RIP: 0010:memcpy_erms+0x6/0x10
    [...]
     Call Trace:
      <TASK>
      ? tpg_fill_plane_buffer+0x856/0x15b0
      vivid_fillbuff+0x8ac/0x1110
      vivid_thread_vid_cap_tick+0x361/0xc90
      vivid_thread_vid_cap+0x21a/0x3a0
      kthread+0x143/0x180
      ret_from_fork+0x1f/0x30
      </TASK>
    
    This is because we forget to check boundary after adjust compose->height
    int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem
    for this case.
    
    Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts")
    Signed-off-by: Liu Shixin <liushixin2@huawei.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
MIPS: BCM63xx: Add check for NULL for clk in clk_enable [+ + +]
Author: Anastasia Belova <abelova@astralinux.ru>
Date:   Fri Dec 9 13:05:50 2022 +0300

    MIPS: BCM63xx: Add check for NULL for clk in clk_enable
    
    [ Upstream commit ee9ef11bd2a59c2fefaa0959e5efcdf040d7c654 ]
    
    Check clk for NULL before calling clk_enable_unlocked where clk
    is dereferenced. There is such check in other implementations
    of clk_enable.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: e7300d04bd08 ("MIPS: BCM63xx: Add support for the Broadcom BCM63xx family of SOCs.")
    Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Acked-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

MIPS: OCTEON: warn only once if deprecated link status is being used [+ + +]
Author: Ladislav Michl <ladis@linux-mips.org>
Date:   Thu Dec 8 12:25:57 2022 +0100

    MIPS: OCTEON: warn only once if deprecated link status is being used
    
    [ Upstream commit 4c587a982603d7e7e751b4925809a1512099a690 ]
    
    Avoid flooding kernel log with warnings.
    
    Fixes: 2c0756d306c2 ("MIPS: OCTEON: warn if deprecated link status is being used")
    Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

MIPS: vpe-cmp: fix possible memory leak while module exiting [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Nov 4 11:39:45 2022 +0800

    MIPS: vpe-cmp: fix possible memory leak while module exiting
    
    [ Upstream commit c5ed1fe0801f0c66b0fbce2785239a5664629057 ]
    
    dev_set_name() allocates memory for name, it need be freed
    when module exiting, call put_device() to give up reference,
    so that it can be freed in kobject_cleanup() when the refcount
    hit to 0. The vpe_device is static, so remove kfree() from
    vpe_device_release().
    
    Fixes: 17a1d523aa58 ("MIPS: APRP: Add VPE loader support for CMP platforms.")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

MIPS: vpe-mt: fix possible memory leak while module exiting [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Nov 4 11:39:44 2022 +0800

    MIPS: vpe-mt: fix possible memory leak while module exiting
    
    [ Upstream commit 5822e8cc84ee37338ab0bdc3124f6eec04dc232d ]
    
    Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
    bus_id string array"), the name of device is allocated dynamically,
    it need be freed when module exiting, call put_device() to give up
    reference, so that it can be freed in kobject_cleanup() when the
    refcount hit to 0. The vpe_device is static, so remove kfree() from
    vpe_device_release().
    
    Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc: ocxl: fix possible name leak in ocxl_file_register_afu() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Nov 11 22:59:29 2022 +0800

    misc: ocxl: fix possible name leak in ocxl_file_register_afu()
    
    [ Upstream commit a4cb1004aeed2ab893a058fad00a5b41a12c4691 ]
    
    If device_register() returns error in ocxl_file_register_afu(),
    the name allocated by dev_set_name() need be freed. As comment
    of device_register() says, it should use put_device() to give
    up the reference in the error path. So fix this by calling
    put_device(), then the name can be freed in kobject_cleanup(),
    and info is freed in info_release().
    
    Fixes: 75ca758adbaf ("ocxl: Create a clear delineation between ocxl backend & frontend")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
    Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
    Link: https://lore.kernel.org/r/20221111145929.2429271-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

misc: sgi-gru: fix use-after-free error in gru_set_context_option, gru_fault and gru_handle_user_call_os [+ + +]
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Thu Nov 10 11:50:33 2022 +0800

    misc: sgi-gru: fix use-after-free error in gru_set_context_option, gru_fault and gru_handle_user_call_os
    
    [ Upstream commit 643a16a0eb1d6ac23744bb6e90a00fc21148a9dc ]
    
    In some bad situation, the gts may be freed gru_check_chiplet_assignment.
    The call chain can be gru_unload_context->gru_free_gru_context->gts_drop
    and kfree finally. However, the caller didn't know if the gts is freed
    or not and use it afterwards. This will trigger a Use after Free bug.
    
    Fix it by introducing a return value to see if it's in error path or not.
    Free the gts in caller if gru_check_chiplet_assignment check failed.
    
    Fixes: 55484c45dbec ("gru: allow users to specify gru chiplet 2")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Acked-by: Dimitri Sivanich <sivanich@hpe.com>
    Link: https://lore.kernel.org/r/20221110035033.19498-1-zyytlz.wz@163.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

misc: tifm: fix possible memory leak in tifm_7xx1_switch_media() [+ + +]
Author: ruanjinjie <ruanjinjie@huawei.com>
Date:   Thu Nov 17 14:47:25 2022 +0800

    misc: tifm: fix possible memory leak in tifm_7xx1_switch_media()
    
    [ Upstream commit fd2c930cf6a5b9176382c15f9acb1996e76e25ad ]
    
    If device_register() returns error in tifm_7xx1_switch_media(),
    name of kobject which is allocated in dev_set_name() called in device_add()
    is leaked.
    
    Never directly free @dev after calling device_register(), even
    if it returned an error! Always use put_device() to give up the
    reference initialized.
    
    Fixes: 2428a8fe2261 ("tifm: move common device management tasks from tifm_7xx1 to tifm_core")
    Signed-off-by: ruanjinjie <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20221117064725.3478402-1-ruanjinjie@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mISDN: hfcmulti: don't call dev_kfree_skb/kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Dec 12 16:41:39 2022 +0800

    mISDN: hfcmulti: don't call dev_kfree_skb/kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 1232946cf522b8de9e398828bde325d7c41f29dd ]
    
    It is not allowed to call kfree_skb() or consume_skb() from hardware
    interrupt context or with hardware interrupts being disabled.
    
    skb_queue_purge() is called under spin_lock_irqsave() in handle_dmsg()
    and hfcm_l1callback(), kfree_skb() is called in them, to fix this, use
    skb_queue_splice_init() to move the dch->squeue to a free queue, also
    enqueue the tx_skb and rx_skb, at last calling __skb_queue_purge() to
    free the SKBs afer unlock.
    
    Fixes: af69fb3a8ffa ("Add mISDN HFC multiport driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mISDN: hfcpci: don't call dev_kfree_skb/kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Dec 12 16:41:38 2022 +0800

    mISDN: hfcpci: don't call dev_kfree_skb/kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit f0f596bd75a9d573ca9b587abb39cee0b916bb82 ]
    
    It is not allowed to call kfree_skb() or consume_skb() from hardware
    interrupt context or with hardware interrupts being disabled.
    
    skb_queue_purge() is called under spin_lock_irqsave() in hfcpci_l2l1D(),
    kfree_skb() is called in it, to fix this, use skb_queue_splice_init()
    to move the dch->squeue to a free queue, also enqueue the tx_skb and
    rx_skb, at last calling __skb_queue_purge() to free the SKBs afer unlock.
    
    Fixes: 1700fe1a10dc ("Add mISDN HFC PCI driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mISDN: hfcsusb: don't call dev_kfree_skb/kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Dec 12 16:41:37 2022 +0800

    mISDN: hfcsusb: don't call dev_kfree_skb/kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit ddc9648db162eee556edd5222d2808fe33730203 ]
    
    It is not allowed to call kfree_skb() or consume_skb() from hardware
    interrupt context or with hardware interrupts being disabled.
    
    It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
    The difference between them is free reason, dev_kfree_skb_irq() means
    the SKB is dropped in error and dev_consume_skb_irq() means the SKB
    is consumed in normal.
    
    skb_queue_purge() is called under spin_lock_irqsave() in hfcusb_l2l1D(),
    kfree_skb() is called in it, to fix this, use skb_queue_splice_init()
    to move the dch->squeue to a free queue, also enqueue the tx_skb and
    rx_skb, at last calling __skb_queue_purge() to free the SKBs afer unlock.
    
    In tx_iso_complete(), dev_kfree_skb() is called to consume the transmitted
    SKB, so replace it with dev_consume_skb_irq().
    
    Fixes: 69f52adb2d53 ("mISDN: Add HFC USB driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm, compaction: fix fast_isolate_around() to stay within boundaries [+ + +]
Author: NARIBAYASHI Akira <a.naribayashi@fujitsu.com>
Date:   Wed Oct 26 20:24:38 2022 +0900

    mm, compaction: fix fast_isolate_around() to stay within boundaries
    
    commit be21b32afe470c5ae98e27e49201158a47032942 upstream.
    
    Depending on the memory configuration, isolate_freepages_block() may scan
    pages out of the target range and causes panic.
    
    Panic can occur on systems with multiple zones in a single pageblock.
    
    The reason it is rare is that it only happens in special
    configurations.  Depending on how many similar systems there are, it
    may be a good idea to fix this problem for older kernels as well.
    
    The problem is that pfn as argument of fast_isolate_around() could be out
    of the target range.  Therefore we should consider the case where pfn <
    start_pfn, and also the case where end_pfn < pfn.
    
    This problem should have been addressd by the commit 6e2b7044c199 ("mm,
    compaction: make fast_isolate_freepages() stay within zone") but there was
    an oversight.
    
     Case1: pfn < start_pfn
    
      <at memory compaction for node Y>
      |  node X's zone  | node Y's zone
      +-----------------+------------------------------...
       pageblock    ^   ^     ^
      +-----------+-----------+-----------+-----------+...
                    ^   ^     ^
                    ^   ^      end_pfn
                    ^    start_pfn = cc->zone->zone_start_pfn
                     pfn
                    <---------> scanned range by "Scan After"
    
     Case2: end_pfn < pfn
    
      <at memory compaction for node X>
      |  node X's zone  | node Y's zone
      +-----------------+------------------------------...
       pageblock  ^     ^   ^
      +-----------+-----------+-----------+-----------+...
                  ^     ^   ^
                  ^     ^    pfn
                  ^      end_pfn
                   start_pfn
                  <---------> scanned range by "Scan Before"
    
    It seems that there is no good reason to skip nr_isolated pages just after
    given pfn.  So let perform simple scan from start to end instead of
    dividing the scan into "Before" and "After".
    
    Link: https://lkml.kernel.org/r/20221026112438.236336-1-a.naribayashi@fujitsu.com
    Fixes: 6e2b7044c199 ("mm, compaction: make fast_isolate_freepages() stay within zone").
    Signed-off-by: NARIBAYASHI Akira <a.naribayashi@fujitsu.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/highmem: Lift memcpy_[to|from]_page to core [+ + +]
Author: Ira Weiny <ira.weiny@intel.com>
Date:   Tue Feb 9 22:22:14 2021 -0800

    mm/highmem: Lift memcpy_[to|from]_page to core
    
    [ Upstream commit bb90d4bc7b6a536b2e4db45f4763e467c2008251 ]
    
    Working through a conversion to a call kmap_local_page() instead of
    kmap() revealed many places where the pattern kmap/memcpy/kunmap
    occurred.
    
    Eric Biggers, Matthew Wilcox, Christoph Hellwig, Dan Williams, and Al
    Viro all suggested putting this code into helper functions.  Al Viro
    further pointed out that these functions already existed in the iov_iter
    code.[1]
    
    Various locations for the lifted functions were considered.
    
    Headers like mm.h or string.h seem ok but don't really portray the
    functionality well.  pagemap.h made some sense but is for page cache
    functionality.[2]
    
    Another alternative would be to create a new header for the promoted
    memcpy functions, but it masks the fact that these are designed to copy
    to/from pages using the kernel direct mappings and complicates matters
    with a new header.
    
    Placing these functions in 'highmem.h' is suboptimal especially with the
    changes being proposed in the functionality of kmap.  From a caller
    perspective including/using 'highmem.h' implies that the functions
    defined in that header are only required when highmem is in use which is
    increasingly not the case with modern processors.  However, highmem.h is
    where all the current functions like this reside (zero_user(),
    clear_highpage(), clear_user_highpage(), copy_user_highpage(), and
    copy_highpage()).  So it makes the most sense even though it is
    distasteful for some.[3]
    
    Lift memcpy_to_page() and memcpy_from_page() to pagemap.h.
    
    [1] https://lore.kernel.org/lkml/20201013200149.GI3576660@ZenIV.linux.org.uk/
        https://lore.kernel.org/lkml/20201013112544.GA5249@infradead.org/
    
    [2] https://lore.kernel.org/lkml/20201208122316.GH7338@casper.infradead.org/
    
    [3] https://lore.kernel.org/lkml/20201013200149.GI3576660@ZenIV.linux.org.uk/#t
        https://lore.kernel.org/lkml/20201208163814.GN1563847@iweiny-DESK2.sc.intel.com/
    
    Cc: Boris Pismenny <borisp@mellanox.com>
    Cc: Or Gerlitz <gerlitz.or@gmail.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Suggested-by: Matthew Wilcox <willy@infradead.org>
    Suggested-by: Christoph Hellwig <hch@infradead.org>
    Suggested-by: Dan Williams <dan.j.williams@intel.com>
    Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
    Suggested-by: Eric Biggers <ebiggers@kernel.org>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Ira Weiny <ira.weiny@intel.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Stable-dep-of: 956510c0c743 ("fs: ext4: initialize fsdata in pagecache_write()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm: Always release pages to the buddy allocator in memblock_free_late(). [+ + +]
Author: Aaron Thompson <dev@aaront.org>
Date:   Fri Jan 6 22:22:44 2023 +0000

    mm: Always release pages to the buddy allocator in memblock_free_late().
    
    commit 115d9d77bb0f9152c60b6e8646369fa7f6167593 upstream.
    
    If CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled, memblock_free_pages()
    only releases pages to the buddy allocator if they are not in the
    deferred range. This is correct for free pages (as defined by
    for_each_free_mem_pfn_range_in_zone()) because free pages in the
    deferred range will be initialized and released as part of the deferred
    init process. memblock_free_pages() is called by memblock_free_late(),
    which is used to free reserved ranges after memblock_free_all() has
    run. All pages in reserved ranges have been initialized at that point,
    and accordingly, those pages are not touched by the deferred init
    process. This means that currently, if the pages that
    memblock_free_late() intends to release are in the deferred range, they
    will never be released to the buddy allocator. They will forever be
    reserved.
    
    In addition, memblock_free_pages() calls kmsan_memblock_free_pages(),
    which is also correct for free pages but is not correct for reserved
    pages. KMSAN metadata for reserved pages is initialized by
    kmsan_init_shadow(), which runs shortly before memblock_free_all().
    
    For both of these reasons, memblock_free_pages() should only be called
    for free pages, and memblock_free_late() should call __free_pages_core()
    directly instead.
    
    One case where this issue can occur in the wild is EFI boot on
    x86_64. The x86 EFI code reserves all EFI boot services memory ranges
    via memblock_reserve() and frees them later via memblock_free_late()
    (efi_reserve_boot_services() and efi_free_boot_services(),
    respectively). If any of those ranges happens to fall within the
    deferred init range, the pages will not be released and that memory will
    be unavailable.
    
    For example, on an Amazon EC2 t3.micro VM (1 GB) booting via EFI:
    
    v6.2-rc2:
      # grep -E 'Node|spanned|present|managed' /proc/zoneinfo
      Node 0, zone      DMA
              spanned  4095
              present  3999
              managed  3840
      Node 0, zone    DMA32
              spanned  246652
              present  245868
              managed  178867
    
    v6.2-rc2 + patch:
      # grep -E 'Node|spanned|present|managed' /proc/zoneinfo
      Node 0, zone      DMA
              spanned  4095
              present  3999
              managed  3840
      Node 0, zone    DMA32
              spanned  246652
              present  245868
              managed  222816   # +43,949 pages
    
    Fixes: 3a80a7fa7989 ("mm: meminit: initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set")
    Signed-off-by: Aaron Thompson <dev@aaront.org>
    Link: https://lore.kernel.org/r/01010185892de53e-e379acfb-7044-4b24-b30a-e2657c1ba989-000000@us-west-2.amazonses.com
    Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mmc: alcor: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 1 14:30:15 2022 +0800

    mmc: alcor: fix return value check of mmc_add_host()
    
    [ Upstream commit e93d1468f429475a753d6baa79b853b7ee5ef8c0 ]
    
    mmc_add_host() may return error, if we ignore its return value, the memory
    that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
    crash because of deleting not added device in the remove path.
    
    So fix this by checking the return value and calling mmc_free_host() in the
    error path.
    
    Fixes: c5413ad815a6 ("mmc: add new Alcor Micro Cardreader SD/MMC driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221101063023.1664968-2-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: atmel-mci: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 8 20:28:19 2022 +0800

    mmc: atmel-mci: fix return value check of mmc_add_host()
    
    [ Upstream commit 9e6e8c43726673ca2abcaac87640b9215fd72f4c ]
    
    mmc_add_host() may return error, if we ignore its return value,
    it will lead two issues:
    1. The memory that allocated in mmc_alloc_host() is leaked.
    2. In the remove() path, mmc_remove_host() will be called to
       delete device, but it's not added yet, it will lead a kernel
       crash because of null-ptr-deref in device_del().
    
    So fix this by checking the return value and calling mmc_free_host()
    in the error path.
    
    Fixes: 7d2be0749a59 ("atmel-mci: Driver for Atmel on-chip MMC controllers")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221108122819.429975-1-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: f-sdh30: Add quirks for broken timeout clock capability [+ + +]
Author: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Date:   Fri Nov 11 17:10:33 2022 +0900

    mmc: f-sdh30: Add quirks for broken timeout clock capability
    
    [ Upstream commit aae9d3a440736691b3c1cb09ae2c32c4f1ee2e67 ]
    
    There is a case where the timeout clock is not supplied to the capability.
    Add a quirk for that.
    
    Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
    Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
    Link: https://lore.kernel.org/r/20221111081033.3813-7-hayashi.kunihiko@socionext.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: meson-gx: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 8 20:34:17 2022 +0800

    mmc: meson-gx: fix return value check of mmc_add_host()
    
    [ Upstream commit 90935f16f2650ab7416fa2ffbe5c28cb39cf3f1e ]
    
    mmc_add_host() may return error, if we ignore its return value,
    it will lead two issues:
    1. The memory that allocated in mmc_alloc_host() is leaked.
    2. In the remove() path, mmc_remove_host() will be called to
       delete device, but it's not added yet, it will lead a kernel
       crash because of null-ptr-deref in device_del().
    
    Fix this by checking the return value and goto error path which
    will call mmc_free_host().
    
    Fixes: 51c5d8447bd7 ("MMC: meson: initial support for GX platforms")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/20221108123417.479045-1-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: mmci: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Nov 9 21:35:39 2022 +0800

    mmc: mmci: fix return value check of mmc_add_host()
    
    [ Upstream commit b38a20f29a49ae04d23750d104b25400b792b98c ]
    
    mmc_add_host() may return error, if we ignore its return value,
    it will lead two issues:
    1. The memory that allocated in mmc_alloc_host() is leaked.
    2. In the remove() path, mmc_remove_host() will be called to
       delete device, but it's not added yet, it will lead a kernel
       crash because of null-ptr-deref in device_del().
    
    So fix this by checking the return value and goto error path which
    will call mmc_free_host().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221109133539.3275664-1-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: moxart: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 1 14:30:16 2022 +0800

    mmc: moxart: fix return value check of mmc_add_host()
    
    [ Upstream commit 0ca18d09c744fb030ae9bc5836c3e357e0237dea ]
    
    mmc_add_host() may return error, if we ignore its return value, the memory
    that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
    crash because of deleting not added device in the remove path.
    
    So fix this by checking the return value and goto error path which will call
    mmc_free_host().
    
    Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221101063023.1664968-3-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: mxcmmc: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 1 14:30:17 2022 +0800

    mmc: mxcmmc: fix return value check of mmc_add_host()
    
    [ Upstream commit cde600af7b413c9fe03e85c58c4279df90e91d13 ]
    
    mmc_add_host() may return error, if we ignore its return value, the memory
    that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
    crash because of deleting not added device in the remove path.
    
    So fix this by checking the return value and goto error path which will call
    mmc_free_host().
    
    Fixes: d96be879ff46 ("mmc: Add a MX2/MX3 specific SDHC driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221101063023.1664968-4-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: omap_hsmmc: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 8 20:13:16 2022 +0800

    mmc: omap_hsmmc: fix return value check of mmc_add_host()
    
    [ Upstream commit a525cad241c339ca00bf7ebf03c5180f2a9b767c ]
    
    mmc_add_host() may return error, if we ignore its return value,
    it will lead two issues:
    1. The memory that allocated in mmc_alloc_host() is leaked.
    2. In the remove() path, mmc_remove_host() will be called to
       delete device, but it's not added yet, it will lead a kernel
       crash because of null-ptr-deref in device_del().
    
    Fix this by checking the return value and goto error path wihch
    will call mmc_free_host().
    
    Fixes: a45c6cb81647 ("[ARM] 5369/1: omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221108121316.340354-1-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: pxamci: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 1 14:30:18 2022 +0800

    mmc: pxamci: fix return value check of mmc_add_host()
    
    [ Upstream commit 80e1ef3afb8bfbe768380b70ffe1b6cab87d1a3b ]
    
    mmc_add_host() may return error, if we ignore its return value, the memory
    that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
    crash because of deleting not added device in the remove path.
    
    So fix this by checking the return value and goto error path which will call
    mmc_free_host(), besides, ->exit() need be called to uninit the pdata.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221101063023.1664968-5-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 1 14:30:20 2022 +0800

    mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host()
    
    [ Upstream commit fc38a5a10e9e5a75eb9189854abeb8405b214cc9 ]
    
    mmc_add_host() may return error, if we ignore its return value, the memory
    that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
    crash because of deleting not added device in the remove path.
    
    So fix this by checking the return value and calling mmc_free_host() in the
    error path, besides, led_classdev_unregister() and pm_runtime_disable() also
    need be called.
    
    Fixes: c7f6558d84af ("mmc: Add realtek USB sdmmc host driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221101063023.1664968-7-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: sdhci-sprd: Disable CLK_AUTO when the clock is less than 400K [+ + +]
Author: Wenchao Chen <wenchao.chen@unisoc.com>
Date:   Wed Dec 7 13:19:09 2022 +0800

    mmc: sdhci-sprd: Disable CLK_AUTO when the clock is less than 400K
    
    commit ff874dbc4f868af128b412a9bd92637103cf11d7 upstream.
    
    When the clock is less than 400K, some SD cards fail to initialize
    because CLK_AUTO is enabled.
    
    Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller")
    Signed-off-by: Wenchao Chen <wenchao.chen@unisoc.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20221207051909.32126-1-wenchao.chen@unisoc.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: toshsd: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 1 14:30:21 2022 +0800

    mmc: toshsd: fix return value check of mmc_add_host()
    
    [ Upstream commit f670744a316ea983113a65313dcd387b5a992444 ]
    
    mmc_add_host() may return error, if we ignore its return value, the memory
    that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
    crash because of deleting not added device in the remove path.
    
    So fix this by checking the return value and goto error path which will call
    mmc_free_host(), besides, free_irq() also needs be called.
    
    Fixes: a5eb8bbd66cc ("mmc: add Toshiba PCI SD controller driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221101063023.1664968-8-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: via-sdmmc: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 8 21:09:49 2022 +0800

    mmc: via-sdmmc: fix return value check of mmc_add_host()
    
    [ Upstream commit e4e46fb61e3bb4628170810d3f2b996b709b90d9 ]
    
    mmc_add_host() may return error, if we ignore its return value,
    it will lead two issues:
    1. The memory that allocated in mmc_alloc_host() is leaked.
    2. In the remove() path, mmc_remove_host() will be called to
       delete device, but it's not added yet, it will lead a kernel
       crash because of null-ptr-deref in device_del().
    
    Fix this by checking the return value and goto error path which
    will call mmc_free_host().
    
    Fixes: f0bf7f61b840 ("mmc: Add new via-sdmmc host controller driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221108130949.1067699-1-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: vub300: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 1 14:30:22 2022 +0800

    mmc: vub300: fix return value check of mmc_add_host()
    
    [ Upstream commit 0613ad2401f88bdeae5594c30afe318e93b14676 ]
    
    mmc_add_host() may return error, if we ignore its return value, the memory
    that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
    crash because of deleting not added device in the remove path.
    
    So fix this by checking the return value and goto error path which will call
    mmc_free_host(), besides, the timer added before mmc_add_host() needs be del.
    
    And this patch fixes another missing call mmc_free_host() if usb_control_msg()
    fails.
    
    Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221101063023.1664968-9-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING [+ + +]
Author: Deren Wu <deren.wu@mediatek.com>
Date:   Sun Dec 4 16:24:16 2022 +0800

    mmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING
    
    commit 4a44cd249604e29e7b90ae796d7692f5773dd348 upstream.
    
    vub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here.
    Ensure that we mark current as TASK_RUNNING for sleepable context.
    
    [   77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff92a72c1d>] sdio_irq_thread+0x17d/0x5b0
    [   77.554652] WARNING: CPU: 2 PID: 1983 at kernel/sched/core.c:9813 __might_sleep+0x116/0x160
    [   77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1 Tainted: G           OE      6.1.0-rc5 #1
    [   77.554910] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020
    [   77.554912] RIP: 0010:__might_sleep+0x116/0x160
    [   77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282
    [   77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000
    [   77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9
    [   77.554928] RBP: ffff888107b7fde0 R08: 0000000000000001 R09: ffffed1043ea60ba
    [   77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60
    [   77.554932] R13: 000000000000011b R14: 7fffffffffffffff R15: ffffffffc0558660
    [   77.554934] FS:  0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000
    [   77.554937] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   77.554939] CR2: 00007f8a44010d68 CR3: 000000024421a003 CR4: 00000000003706e0
    [   77.554942] Call Trace:
    [   77.554944]  <TASK>
    [   77.554952]  mutex_lock+0x78/0xf0
    [   77.554973]  vub300_enable_sdio_irq+0x103/0x3c0 [vub300]
    [   77.554981]  sdio_irq_thread+0x25c/0x5b0
    [   77.555006]  kthread+0x2b8/0x370
    [   77.555017]  ret_from_fork+0x1f/0x30
    [   77.555023]  </TASK>
    [   77.555025] ---[ end trace 0000000000000000 ]---
    
    Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
    Signed-off-by: Deren Wu <deren.wu@mediatek.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/87dc45b122d26d63c80532976813c9365d7160b3.1670140888.git.deren.wu@mediatek.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: wbsd: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Nov 9 21:32:37 2022 +0800

    mmc: wbsd: fix return value check of mmc_add_host()
    
    [ Upstream commit dc5b9b50fc9d1334407e316e6e29a5097ef833bd ]
    
    mmc_add_host() may return error, if we ignore its return value,
    it will lead two issues:
    1. The memory that allocated in mmc_alloc_host() is leaked.
    2. In the remove() path, mmc_remove_host() will be called to
       delete device, but it's not added yet, it will lead a kernel
       crash because of null-ptr-deref in device_del().
    
    So fix this by checking the return value and goto error path which
    will call mmc_free_host(), besides, other resources also need be
    released.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221109133237.3273558-1-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: wmt-sdmmc: fix return value check of mmc_add_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 1 14:30:23 2022 +0800

    mmc: wmt-sdmmc: fix return value check of mmc_add_host()
    
    [ Upstream commit 29276d56f6ed138db0f38cd31aedc0b725c8c76c ]
    
    mmc_add_host() may return error, if we ignore its return value, the memory
    that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
    crash because of deleting not added device in the remove path.
    
    So fix this by checking the return value and goto error path which will call
    mmc_free_host(), besides, clk_disable_unprepare() also needs be called.
    
    Fixes: 3a96dff0f828 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM8650")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221101063023.1664968-10-yangyingliang@huawei.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mrp: introduce active flags to prevent UAF when applicant uninit [+ + +]
Author: Schspa Shi <schspa@gmail.com>
Date:   Wed Nov 16 19:45:11 2022 +0800

    mrp: introduce active flags to prevent UAF when applicant uninit
    
    [ Upstream commit ab0377803dafc58f1e22296708c1c28e309414d6 ]
    
    The caller of del_timer_sync must prevent restarting of the timer, If
    we have no this synchronization, there is a small probability that the
    cancellation will not be successful.
    
    And syzbot report the fellowing crash:
    ==================================================================
    BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline]
    BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605
    Write at addr f9ff000024df6058 by task syz-fuzzer/2256
    Pointer tag: [f9], memory tag: [fe]
    
    CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008-
    ge01d50cbd6ee #0
    Hardware name: linux,dummy-virt (DT)
    Call trace:
     dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156
     dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline]
     show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163
     __dump_stack lib/dump_stack.c:88 [inline]
     dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106
     print_address_description mm/kasan/report.c:284 [inline]
     print_report+0x1a8/0x4a0 mm/kasan/report.c:395
     kasan_report+0x94/0xb4 mm/kasan/report.c:495
     __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320
     do_bad_area arch/arm64/mm/fault.c:473 [inline]
     do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749
     do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825
     el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367
     el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427
     el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576
     hlist_add_head include/linux/list.h:929 [inline]
     enqueue_timer+0x18/0xa4 kernel/time/timer.c:605
     mod_timer+0x14/0x20 kernel/time/timer.c:1161
     mrp_periodic_timer_arm net/802/mrp.c:614 [inline]
     mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627
     call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474
     expire_timers+0x98/0xc4 kernel/time/timer.c:1519
    
    To fix it, we can introduce a new active flags to make sure the timer will
    not restart.
    
    Reported-by: syzbot+6fd64001c20aa99e34a4@syzkaller.appspotmail.com
    
    Signed-off-by: Schspa Shi <schspa@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mtd: Fix device name leak when register device failed in add_mtd_device() [+ + +]
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Sat Oct 22 20:13:52 2022 +0800

    mtd: Fix device name leak when register device failed in add_mtd_device()
    
    [ Upstream commit 895d68a39481a75c680aa421546931fb11942fa6 ]
    
    There is a kmemleak when register device failed:
      unreferenced object 0xffff888101aab550 (size 8):
        comm "insmod", pid 3922, jiffies 4295277753 (age 925.408s)
        hex dump (first 8 bytes):
          6d 74 64 30 00 88 ff ff                          mtd0....
        backtrace:
          [<00000000bde26724>] __kmalloc_node_track_caller+0x4e/0x150
          [<000000003c32b416>] kvasprintf+0xb0/0x130
          [<000000001f7a8f15>] kobject_set_name_vargs+0x2f/0xb0
          [<000000006e781163>] dev_set_name+0xab/0xe0
          [<00000000e30d0c78>] add_mtd_device+0x4bb/0x700
          [<00000000f3d34de7>] mtd_device_parse_register+0x2ac/0x3f0
          [<00000000c0d88488>] 0xffffffffa0238457
          [<00000000b40d0922>] 0xffffffffa02a008f
          [<0000000023d17b9d>] do_one_initcall+0x87/0x2a0
          [<00000000770f6ca6>] do_init_module+0xdf/0x320
          [<000000007b6768fe>] load_module+0x2f98/0x3330
          [<00000000346bed5a>] __do_sys_finit_module+0x113/0x1b0
          [<00000000674c2290>] do_syscall_64+0x35/0x80
          [<000000004c6a8d97>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    If register device failed, should call put_device() to give up the
    reference.
    
    Fixes: 1f24b5a8ecbb ("[MTD] driver model updates")
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20221022121352.2534682-1-zhangxiaoxu5@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: lpddr2_nvm: Fix possible null-ptr-deref [+ + +]
Author: Hui Tang <tanghui20@huawei.com>
Date:   Mon Nov 14 17:02:40 2022 +0800

    mtd: lpddr2_nvm: Fix possible null-ptr-deref
    
    [ Upstream commit 6bdd45d795adf9e73b38ced5e7f750cd199499ff ]
    
    It will cause null-ptr-deref when resource_size(add_range) invoked,
    if platform_get_resource() returns NULL.
    
    Fixes: 96ba9dd65788 ("mtd: lpddr: add driver for LPDDR2-NVM PCM memories")
    Signed-off-by: Hui Tang <tanghui20@huawei.com>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20221114090240.244172-1-tanghui20@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: maps: pxa2xx-flash: fix memory leak in probe [+ + +]
Author: Zheng Yongjun <zhengyongjun3@huawei.com>
Date:   Sat Nov 19 07:33:07 2022 +0000

    mtd: maps: pxa2xx-flash: fix memory leak in probe
    
    [ Upstream commit 2399401feee27c639addc5b7e6ba519d3ca341bf ]
    
    Free 'info' upon remapping error to avoid a memory leak.
    
    Fixes: e644f7d62894 ("[MTD] MAPS: Merge Lubbock and Mainstone drivers into common PXA2xx driver")
    Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
    [<miquel.raynal@bootlin.com>: Reword the commit log]
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20221119073307.22929-1-zhengyongjun3@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mtd: spi-nor: Check for zero erase size in spi_nor_find_best_erase_type() [+ + +]
Author: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Date:   Fri Nov 19 09:14:12 2021 +0100

    mtd: spi-nor: Check for zero erase size in spi_nor_find_best_erase_type()
    
    commit 2ebc336be08160debfe27f87660cf550d710f3e9 upstream.
    
    Erase can be zeroed in spi_nor_parse_4bait() or
    spi_nor_init_non_uniform_erase_map(). In practice it happened with
    mt25qu256a, which supports 4K, 32K, 64K erases with 3b address commands,
    but only 4K and 64K erase with 4b address commands.
    
    Fixes: dc92843159a7 ("mtd: spi-nor: fix erase_type array to indicate current map conf")
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
    Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20211119081412.29732-1-alexander.sverdlin@nokia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
myri10ge: Fix an error handling path in myri10ge_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sun Dec 18 19:08:40 2022 +0100

    myri10ge: Fix an error handling path in myri10ge_probe()
    
    [ Upstream commit d83b950d44d2982c0e62e3d81b0f35ab09431008 ]
    
    Some memory allocated in myri10ge_probe_slices() is not released in the
    error handling path of myri10ge_probe().
    
    Add the corresponding kfree(), as already done in the remove function.
    
    Fixes: 0dcffac1a329 ("myri10ge: add multislices support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net, proc: Provide PROC_FS=n fallback for proc_create_net_single_write() [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Mon Oct 3 07:34:21 2022 +0100

    net, proc: Provide PROC_FS=n fallback for proc_create_net_single_write()
    
    [ Upstream commit c3d96f690a790074b508fe183a41e36a00cd7ddd ]
    
    Provide a CONFIG_PROC_FS=n fallback for proc_create_net_single_write().
    
    Also provide a fallback for proc_create_net_data_write().
    
    Fixes: 564def71765c ("proc: Add a way to make network proc files writable")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    cc: netdev@vger.kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Mon Apr 25 09:45:02 2022 +0800

    net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO
    
    commit dfed913e8b55a0c2c4906f1242fd38fd9a116e49 upstream.
    
    Currently, the kernel drops GSO VLAN tagged packet if it's created with
    socket(AF_PACKET, SOCK_RAW, 0) plus virtio_net_hdr.
    
    The reason is AF_PACKET doesn't adjust the skb network header if there is
    a VLAN tag. Then after virtio_net_hdr_set_proto() called, the skb->protocol
    will be set to ETH_P_IP/IPv6. And in later inet/ipv6_gso_segment() the skb
    is dropped as network header position is invalid.
    
    Let's handle VLAN packets by adjusting network header position in
    packet_parse_headers(). The adjustment is safe and does not affect the
    later xmit as tap device also did that.
    
    In packet_snd(), packet_parse_headers() need to be moved before calling
    virtio_net_hdr_set_proto(), so we can set correct skb->protocol and
    network header first.
    
    There is no need to update tpacket_snd() as it calls packet_parse_headers()
    in tpacket_fill_skb(), which is already before calling virtio_net_hdr_*
    functions.
    
    skb->no_fcs setting is also moved upper to make all skb settings together
    and keep consistency with function packet_sendmsg_spkt().
    
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Link: https://lore.kernel.org/r/20220425014502.985464-1-liuhangbin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net/af_packet: make sure to pull mac header [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Jun 2 09:18:59 2022 -0700

    net/af_packet: make sure to pull mac header
    
    commit e9d3f80935b6607dcdc5682b00b1d4b28e0a0c5d upstream.
    
    GSO assumes skb->head contains link layer headers.
    
    tun device in some case can provide base 14 bytes,
    regardless of VLAN being used or not.
    
    After blamed commit, we can end up setting a network
    header offset of 18+, we better pull the missing
    bytes to avoid a posible crash in GSO.
    
    syzbot report was:
    kernel BUG at include/linux/skbuff.h:2699!
    invalid opcode: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 3601 Comm: syz-executor210 Not tainted 5.18.0-syzkaller-11338-g2c5ca23f7414 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:__skb_pull include/linux/skbuff.h:2699 [inline]
    RIP: 0010:skb_mac_gso_segment+0x48f/0x530 net/core/gro.c:136
    Code: 00 48 c7 c7 00 96 d4 8a c6 05 cb d3 45 06 01 e8 26 bb d0 01 e9 2f fd ff ff 49 c7 c4 ea ff ff ff e9 f1 fe ff ff e8 91 84 19 fa <0f> 0b 48 89 df e8 97 44 66 fa e9 7f fd ff ff e8 ad 44 66 fa e9 48
    RSP: 0018:ffffc90002e2f4b8 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: 0000000000000012 RCX: 0000000000000000
    RDX: ffff88805bb58000 RSI: ffffffff8760ed0f RDI: 0000000000000004
    RBP: 0000000000005dbc R08: 0000000000000004 R09: 0000000000000fe0
    R10: 0000000000000fe4 R11: 0000000000000000 R12: 0000000000000fe0
    R13: ffff88807194d780 R14: 1ffff920005c5e9b R15: 0000000000000012
    FS:  000055555730f300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000200015c0 CR3: 0000000071ff8000 CR4: 0000000000350ee0
    Call Trace:
     <TASK>
     __skb_gso_segment+0x327/0x6e0 net/core/dev.c:3411
     skb_gso_segment include/linux/netdevice.h:4749 [inline]
     validate_xmit_skb+0x6bc/0xf10 net/core/dev.c:3669
     validate_xmit_skb_list+0xbc/0x120 net/core/dev.c:3719
     sch_direct_xmit+0x3d1/0xbe0 net/sched/sch_generic.c:327
     __dev_xmit_skb net/core/dev.c:3815 [inline]
     __dev_queue_xmit+0x14a1/0x3a00 net/core/dev.c:4219
     packet_snd net/packet/af_packet.c:3071 [inline]
     packet_sendmsg+0x21cb/0x5550 net/packet/af_packet.c:3102
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg+0xcf/0x120 net/socket.c:734
     ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492
     ___sys_sendmsg+0xf3/0x170 net/socket.c:2546
     __sys_sendmsg net/socket.c:2575 [inline]
     __do_sys_sendmsg net/socket.c:2584 [inline]
     __se_sys_sendmsg net/socket.c:2582 [inline]
     __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    RIP: 0033:0x7f4b95da06c9
    Code: 28 c3 e8 4a 15 00 00 66 2e 0f 1f 84 00 00 00 00 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 c0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007ffd7defc4c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007ffd7defc4f0 RCX: 00007f4b95da06c9
    RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
    RBP: 0000000000000003 R08: bb1414ac00000050 R09: bb1414ac00000050
    R10: 0000000000000004 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007ffd7defc4e0 R14: 00007ffd7defc4d8 R15: 00007ffd7defc4d4
     </TASK>
    
    Fixes: dfed913e8b55 ("net/af_packet: add VLAN support for AF_PACKET SOCK_RAW GSO")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Acked-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: Willem de Bruijn <willemb@google.com>
    Cc: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/mlx5: Fix ptp max frequency adjustment range [+ + +]
Author: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Date:   Mon Dec 5 14:26:09 2022 -0800

    net/mlx5: Fix ptp max frequency adjustment range
    
    [ Upstream commit fe91d57277eef8bb4aca05acfa337b4a51d0bba4 ]
    
    .max_adj of ptp_clock_info acts as an absolute value for the amount in ppb
    that can be set for a single call of .adjfine. This means that a single
    call to .getfine cannot be greater than .max_adj or less than -(.max_adj).
    Provides correct value for max frequency adjustment value supported by
    devices.
    
    Fixes: 3d8c38af1493 ("net/mlx5e: Add PTP Hardware Clock (PHC) support")
    Signed-off-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
    Reviewed-by: Gal Pressman <gal@nvidia.com>
    Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net/mlx5: Rename ptp clock info [+ + +]
Author: Eran Ben Elisha <eranbe@mellanox.com>
Date:   Tue Jun 9 10:58:31 2020 +0300

    net/mlx5: Rename ptp clock info
    
    [ Upstream commit aac2df7f022eccb5d117f07b1e231410db1a863a ]
    
    Fix a typo in ptp_clock_info naming: mlx5_p2p -> mlx5_ptp.
    
    Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
    Stable-dep-of: fe91d57277ee ("net/mlx5: Fix ptp max frequency adjustment range")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/sched: act_mpls: Fix warning during failed attribute validation [+ + +]
Author: Ido Schimmel <idosch@nvidia.com>
Date:   Sat Jan 7 19:10:04 2023 +0200

    net/sched: act_mpls: Fix warning during failed attribute validation
    
    [ Upstream commit 9e17f99220d111ea031b44153fdfe364b0024ff2 ]
    
    The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a
    validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid
    combination according to the comment above 'struct nla_policy':
    
    "
    Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN:
       NLA_BINARY           Validation function called for the attribute.
       All other            Unused - but note that it's a union
    "
    
    This can trigger the warning [1] in nla_get_range_unsigned() when
    validation of the attribute fails. Despite being of 'NLA_U32' type, the
    associated 'min'/'max' fields in the policy are negative as they are
    aliased by the 'validate' field.
    
    Fix by changing the attribute type to 'NLA_BINARY' which is consistent
    with the above comment and all other users of NLA_POLICY_VALIDATE_FN().
    As a result, move the length validation to the validation function.
    
    No regressions in MPLS tests:
    
     # ./tdc.py -f tc-tests/actions/mpls.json
     [...]
     # echo $?
     0
    
    [1]
    WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118
    nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
    Modules linked in:
    CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
    RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
    [...]
    Call Trace:
     <TASK>
     __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310
     netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411
     netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]
     netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506
     netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546
     rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109
     netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
     netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345
     netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921
     sock_sendmsg_nosec net/socket.c:714 [inline]
     sock_sendmsg net/socket.c:734 [inline]
     ____sys_sendmsg+0x38f/0x500 net/socket.c:2482
     ___sys_sendmsg net/socket.c:2536 [inline]
     __sys_sendmsg+0x197/0x230 net/socket.c:2565
     __do_sys_sendmsg net/socket.c:2574 [inline]
     __se_sys_sendmsg net/socket.c:2572 [inline]
     __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Link: https://lore.kernel.org/netdev/CAO4mrfdmjvRUNbDyP0R03_DrD_eFCLCguz6OxZ2TYRSv0K9gxA@mail.gmail.com/
    Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC")
    Reported-by: Wei Chen <harperchen1110@gmail.com>
    Tested-by: Wei Chen <harperchen1110@gmail.com>
    Signed-off-by: Ido Schimmel <idosch@nvidia.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Link: https://lore.kernel.org/r/20230107171004.608436-1-idosch@nvidia.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/tunnel: wait until all sk_user_data reader finish before releasing the sock [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu Dec 8 20:04:52 2022 +0800

    net/tunnel: wait until all sk_user_data reader finish before releasing the sock
    
    [ Upstream commit 3cf7203ca620682165706f70a1b12b5194607dce ]
    
    There is a race condition in vxlan that when deleting a vxlan device
    during receiving packets, there is a possibility that the sock is
    released after getting vxlan_sock vs from sk_user_data. Then in
    later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got
    NULL pointer dereference. e.g.
    
       #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757
       #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d
       #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48
       #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b
       #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb
       #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542
       #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62
          [exception RIP: vxlan_ecn_decapsulate+0x3b]
          RIP: ffffffffc1014e7b  RSP: ffffa25ec6978cb0  RFLAGS: 00010246
          RAX: 0000000000000008  RBX: ffff8aa000888000  RCX: 0000000000000000
          RDX: 000000000000000e  RSI: ffff8a9fc7ab803e  RDI: ffff8a9fd1168700
          RBP: ffff8a9fc7ab803e   R8: 0000000000700000   R9: 00000000000010ae
          R10: ffff8a9fcb748980  R11: 0000000000000000  R12: ffff8a9fd1168700
          R13: ffff8aa000888000  R14: 00000000002a0000  R15: 00000000000010ae
          ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
       #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan]
       #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507
       #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45
      #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807
      #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951
      #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde
      #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b
      #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139
      #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a
      #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3
      #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca
      #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3
    
    Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh
    
    Fix this by waiting for all sk_user_data reader to finish before
    releasing the sock.
    
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
    Fixes: 6a93cc905274 ("udp-tunnel: Add a few more UDP tunnel APIs")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/ulp: prevent ULP without clone op from entering the LISTEN status [+ + +]
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Tue Jan 3 12:19:17 2023 +0100

    net/ulp: prevent ULP without clone op from entering the LISTEN status
    
    commit 2c02d41d71f90a5168391b6a5f2954112ba2307c upstream.
    
    When an ULP-enabled socket enters the LISTEN status, the listener ULP data
    pointer is copied inside the child/accepted sockets by sk_clone_lock().
    
    The relevant ULP can take care of de-duplicating the context pointer via
    the clone() operation, but only MPTCP and SMC implement such op.
    
    Other ULPs may end-up with a double-free at socket disposal time.
    
    We can't simply clear the ULP data at clone time, as TLS replaces the
    socket ops with custom ones assuming a valid TLS ULP context is
    available.
    
    Instead completely prevent clone-less ULP sockets from entering the
    LISTEN status.
    
    Fixes: 734942cc4ea6 ("tcp: ULP infrastructure")
    Reported-by: slipper <slipper.alive@gmail.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Link: https://lore.kernel.org/r/4b80c3d1dbe3d0ab072f80450c202d9bc88b4b03.1672740602.git.pabeni@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: add atomic_long_t to net_device_stats fields [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Tue Nov 15 08:53:55 2022 +0000

    net: add atomic_long_t to net_device_stats fields
    
    [ Upstream commit 6c1c5097781f563b70a81683ea6fdac21637573b ]
    
    Long standing KCSAN issues are caused by data-race around
    some dev->stats changes.
    
    Most performance critical paths already use per-cpu
    variables, or per-queue ones.
    
    It is reasonable (and more correct) to use atomic operations
    for the slow paths.
    
    This patch adds an union for each field of net_device_stats,
    so that we can convert paths that are not yet protected
    by a spinlock or a mutex.
    
    netdev_stats_to_stats64() no longer has an #if BITS_PER_LONG==64
    
    Note that the memcpy() we were using on 64bit arches
    had no provision to avoid load-tearing,
    while atomic_long_read() is providing the needed protection
    at no cost.
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: amd-xgbe: add missed tasklet_kill [+ + +]
Author: Jiguang Xiao <jiguang.xiao@windriver.com>
Date:   Wed Dec 28 16:14:47 2022 +0800

    net: amd-xgbe: add missed tasklet_kill
    
    [ Upstream commit d530ece70f16f912e1d1bfeea694246ab78b0a4b ]
    
    The driver does not call tasklet_kill in several places.
    Add the calls to fix it.
    
    Fixes: 85b85c853401 ("amd-xgbe: Re-issue interrupt if interrupt status not cleared")
    Signed-off-by: Jiguang Xiao <jiguang.xiao@windriver.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: amd-xgbe: Check only the minimum speed for active/passive cables [+ + +]
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Thu Dec 8 10:22:25 2022 -0600

    net: amd-xgbe: Check only the minimum speed for active/passive cables
    
    [ Upstream commit f8ab263d4d48e6dab752029bf562f20a2ee630ed ]
    
    There are cables that exist that can support speeds in excess of 10GbE.
    The driver, however, restricts the EEPROM advertised nominal bitrate to
    a specific range, which can prevent usage of cables that can support,
    for example, up to 25GbE.
    
    Rather than checking that an active or passive cable supports a specific
    range, only check for a minimum supported speed.
    
    Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: amd-xgbe: Fix logic around active and passive cables [+ + +]
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date:   Thu Dec 8 10:22:24 2022 -0600

    net: amd-xgbe: Fix logic around active and passive cables
    
    [ Upstream commit 4998006c73afe44e2f639d55bd331c6c26eb039f ]
    
    SFP+ active and passive cables are copper cables with fixed SFP+ end
    connectors. Due to a misinterpretation of this, SFP+ active cables could
    end up not being recognized, causing the driver to fail to establish a
    connection.
    
    Introduce a new enum in SFP+ cable types, XGBE_SFP_CABLE_FIBER, that is
    the default cable type, and handle active and passive cables when they are
    specifically detected.
    
    Fixes: abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")
    Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: amd: lance: don't call dev_kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Dec 8 22:21:47 2022 +0800

    net: amd: lance: don't call dev_kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 6151d105dfce8c23edf30eed35e97f3d9b96a35c ]
    
    It is not allowed to call kfree_skb() or consume_skb() from hardware
    interrupt context or with hardware interrupts being disabled.
    
    It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
    The difference between them is free reason, dev_kfree_skb_irq() means
    the SKB is dropped in error and dev_consume_skb_irq() means the SKB
    is consumed in normal.
    
    In these two cases, dev_kfree_skb() is called consume the xmited SKB,
    so replace it with dev_consume_skb_irq().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: apple: bmac: don't call dev_kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Dec 8 21:37:35 2022 +0800

    net: apple: bmac: don't call dev_kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 5fe02e046e6422c4adfdbc50206ec7186077da24 ]
    
    It is not allowed to call kfree_skb() or consume_skb() from hardware
    interrupt context or with hardware interrupts being disabled.
    
    It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
    The difference between them is free reason, dev_kfree_skb_irq() means
    the SKB is dropped in error and dev_consume_skb_irq() means the SKB
    is consumed in normal.
    
    In this case, dev_kfree_skb() is called in bmac_tx_timeout() to drop
    the SKB, when tx timeout, so replace it with dev_kfree_skb_irq().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: apple: mace: don't call dev_kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Dec 8 21:37:34 2022 +0800

    net: apple: mace: don't call dev_kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 3dfe3486c1cd4f82b466b7d307f23777137b8acc ]
    
    It is not allowed to call kfree_skb() or consume_skb() from hardware
    interrupt context or with hardware interrupts being disabled.
    
    It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
    The difference between them is free reason, dev_kfree_skb_irq() means
    the SKB is dropped in error and dev_consume_skb_irq() means the SKB
    is consumed in normal.
    
    In this case, dev_kfree_skb() is called in mace_tx_timeout() to drop
    the SKB, when tx timeout, so replace it with dev_kfree_skb_irq().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: defxx: Fix missing err handling in dfx_init() [+ + +]
Author: Yongqiang Liu <liuyongqiang13@huawei.com>
Date:   Wed Dec 7 07:20:45 2022 +0000

    net: defxx: Fix missing err handling in dfx_init()
    
    [ Upstream commit ae18dcdff0f8d7e84cd3fd9f496518b5e72d185d ]
    
    When eisa_driver_register() or tc_register_driver() failed,
    the modprobe defxx would fail with some err log as follows:
    
     Error: Driver 'defxx' is already registered, aborting...
    
    Fix this issue by adding err hanling in dfx_init().
    
    Fixes: e89a2cfb7d7b5 ("[TC] defxx: TURBOchannel support")
    Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: emaclite: don't call dev_kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Dec 8 22:21:44 2022 +0800

    net: emaclite: don't call dev_kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit d1678bf45f21fa5ae4a456f821858679556ea5f8 ]
    
    It is not allowed to call kfree_skb() or consume_skb() from hardware
    interrupt context or with hardware interrupts being disabled.
    
    It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
    The difference between them is free reason, dev_kfree_skb_irq() means
    the SKB is dropped in error and dev_consume_skb_irq() means the SKB
    is consumed in normal.
    
    In this case, dev_kfree_skb() is called in xemaclite_tx_timeout() to
    drop the SKB, when tx timeout, so replace it with dev_kfree_skb_irq().
    
    Fixes: bb81b2ddfa19 ("net: add Xilinx emac lite device driver")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: dnet: don't call dev_kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Dec 8 22:21:45 2022 +0800

    net: ethernet: dnet: don't call dev_kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit f07fadcbee2a5e84caa67c7c445424200bffb60b ]
    
    It is not allowed to call kfree_skb() or consume_skb() from hardware
    interrupt context or with hardware interrupts being disabled.
    
    In this case, the lock is used to protected 'bp', so we can move
    dev_kfree_skb() after the spin_unlock_irqrestore().
    
    Fixes: 4796417417a6 ("dnet: Dave DNET ethernet controller driver (updated)")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ethernet: ti: Fix return type of netcp_ndo_start_xmit() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Nov 2 09:09:33 2022 -0700

    net: ethernet: ti: Fix return type of netcp_ndo_start_xmit()
    
    [ Upstream commit 63fe6ff674a96cfcfc0fa8df1051a27aa31c70b4 ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed. A
    proposed warning in clang aims to catch these at compile time, which
    reveals:
    
      drivers/net/ethernet/ti/netcp_core.c:1944:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .ndo_start_xmit         = netcp_ndo_start_xmit,
                                        ^~~~~~~~~~~~~~~~~~~~
      1 error generated.
    
    ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
    'netdev_tx_t', not 'int'. Adjust the return type of
    netcp_ndo_start_xmit() to match the prototype's to resolve the warning
    and CFI failure.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1750
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221102160933.1601260-1-nathan@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: farsync: Fix kmemleak when rmmods farsync [+ + +]
Author: Li Zetao <lizetao1@huawei.com>
Date:   Thu Dec 8 20:05:40 2022 +0800

    net: farsync: Fix kmemleak when rmmods farsync
    
    [ Upstream commit 2f623aaf9f31de968dea6169849706a2f9be444c ]
    
    There are two memory leaks reported by kmemleak:
    
      unreferenced object 0xffff888114b20200 (size 128):
        comm "modprobe", pid 4846, jiffies 4295146524 (age 401.345s)
        hex dump (first 32 bytes):
          e0 62 57 09 81 88 ff ff e0 62 57 09 81 88 ff ff  .bW......bW.....
          01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60
          [<ffffffff83d35c78>] __hw_addr_add_ex+0x198/0x6c0
          [<ffffffff83d3989d>] dev_addr_init+0x13d/0x230
          [<ffffffff83d1063d>] alloc_netdev_mqs+0x10d/0xe50
          [<ffffffff82b4a06e>] alloc_hdlcdev+0x2e/0x80
          [<ffffffffa016a741>] fst_add_one+0x601/0x10e0 [farsync]
          ...
    
      unreferenced object 0xffff88810b85b000 (size 1024):
        comm "modprobe", pid 4846, jiffies 4295146523 (age 401.346s)
        hex dump (first 32 bytes):
          00 00 b0 02 00 c9 ff ff 00 70 0a 00 00 c9 ff ff  .........p......
          00 00 00 f2 00 00 00 f3 0a 00 00 00 02 00 00 00  ................
        backtrace:
          [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60
          [<ffffffffa016a294>] fst_add_one+0x154/0x10e0 [farsync]
          [<ffffffff82060e83>] local_pci_probe+0xd3/0x170
          ...
    
    The root cause is traced to the netdev and fst_card_info are not freed
    when removes one fst in fst_remove_one(), which may trigger oom if
    repeated insmod and rmmod module.
    
    Fix it by adding free_netdev() and kfree() in fst_remove_one(), just as
    the operations on the error handling path in fst_add_one().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Li Zetao <lizetao1@huawei.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: hns3: add interrupts re-initialization while doing VF FLR [+ + +]
Author: Jie Wang <wangjie125@huawei.com>
Date:   Thu Dec 22 14:43:41 2022 +0800

    net: hns3: add interrupts re-initialization while doing VF FLR
    
    [ Upstream commit 09e6b30eeb254f1818a008cace3547159e908dfd ]
    
    Currently keep alive message between PF and VF may be lost and the VF is
    unalive in PF. So the VF will not do reset during PF FLR reset process.
    This would make the allocated interrupt resources of VF invalid and VF
    would't receive or respond to PF any more.
    
    So this patch adds VF interrupts re-initialization during VF FLR for VF
    recovery in above cases.
    
    Fixes: 862d969a3a4d ("net: hns3: do VF's pci re-initialization while PF doing FLR")
    Signed-off-by: Jie Wang <wangjie125@huawei.com>
    Signed-off-by: Hao Lan <lanhao@huawei.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: lan9303: Fix read error execution path [+ + +]
Author: Jerry Ray <jerry.ray@microchip.com>
Date:   Fri Dec 9 09:35:02 2022 -0600

    net: lan9303: Fix read error execution path
    
    [ Upstream commit 8964916d206071b058c6351f88b1966bd58cbde0 ]
    
    This patch fixes an issue where a read failure of a port statistic counter
    will return unknown results.  While it is highly unlikely the read will
    ever fail, it is much cleaner to return a zero for the stat count.
    
    Fixes: a1292595e006 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303")
    Signed-off-by: Jerry Ray <jerry.ray@microchip.com>
    Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20221209153502.7429-1-jerry.ray@microchip.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: loopback: use NET_NAME_PREDICTABLE for name_assign_type [+ + +]
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Wed Nov 23 15:18:28 2022 +0100

    net: loopback: use NET_NAME_PREDICTABLE for name_assign_type
    
    [ Upstream commit 31d929de5a112ee1b977a89c57de74710894bbbf ]
    
    When the name_assign_type attribute was introduced (commit
    685343fc3ba6, "net: add name_assign_type netdev attribute"), the
    loopback device was explicitly mentioned as one which would make use
    of NET_NAME_PREDICTABLE:
    
        The name_assign_type attribute gives hints where the interface name of a
        given net-device comes from. These values are currently defined:
    ...
          NET_NAME_PREDICTABLE:
            The ifname has been assigned by the kernel in a predictable way
            that is guaranteed to avoid reuse and always be the same for a
            given device. Examples include statically created devices like
            the loopback device [...]
    
    Switch to that so that reading /sys/class/net/lo/name_assign_type
    produces something sensible instead of returning -EINVAL.
    
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probe [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu Dec 29 10:29:25 2022 +0400

    net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probe
    
    [ Upstream commit d039535850ee47079d59527e96be18d8e0daa84b ]
    
    of_phy_find_device() return device node with refcount incremented.
    Call put_device() to relese it when not needed anymore.
    
    Fixes: ab4e6ee578e8 ("net: phy: xgmiitorgmii: Check phy_driver ready before accessing")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: sched: atm: dont intepret cls results when asked to drop [+ + +]
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Sun Jan 1 16:57:43 2023 -0500

    net: sched: atm: dont intepret cls results when asked to drop
    
    [ Upstream commit a2965c7be0522eaa18808684b7b82b248515511b ]
    
    If asked to drop a packet via TC_ACT_SHOT it is unsafe to assume
    res.class contains a valid pointer
    Fixes: b0188d4dbe5f ("[NET_SCHED]: sch_atm: Lindent")
    
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: sched: cbq: dont intepret cls results when asked to drop [+ + +]
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Sun Jan 1 16:57:44 2023 -0500

    net: sched: cbq: dont intepret cls results when asked to drop
    
    [ Upstream commit caa4b35b4317d5147b3ab0fbdc9c075c7d2e9c12 ]
    
    If asked to drop a packet via TC_ACT_SHOT it is unsafe to assume that
    res.class contains a valid pointer
    
    Sample splat reported by Kyle Zeng
    
    [    5.405624] 0: reclassify loop, rule prio 0, protocol 800
    [    5.406326] ==================================================================
    [    5.407240] BUG: KASAN: slab-out-of-bounds in cbq_enqueue+0x54b/0xea0
    [    5.407987] Read of size 1 at addr ffff88800e3122aa by task poc/299
    [    5.408731]
    [    5.408897] CPU: 0 PID: 299 Comm: poc Not tainted 5.10.155+ #15
    [    5.409516] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS 1.15.0-1 04/01/2014
    [    5.410439] Call Trace:
    [    5.410764]  dump_stack+0x87/0xcd
    [    5.411153]  print_address_description+0x7a/0x6b0
    [    5.411687]  ? vprintk_func+0xb9/0xc0
    [    5.411905]  ? printk+0x76/0x96
    [    5.412110]  ? cbq_enqueue+0x54b/0xea0
    [    5.412323]  kasan_report+0x17d/0x220
    [    5.412591]  ? cbq_enqueue+0x54b/0xea0
    [    5.412803]  __asan_report_load1_noabort+0x10/0x20
    [    5.413119]  cbq_enqueue+0x54b/0xea0
    [    5.413400]  ? __kasan_check_write+0x10/0x20
    [    5.413679]  __dev_queue_xmit+0x9c0/0x1db0
    [    5.413922]  dev_queue_xmit+0xc/0x10
    [    5.414136]  ip_finish_output2+0x8bc/0xcd0
    [    5.414436]  __ip_finish_output+0x472/0x7a0
    [    5.414692]  ip_finish_output+0x5c/0x190
    [    5.414940]  ip_output+0x2d8/0x3c0
    [    5.415150]  ? ip_mc_finish_output+0x320/0x320
    [    5.415429]  __ip_queue_xmit+0x753/0x1760
    [    5.415664]  ip_queue_xmit+0x47/0x60
    [    5.415874]  __tcp_transmit_skb+0x1ef9/0x34c0
    [    5.416129]  tcp_connect+0x1f5e/0x4cb0
    [    5.416347]  tcp_v4_connect+0xc8d/0x18c0
    [    5.416577]  __inet_stream_connect+0x1ae/0xb40
    [    5.416836]  ? local_bh_enable+0x11/0x20
    [    5.417066]  ? lock_sock_nested+0x175/0x1d0
    [    5.417309]  inet_stream_connect+0x5d/0x90
    [    5.417548]  ? __inet_stream_connect+0xb40/0xb40
    [    5.417817]  __sys_connect+0x260/0x2b0
    [    5.418037]  __x64_sys_connect+0x76/0x80
    [    5.418267]  do_syscall_64+0x31/0x50
    [    5.418477]  entry_SYSCALL_64_after_hwframe+0x61/0xc6
    [    5.418770] RIP: 0033:0x473bb7
    [    5.418952] Code: 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00
    00 00 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2a 00 00
    00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 18 89 54 24 0c 48 89 34
    24 89
    [    5.420046] RSP: 002b:00007fffd20eb0f8 EFLAGS: 00000246 ORIG_RAX:
    000000000000002a
    [    5.420472] RAX: ffffffffffffffda RBX: 00007fffd20eb578 RCX: 0000000000473bb7
    [    5.420872] RDX: 0000000000000010 RSI: 00007fffd20eb110 RDI: 0000000000000007
    [    5.421271] RBP: 00007fffd20eb150 R08: 0000000000000001 R09: 0000000000000004
    [    5.421671] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
    [    5.422071] R13: 00007fffd20eb568 R14: 00000000004fc740 R15: 0000000000000002
    [    5.422471]
    [    5.422562] Allocated by task 299:
    [    5.422782]  __kasan_kmalloc+0x12d/0x160
    [    5.423007]  kasan_kmalloc+0x5/0x10
    [    5.423208]  kmem_cache_alloc_trace+0x201/0x2e0
    [    5.423492]  tcf_proto_create+0x65/0x290
    [    5.423721]  tc_new_tfilter+0x137e/0x1830
    [    5.423957]  rtnetlink_rcv_msg+0x730/0x9f0
    [    5.424197]  netlink_rcv_skb+0x166/0x300
    [    5.424428]  rtnetlink_rcv+0x11/0x20
    [    5.424639]  netlink_unicast+0x673/0x860
    [    5.424870]  netlink_sendmsg+0x6af/0x9f0
    [    5.425100]  __sys_sendto+0x58d/0x5a0
    [    5.425315]  __x64_sys_sendto+0xda/0xf0
    [    5.425539]  do_syscall_64+0x31/0x50
    [    5.425764]  entry_SYSCALL_64_after_hwframe+0x61/0xc6
    [    5.426065]
    [    5.426157] The buggy address belongs to the object at ffff88800e312200
    [    5.426157]  which belongs to the cache kmalloc-128 of size 128
    [    5.426955] The buggy address is located 42 bytes to the right of
    [    5.426955]  128-byte region [ffff88800e312200, ffff88800e312280)
    [    5.427688] The buggy address belongs to the page:
    [    5.427992] page:000000009875fabc refcount:1 mapcount:0
    mapping:0000000000000000 index:0x0 pfn:0xe312
    [    5.428562] flags: 0x100000000000200(slab)
    [    5.428812] raw: 0100000000000200 dead000000000100 dead000000000122
    ffff888007843680
    [    5.429325] raw: 0000000000000000 0000000000100010 00000001ffffffff
    ffff88800e312401
    [    5.429875] page dumped because: kasan: bad access detected
    [    5.430214] page->mem_cgroup:ffff88800e312401
    [    5.430471]
    [    5.430564] Memory state around the buggy address:
    [    5.430846]  ffff88800e312180: fc fc fc fc fc fc fc fc fc fc fc fc
    fc fc fc fc
    [    5.431267]  ffff88800e312200: 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 fc
    [    5.431705] >ffff88800e312280: fc fc fc fc fc fc fc fc fc fc fc fc
    fc fc fc fc
    [    5.432123]                                   ^
    [    5.432391]  ffff88800e312300: 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 fc
    [    5.432810]  ffff88800e312380: fc fc fc fc fc fc fc fc fc fc fc fc
    fc fc fc fc
    [    5.433229] ==================================================================
    [    5.433648] Disabling lock debugging due to kernel taint
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: Kyle Zeng <zengyhkyle@gmail.com>
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: sched: disallow noqueue for qdisc classes [+ + +]
Author: Frederick Lawler <fred@cloudflare.com>
Date:   Mon Jan 9 10:39:06 2023 -0600

    net: sched: disallow noqueue for qdisc classes
    
    commit 96398560f26aa07e8f2969d73c8197e6a6d10407 upstream.
    
    While experimenting with applying noqueue to a classful queue discipline,
    we discovered a NULL pointer dereference in the __dev_queue_xmit()
    path that generates a kernel OOPS:
    
        # dev=enp0s5
        # tc qdisc replace dev $dev root handle 1: htb default 1
        # tc class add dev $dev parent 1: classid 1:1 htb rate 10mbit
        # tc qdisc add dev $dev parent 1:1 handle 10: noqueue
        # ping -I $dev -w 1 -c 1 1.1.1.1
    
    [    2.172856] BUG: kernel NULL pointer dereference, address: 0000000000000000
    [    2.173217] #PF: supervisor instruction fetch in kernel mode
    ...
    [    2.178451] Call Trace:
    [    2.178577]  <TASK>
    [    2.178686]  htb_enqueue+0x1c8/0x370
    [    2.178880]  dev_qdisc_enqueue+0x15/0x90
    [    2.179093]  __dev_queue_xmit+0x798/0xd00
    [    2.179305]  ? _raw_write_lock_bh+0xe/0x30
    [    2.179522]  ? __local_bh_enable_ip+0x32/0x70
    [    2.179759]  ? ___neigh_create+0x610/0x840
    [    2.179968]  ? eth_header+0x21/0xc0
    [    2.180144]  ip_finish_output2+0x15e/0x4f0
    [    2.180348]  ? dst_output+0x30/0x30
    [    2.180525]  ip_push_pending_frames+0x9d/0xb0
    [    2.180739]  raw_sendmsg+0x601/0xcb0
    [    2.180916]  ? _raw_spin_trylock+0xe/0x50
    [    2.181112]  ? _raw_spin_unlock_irqrestore+0x16/0x30
    [    2.181354]  ? get_page_from_freelist+0xcd6/0xdf0
    [    2.181594]  ? sock_sendmsg+0x56/0x60
    [    2.181781]  sock_sendmsg+0x56/0x60
    [    2.181958]  __sys_sendto+0xf7/0x160
    [    2.182139]  ? handle_mm_fault+0x6e/0x1d0
    [    2.182366]  ? do_user_addr_fault+0x1e1/0x660
    [    2.182627]  __x64_sys_sendto+0x1b/0x30
    [    2.182881]  do_syscall_64+0x38/0x90
    [    2.183085]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
    ...
    [    2.187402]  </TASK>
    
    Previously in commit d66d6c3152e8 ("net: sched: register noqueue
    qdisc"), NULL was set for the noqueue discipline on noqueue init
    so that __dev_queue_xmit() falls through for the noqueue case. This
    also sets a bypass of the enqueue NULL check in the
    register_qdisc() function for the struct noqueue_disc_ops.
    
    Classful queue disciplines make it past the NULL check in
    __dev_queue_xmit() because the discipline is set to htb (in this case),
    and then in the call to __dev_xmit_skb(), it calls into htb_enqueue()
    which grabs a leaf node for a class and then calls qdisc_enqueue() by
    passing in a queue discipline which assumes ->enqueue() is not set to NULL.
    
    Fix this by not allowing classes to be assigned to the noqueue
    discipline. Linux TC Notes states that classes cannot be set to
    the noqueue discipline. [1] Let's enforce that here.
    
    Links:
    1. https://linux-tc-notes.sourceforge.net/tc/doc/sch_noqueue.txt
    
    Fixes: d66d6c3152e8 ("net: sched: register noqueue qdisc")
    Cc: stable@vger.kernel.org
    Signed-off-by: Frederick Lawler <fred@cloudflare.com>
    Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
    Link: https://lore.kernel.org/r/20230109163906.706000-1-fred@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: sched: fix memory leak in tcindex_set_parms [+ + +]
Author: Hawkins Jiawei <yin31149@gmail.com>
Date:   Thu Dec 22 11:51:19 2022 +0800

    net: sched: fix memory leak in tcindex_set_parms
    
    [ Upstream commit 399ab7fe0fa0d846881685fd4e57e9a8ef7559f7 ]
    
    Syzkaller reports a memory leak as follows:
    ====================================
    BUG: memory leak
    unreferenced object 0xffff88810c287f00 (size 256):
      comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
        [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline]
        [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [inline]
        [<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline]
        [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline]
        [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342
        [<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553
        [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147
        [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082
        [<ffffffff839eba67>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540
        [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
        [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345
        [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921
        [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline]
        [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734
        [<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482
        [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536
        [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622
        [<ffffffff83843c14>] __do_sys_sendmmsg net/socket.c:2651 [inline]
        [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline]
        [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648
        [<ffffffff84605fd5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
        [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
        [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    ====================================
    
    Kernel uses tcindex_change() to change an existing
    filter properties.
    
    Yet the problem is that, during the process of changing,
    if `old_r` is retrieved from `p->perfect`, then
    kernel uses tcindex_alloc_perfect_hash() to newly
    allocate filter results, uses tcindex_filter_result_init()
    to clear the old filter result, without destroying
    its tcf_exts structure, which triggers the above memory leak.
    
    To be more specific, there are only two source for the `old_r`,
    according to the tcindex_lookup(). `old_r` is retrieved from
    `p->perfect`, or `old_r` is retrieved from `p->h`.
    
      * If `old_r` is retrieved from `p->perfect`, kernel uses
    tcindex_alloc_perfect_hash() to newly allocate the
    filter results. Then `r` is assigned with `cp->perfect + handle`,
    which is newly allocated. So condition `old_r && old_r != r` is
    true in this situation, and kernel uses tcindex_filter_result_init()
    to clear the old filter result, without destroying
    its tcf_exts structure
    
      * If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL
    according to the tcindex_lookup(). Considering that `cp->h`
    is directly copied from `p->h` and `p->perfect` is NULL,
    `r` is assigned with `tcindex_lookup(cp, handle)`, whose value
    should be the same as `old_r`, so condition `old_r && old_r != r`
    is false in this situation, kernel ignores using
    tcindex_filter_result_init() to clear the old filter result.
    
    So only when `old_r` is retrieved from `p->perfect` does kernel use
    tcindex_filter_result_init() to clear the old filter result, which
    triggers the above memory leak.
    
    Considering that there already exists a tc_filter_wq workqueue
    to destroy the old tcindex_data by tcindex_partial_destroy_work()
    at the end of tcindex_set_parms(), this patch solves
    this memory leak bug by removing this old filter result
    clearing part and delegating it to the tc_filter_wq workqueue.
    
    Note that this patch doesn't introduce any other issues. If
    `old_r` is retrieved from `p->perfect`, this patch just
    delegates old filter result clearing part to the
    tc_filter_wq workqueue; If `old_r` is retrieved from `p->h`,
    kernel doesn't reach the old filter result clearing part, so
    removing this part has no effect.
    
    [Thanks to the suggestion from Jakub Kicinski, Cong Wang, Paolo Abeni
    and Dmitry Vyukov]
    
    Fixes: b9a24bb76bf6 ("net_sched: properly handle failure case of tcf_exts_init()")
    Link: https://lore.kernel.org/all/0000000000001de5c505ebc9ec59@google.com/
    Reported-by: syzbot+232ebdbd36706c965ebf@syzkaller.appspotmail.com
    Tested-by: syzbot+232ebdbd36706c965ebf@syzkaller.appspotmail.com
    Cc: Cong Wang <cong.wang@bytedance.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: selftests: fix potential memleak in stmmac_test_arpoffload() [+ + +]
Author: Zhang Changzhong <zhangchangzhong@huawei.com>
Date:   Wed Dec 7 16:31:59 2022 +0800

    net: stmmac: selftests: fix potential memleak in stmmac_test_arpoffload()
    
    [ Upstream commit f150b63f3fa5fdd81e0dd6151e8850268e29438c ]
    
    The skb allocated by stmmac_test_get_arp_skb() hasn't been released in
    some error handling case, which will lead to a memory leak. Fix this up
    by adding kfree_skb() to release skb.
    
    Compile tested only.
    
    Fixes: 5e3fb0a6e2b3 ("net: stmmac: selftests: Implement the ARP Offload test")
    Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stream: purge sk_error_queue in sk_stream_kill_queues() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Dec 16 16:29:17 2022 +0000

    net: stream: purge sk_error_queue in sk_stream_kill_queues()
    
    [ Upstream commit e0c8bccd40fc1c19e1d246c39bcf79e357e1ada3 ]
    
    Changheon Lee reported TCP socket leaks, with a nice repro.
    
    It seems we leak TCP sockets with the following sequence:
    
    1) SOF_TIMESTAMPING_TX_ACK is enabled on the socket.
    
       Each ACK will cook an skb put in error queue, from __skb_tstamp_tx().
       __skb_tstamp_tx() is using skb_clone(), unless
       SOF_TIMESTAMPING_OPT_TSONLY was also requested.
    
    2) If the application is also using MSG_ZEROCOPY, then we put in the
       error queue cloned skbs that had a struct ubuf_info attached to them.
    
       Whenever an struct ubuf_info is allocated, sock_zerocopy_alloc()
       does a sock_hold().
    
       As long as the cloned skbs are still in sk_error_queue,
       socket refcount is kept elevated.
    
    3) Application closes the socket, while error queue is not empty.
    
    Since tcp_close() no longer purges the socket error queue,
    we might end up with a TCP socket with at least one skb in
    error queue keeping the socket alive forever.
    
    This bug can be (ab)used to consume all kernel memory
    and freeze the host.
    
    We need to purge the error queue, with proper synchronization
    against concurrent writers.
    
    Fixes: 24bcbe1cc69f ("net: stream: don't purge sk_error_queue in sk_stream_kill_queues()")
    Reported-by: Changheon Lee <darklight2357@icloud.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: vmw_vsock: vmci: Check memcpy_from_msg() [+ + +]
Author: Artem Chernyshev <artem.chernyshev@red-soft.ru>
Date:   Tue Dec 6 09:58:34 2022 +0300

    net: vmw_vsock: vmci: Check memcpy_from_msg()
    
    [ Upstream commit 44aa5a6dba8283bfda28b1517af4de711c5652a4 ]
    
    vmci_transport_dgram_enqueue() does not check the return value
    of memcpy_from_msg().  If memcpy_from_msg() fails, it is possible that
    uninitialized memory contents are sent unintentionally instead of user's
    message in the datagram to the destination.  Return with an error if
    memcpy_from_msg() fails.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: 0f7db23a07af ("vmci_transport: switch ->enqeue_dgram, ->enqueue_stream and ->dequeue_stream to msghdr")
    Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
    Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
    Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net_sched: reject TCF_EM_SIMPLE case for complex ematch module [+ + +]
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Sat Dec 17 14:17:07 2022 -0800

    net_sched: reject TCF_EM_SIMPLE case for complex ematch module
    
    [ Upstream commit 9cd3fd2054c3b3055163accbf2f31a4426f10317 ]
    
    When TCF_EM_SIMPLE was introduced, it is supposed to be convenient
    for ematch implementation:
    
    https://lore.kernel.org/all/20050105110048.GO26856@postel.suug.ch/
    
    "You don't have to, providing a 32bit data chunk without TCF_EM_SIMPLE
    set will simply result in allocating & copy. It's an optimization,
    nothing more."
    
    So if an ematch module provides ops->datalen that means it wants a
    complex data structure (saved in its em->data) instead of a simple u32
    value. We should simply reject such a combination, otherwise this u32
    could be misinterpreted as a pointer.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-and-tested-by: syzbot+4caeae4c7103813598ae@syzkaller.appspotmail.com
    Reported-by: Jun Nie <jun.nie@linaro.org>
    Cc: Jamal Hadi Salim <jhs@mojatatu.com>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: conntrack: set icmpv6 redirects as RELATED [+ + +]
Author: Florian Westphal <fw@strlen.de>
Date:   Tue Nov 22 16:00:09 2022 +0100

    netfilter: conntrack: set icmpv6 redirects as RELATED
    
    [ Upstream commit 7d7cfb48d81353e826493d24c7cec7360950968f ]
    
    icmp conntrack will set icmp redirects as RELATED, but icmpv6 will not
    do this.
    
    For icmpv6, only icmp errors (code <= 128) are examined for RELATED state.
    ICMPV6 Redirects are part of neighbour discovery mechanism, those are
    handled by marking a selected subset (e.g.  neighbour solicitations) as
    UNTRACKED, but not REDIRECT -- they will thus be flagged as INVALID.
    
    Add minimal support for REDIRECTs.  No parsing of neighbour options is
    added for simplicity, so this will only check that we have the embeeded
    original header (ND_OPT_REDIRECT_HDR), and then attempt to do a flow
    lookup for this tuple.
    
    Also extend the existing test case to cover redirects.
    
    Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.")
    Reported-by: Eric Garver <eric@garver.life>
    Link: https://github.com/firewalld/firewalld/issues/1046
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Acked-by: Eric Garver <eric@garver.life>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function. [+ + +]
Author: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
Date:   Wed Jan 11 11:57:39 2023 +0000

    netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.
    
    commit 9ea4b476cea1b7d461d16dda25ca3c7e616e2d15 upstream.
    
    When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value of
    an arithmetic expression 2 << (netmask - mask_bits - 1) is subject
    to overflow due to a failure casting operands to a larger data type
    before performing the arithmetic.
    
    Note that it's harmless since the value will be checked at the next step.
    
    Found by InfoTeCS on behalf of Linux Verification Center
    (linuxtesting.org) with SVACE.
    
    Fixes: b9fed748185a ("netfilter: ipset: Check and reject crazy /0 input parameters")
    Signed-off-by: Ilia.Gavrilov <Ilia.Gavrilov@infotecs.ru>
    Reviewed-by: Simon Horman <simon.horman@corigine.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfc: Fix potential resource leaks [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Fri Dec 23 11:37:18 2022 +0400

    nfc: Fix potential resource leaks
    
    [ Upstream commit df49908f3c52d211aea5e2a14a93bbe67a2cb3af ]
    
    nfc_get_device() take reference for the device, add missing
    nfc_put_device() to release it when not need anymore.
    Also fix the style warnning by use error EOPNOTSUPP instead of
    ENOTSUPP.
    
    Fixes: 5ce3f32b5264 ("NFC: netlink: SE API implementation")
    Fixes: 29e76924cf08 ("nfc: netlink: Add capability to reply to vendor_cmd with data")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nfc: pn533: Clear nfc_target before being used [+ + +]
Author: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Date:   Wed Dec 14 10:51:39 2022 +0900

    nfc: pn533: Clear nfc_target before being used
    
    [ Upstream commit 9f28157778ede0d4f183f7ab3b46995bb400abbe ]
    
    Fix a slab-out-of-bounds read that occurs in nla_put() called from
    nfc_genl_send_target() when target->sensb_res_len, which is duplicated
    from an nfc_target in pn533, is too large as the nfc_target is not
    properly initialized and retains garbage values. Clear nfc_targets with
    memset() before they are used.
    
    Found by a modified version of syzkaller.
    
    BUG: KASAN: slab-out-of-bounds in nla_put
    Call Trace:
     memcpy
     nla_put
     nfc_genl_dump_targets
     genl_lock_dumpit
     netlink_dump
     __netlink_dump_start
     genl_family_rcv_msg_dumpit
     genl_rcv_msg
     netlink_rcv_skb
     genl_rcv
     netlink_unicast
     netlink_sendmsg
     sock_sendmsg
     ____sys_sendmsg
     ___sys_sendmsg
     __sys_sendmsg
     do_syscall_64
    
    Fixes: 673088fb42d0 ("NFC: pn533: Send ATR_REQ directly for active device detection")
    Fixes: 361f3cb7f9cf ("NFC: DEP link hook implementation for pn533")
    Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Link: https://lore.kernel.org/r/20221214015139.119673-1-linuxlovemin@yonsei.ac.kr
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame() [+ + +]
Author: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Date:   Fri Jan 6 17:23:44 2023 +0900

    nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
    
    [ Upstream commit 9dab880d675b9d0dd56c6428e4e8352a3339371d ]
    
    Fix a use-after-free that occurs in hcd when in_urb sent from
    pn533_usb_send_frame() is completed earlier than out_urb. Its callback
    frees the skb data in pn533_send_async_complete() that is used as a
    transfer buffer of out_urb. Wait before sending in_urb until the
    callback of out_urb is called. To modify the callback of out_urb alone,
    separate the complete function of out_urb and ack_urb.
    
    Found by a modified version of syzkaller.
    
    BUG: KASAN: use-after-free in dummy_timer
    Call Trace:
     memcpy (mm/kasan/shadow.c:65)
     dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)
     transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)
     dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)
     arch_static_branch (arch/x86/include/asm/jump_label.h:27)
     static_key_false (include/linux/jump_label.h:207)
     timer_expire_exit (include/trace/events/timer.h:127)
     call_timer_fn (kernel/time/timer.c:1475)
     expire_timers (kernel/time/timer.c:1519)
     __run_timers (kernel/time/timer.c:1790)
     run_timer_softirq (kernel/time/timer.c:1803)
    
    Fixes: c46ee38620a2 ("NFC: pn533: add NXP pn533 nfc device driver")
    Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSD: Add tracepoints to NFSD's duplicate reply cache [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Sat May 2 11:34:40 2020 -0400

    NFSD: Add tracepoints to NFSD's duplicate reply cache
    
    [ Upstream commit 0b175b18648ebedfe255b11a7792f1d76848a8f7 ]
    
    Try to capture DRC failures.
    
    Two additional clean-ups:
    - Introduce Doxygen-style comments for the main entry points
    - Remove a dprintk that fires for an allocation failure. This was
      the only dprintk in the REPCACHE class.
    
    Reported-by: kbuild test robot <lkp@intel.com>
    [ cel: force typecast for display of checksum values ]
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Stable-dep-of: 3bc8edc98bd4 ("nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfsd: Define the file access mode enum for tracing [+ + +]
Author: Trond Myklebust <trondmy@gmail.com>
Date:   Tue Jan 14 12:00:22 2020 -0500

    nfsd: Define the file access mode enum for tracing
    
    [ Upstream commit c19285596de699e4602f9c89785e6b8c29422286 ]
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Stable-dep-of: 3bc8edc98bd4 ("nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nfsd: don't call nfsd_file_put from client states seqfile display [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Fri Oct 28 08:13:53 2022 -0400

    nfsd: don't call nfsd_file_put from client states seqfile display
    
    [ Upstream commit e0aa651068bfd520afcd357af8ecd2de005fc83d ]
    
    We had a report of this:
    
        BUG: sleeping function called from invalid context at fs/nfsd/filecache.c:440
    
    ...with a stack trace showing nfsd_file_put being called from
    nfs4_show_open. This code has always tried to call fput while holding a
    spinlock, but we recently changed this to use the filecache, and that
    started triggering the might_sleep() in nfsd_file_put.
    
    states_start takes and holds the cl_lock while iterating over the
    client's states, and we can't sleep with that held.
    
    Have the various nfs4_show_* functions instead hold the fi_lock instead
    of taking a nfsd_file reference.
    
    Fixes: 78599c42ae3c ("nfsd4: add file to display list of client's opens")
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=2138357
    Reported-by: Zhi Li <yieli@redhat.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nfsd: fix handling of readdir in v4root vs. mount upcall timeout [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Tue Dec 13 13:08:26 2022 -0500

    nfsd: fix handling of readdir in v4root vs. mount upcall timeout
    
    commit cad853374d85fe678d721512cecfabd7636e51f3 upstream.
    
    If v4 READDIR operation hits a mountpoint and gets back an error,
    then it will include that entry in the reply and set RDATTR_ERROR for it
    to the error.
    
    That's fine for "normal" exported filesystems, but on the v4root, we
    need to be more careful to only expose the existence of dentries that
    lead to exports.
    
    If the mountd upcall times out while checking to see whether a
    mountpoint on the v4root is exported, then we have no recourse other
    than to fail the whole operation.
    
    Cc: Steve Dickson <steved@redhat.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216777
    Reported-by: JianHong Yin <yin-jianhong@163.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfsd: shut down the NFSv4 state objects before the filecache [+ + +]
Author: Jeff Layton <jlayton@kernel.org>
Date:   Thu Dec 22 09:51:30 2022 -0500

    nfsd: shut down the NFSv4 state objects before the filecache
    
    [ Upstream commit 789e1e10f214c00ca18fc6610824c5b9876ba5f2 ]
    
    Currently, we shut down the filecache before trying to clean up the
    stateids that depend on it. This leads to the kernel trying to free an
    nfsd_file twice, and a refcount overput on the nf_mark.
    
    Change the shutdown procedure to tear down all of the stateids prior
    to shutting down the filecache.
    
    Reported-and-tested-by: Wang Yugui <wangyugui@e16-tech.com>
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Fixes: 5e113224c17e ("nfsd: nfsd_file cache entries should be per net namespace")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure [+ + +]
Author: Dan Aloni <dan.aloni@vastdata.com>
Date:   Mon Dec 12 13:11:06 2022 +0200

    nfsd: under NFSv4.1, fix double svc_xprt_put on rpc_create failure
    
    [ Upstream commit 3bc8edc98bd43540dbe648e4ef91f443d6d20a24 ]
    
    On error situation `clp->cl_cb_conn.cb_xprt` should not be given
    a reference to the xprt otherwise both client cleanup and the
    error handling path of the caller call to put it. Better to
    delay handing over the reference to a later branch.
    
    [   72.530665] refcount_t: underflow; use-after-free.
    [   72.531933] WARNING: CPU: 0 PID: 173 at lib/refcount.c:28 refcount_warn_saturate+0xcf/0x120
    [   72.533075] Modules linked in: nfsd(OE) nfsv4(OE) nfsv3(OE) nfs(OE) lockd(OE) compat_nfs_ssc(OE) nfs_acl(OE) rpcsec_gss_krb5(OE) auth_rpcgss(OE) rpcrdma(OE) dns_resolver fscache netfs grace rdma_cm iw_cm ib_cm sunrpc(OE) mlx5_ib mlx5_core mlxfw pci_hyperv_intf ib_uverbs ib_core xt_MASQUERADE nf_conntrack_netlink nft_counter xt_addrtype nft_compat br_netfilter bridge stp llc nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink crct10dif_pclmul crc32_pclmul ghash_clmulni_intel xfs serio_raw virtio_net virtio_blk net_failover failover fuse [last unloaded: sunrpc]
    [   72.540389] CPU: 0 PID: 173 Comm: kworker/u16:5 Tainted: G           OE     5.15.82-dan #1
    [   72.541511] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+1084+97b81f61 04/01/2014
    [   72.542717] Workqueue: nfsd4_callbacks nfsd4_run_cb_work [nfsd]
    [   72.543575] RIP: 0010:refcount_warn_saturate+0xcf/0x120
    [   72.544299] Code: 55 00 0f 0b 5d e9 01 50 98 00 80 3d 75 9e 39 08 00 0f 85 74 ff ff ff 48 c7 c7 e8 d1 60 8e c6 05 61 9e 39 08 01 e8 f6 51 55 00 <0f> 0b 5d e9 d9 4f 98 00 80 3d 4b 9e 39 08 00 0f 85 4c ff ff ff 48
    [   72.546666] RSP: 0018:ffffb3f841157cf0 EFLAGS: 00010286
    [   72.547393] RAX: 0000000000000026 RBX: ffff89ac6231d478 RCX: 0000000000000000
    [   72.548324] RDX: ffff89adb7c2c2c0 RSI: ffff89adb7c205c0 RDI: ffff89adb7c205c0
    [   72.549271] RBP: ffffb3f841157cf0 R08: 0000000000000000 R09: c0000000ffefffff
    [   72.550209] R10: 0000000000000001 R11: ffffb3f841157ad0 R12: ffff89ac6231d180
    [   72.551142] R13: ffff89ac6231d478 R14: ffff89ac40c06180 R15: ffff89ac6231d4b0
    [   72.552089] FS:  0000000000000000(0000) GS:ffff89adb7c00000(0000) knlGS:0000000000000000
    [   72.553175] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   72.553934] CR2: 0000563a310506a8 CR3: 0000000109a66000 CR4: 0000000000350ef0
    [   72.554874] Call Trace:
    [   72.555278]  <TASK>
    [   72.555614]  svc_xprt_put+0xaf/0xe0 [sunrpc]
    [   72.556276]  nfsd4_process_cb_update.isra.11+0xb7/0x410 [nfsd]
    [   72.557087]  ? update_load_avg+0x82/0x610
    [   72.557652]  ? cpuacct_charge+0x60/0x70
    [   72.558212]  ? dequeue_entity+0xdb/0x3e0
    [   72.558765]  ? queued_spin_unlock+0x9/0x20
    [   72.559358]  nfsd4_run_cb_work+0xfc/0x270 [nfsd]
    [   72.560031]  process_one_work+0x1df/0x390
    [   72.560600]  worker_thread+0x37/0x3b0
    [   72.561644]  ? process_one_work+0x390/0x390
    [   72.562247]  kthread+0x12f/0x150
    [   72.562710]  ? set_kthread_struct+0x50/0x50
    [   72.563309]  ret_from_fork+0x22/0x30
    [   72.563818]  </TASK>
    [   72.564189] ---[ end trace 031117b1c72ec616 ]---
    [   72.566019] list_add corruption. next->prev should be prev (ffff89ac4977e538), but was ffff89ac4763e018. (next=ffff89ac4763e018).
    [   72.567647] ------------[ cut here ]------------
    
    Fixes: a4abc6b12eb1 ("nfsd: Fix svc_xprt refcnt leak when setup callback client failed")
    Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
    Cc: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Dan Aloni <dan.aloni@vastdata.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSv4.2: Clear FATTR4_WORD2_SECURITY_LABEL when done decoding [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Oct 18 16:44:47 2022 -0400

    NFSv4.2: Clear FATTR4_WORD2_SECURITY_LABEL when done decoding
    
    [ Upstream commit eef7314caf2d73a94b68ba293cd105154d3a664e ]
    
    We need to clear the FATTR4_WORD2_SECURITY_LABEL bitmap flag
    irrespective of whether or not the label is too long.
    
    Fixes: aa9c2669626c ("NFS: Client implementation of Labeled-NFS")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

NFSv4.2: Fix a memory stomp in decode_attr_security_label [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Oct 18 18:21:14 2022 -0400

    NFSv4.2: Fix a memory stomp in decode_attr_security_label
    
    [ Upstream commit 43c1031f7110967c240cb6e922adcfc4b8899183 ]
    
    We must not change the value of label->len if it is zero, since that
    indicates we stored a label.
    
    Fixes: b4487b935452 ("nfs: Fix getxattr kernel panic and memory overflow")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

NFSv4.2: Fix initialisation of struct nfs4_label [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Wed Oct 19 13:12:11 2022 -0400

    NFSv4.2: Fix initialisation of struct nfs4_label
    
    [ Upstream commit c528f70f504434eaff993a5ddd52203a2010d51f ]
    
    The call to nfs4_label_init_security() should return a fully initialised
    label.
    
    Fixes: aa9c2669626c ("NFS: Client implementation of Labeled-NFS")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSv4.x: Fail client initialisation if state manager thread can't run [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Tue Dec 6 12:42:59 2022 -0500

    NFSv4.x: Fail client initialisation if state manager thread can't run
    
    [ Upstream commit b4e4f66901658fae0614dea5bf91062a5387eda7 ]
    
    If the state manager thread fails to start, then we should just mark the
    client initialisation as failed so that other processes or threads don't
    get stuck in nfs_wait_client_init_complete().
    
    Reported-by: ChenXiaoSong <chenxiaosong2@huawei.com>
    Fixes: 4697bd5e9419 ("NFSv4: Fix a race in the net namespace mount notification")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
NFSv4: Fix a deadlock between nfs4_open_recover_helper() and delegreturn [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Nov 4 13:20:01 2022 -0400

    NFSv4: Fix a deadlock between nfs4_open_recover_helper() and delegreturn
    
    [ Upstream commit 51069e4aef6257b0454057359faed0ab0c9af083 ]
    
    If we're asked to recover open state while a delegation return is
    outstanding, then the state manager thread cannot use a cached open, so
    if the server returns a delegation, we can end up deadlocked behind the
    pending delegreturn.
    To avoid this problem, let's just ask the server not to give us a
    delegation unless we're explicitly reclaiming one.
    
    Fixes: be36e185bd26 ("NFSv4: nfs4_open_recover_helper() must set share access")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset() [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Thu Oct 27 13:43:05 2022 +0900

    nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset()
    
    [ Upstream commit 610a2a3d7d8be3537458a378ec69396a76c385b6 ]
    
    Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mount
    time".
    
    The first patch fixes a bug reported by syzbot, and the second one fixes
    the remaining bug of the same kind.  Although they are triggered by the
    same super block data anomaly, I divided it into the above two because the
    details of the issues and how to fix it are different.
    
    Both are required to eliminate the shift-out-of-bounds issues at mount
    time.
    
    This patch (of 2):
    
    If the block size exponent information written in an on-disk superblock is
    corrupted, nilfs_sb2_bad_offset helper function can trigger
    shift-out-of-bounds warning followed by a kernel panic (if panic_on_warn
    is set):
    
     shift exponent 38983 is too large for 64-bit type 'unsigned long long'
     Call Trace:
      <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
      ubsan_epilogue lib/ubsan.c:151 [inline]
      __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322
      nilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline]
      nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523
      init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577
      nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047
      nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317
      ...
    
    In addition, since nilfs_sb2_bad_offset() performs multiplication without
    considering the upper bound, the computation may overflow if the disk
    layout parameters are not normal.
    
    This fixes these issues by inserting preliminary sanity checks for those
    parameters and by converting the comparison from one involving
    multiplication and left bit-shifting to one using division and right
    bit-shifting.
    
    Link: https://lkml.kernel.org/r/20221027044306.42774-1-konishi.ryusuke@gmail.com
    Link: https://lkml.kernel.org/r/20221027044306.42774-2-konishi.ryusuke@gmail.com
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+e91619dd4c11c4960706@syzkaller.appspotmail.com
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ntb_netdev: Use dev_kfree_skb_any() in interrupt context [+ + +]
Author: Eric Pilmore <epilmore@gigaio.com>
Date:   Thu Dec 8 16:06:59 2022 -0800

    ntb_netdev: Use dev_kfree_skb_any() in interrupt context
    
    [ Upstream commit 5f7d78b2b12a9d561f48fa00bab29b40f4616dad ]
    
    TX/RX callback handlers (ntb_netdev_tx_handler(),
    ntb_netdev_rx_handler()) can be called in interrupt
    context via the DMA framework when the respective
    DMA operations have completed. As such, any calls
    by these routines to free skb's, should use the
    interrupt context safe dev_kfree_skb_any() function.
    
    Previously, these callback handlers would call the
    interrupt unsafe version of dev_kfree_skb(). This has
    not presented an issue on Intel IOAT DMA engines as
    that driver utilizes tasklets rather than a hard
    interrupt handler, like the AMD PTDMA DMA driver.
    On AMD systems, a kernel WARNING message is
    encountered, which is being issued from
    skb_release_head_state() due to in_hardirq()
    being true.
    
    Besides the user visible WARNING from the kernel,
    the other symptom of this bug was that TCP/IP performance
    across the ntb_netdev interface was very poor, i.e.
    approximately an order of magnitude below what was
    expected. With the repair to use dev_kfree_skb_any(),
    kernel WARNINGs from skb_release_head_state() ceased
    and TCP/IP performance, as measured by iperf, was on
    par with expected results, approximately 20 Gb/s on
    AMD Milan based server. Note that this performance
    is comparable with Intel based servers.
    
    Fixes: 765ccc7bc3d91 ("ntb_netdev: correct skb leak")
    Fixes: 548c237c0a997 ("net: Add support for NTB virtual ethernet device")
    Signed-off-by: Eric Pilmore <epilmore@gigaio.com>
    Reviewed-by: Dave Jiang <dave.jiang@intel.com>
    Link: https://lore.kernel.org/r/20221209000659.8318-1-epilmore@gigaio.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme-pci: fix doorbell buffer value endianness [+ + +]
Author: Klaus Jensen <k.jensen@samsung.com>
Date:   Tue Dec 13 09:58:07 2022 +0100

    nvme-pci: fix doorbell buffer value endianness
    
    [ Upstream commit b5f96cb719d8ba220b565ddd3ba4ac0d8bcfb130 ]
    
    When using shadow doorbells, the event index and the doorbell values are
    written to host memory. Prior to this patch, the values written would
    erroneously be written in host endianness. This causes trouble on
    big-endian platforms. Fix this by adding missing endian conversions.
    
    This issue was noticed by Guenter while testing various big-endian
    platforms under QEMU[1]. A similar fix required for hw/nvme in QEMU is
    up for review as well[2].
    
      [1]: https://lore.kernel.org/qemu-devel/20221209110022.GA3396194@roeck-us.net/
      [2]: https://lore.kernel.org/qemu-devel/20221212114409.34972-4-its@irrelevant.dk/
    
    Fixes: f9f38e33389c ("nvme: improve performance for virtual NVMe devices")
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvme: fix the NVME_CMD_EFFECTS_CSE_MASK definition [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Wed Dec 21 10:30:45 2022 +0100

    nvme: fix the NVME_CMD_EFFECTS_CSE_MASK definition
    
    [ Upstream commit 685e6311637e46f3212439ce2789f8a300e5050f ]
    
    3 << 16 does not generate the correct mask for bits 16, 17 and 18.
    Use the GENMASK macro to generate the correct mask instead.
    
    Fixes: 84fef62d135b ("nvme: check admin passthru command effects")
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Keith Busch <kbusch@kernel.org>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Reviewed-by: Kanchan Joshi <joshi.k@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nvme: resync include/linux/nvme.h with nvmecli [+ + +]
Author: Revanth Rajashekar <revanth.rajashekar@intel.com>
Date:   Mon Oct 14 11:16:07 2019 -0600

    nvme: resync include/linux/nvme.h with nvmecli
    
    [ Upstream commit 48c9e85b23464a7d1e3ebd70b79cc3a2d97d3222 ]
    
    Update enumerations and structures in include/linux/nvme.h
    to resync with the nvmecli.
    
    All the updates are mentioned in the ratified NVMe 1.4 spec
    https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4-2019.06.10-Ratified.pdf
    
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Revanth Rajashekar <revanth.rajashekar@intel.com>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: 685e6311637e ("nvme: fix the NVME_CMD_EFFECTS_CSE_MASK definition")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
objtool: Fix SEGFAULT [+ + +]
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date:   Mon Nov 14 23:27:46 2022 +0530

    objtool: Fix SEGFAULT
    
    [ Upstream commit efb11fdb3e1a9f694fa12b70b21e69e55ec59c36 ]
    
    find_insn() will return NULL in case of failure. Check insn in order
    to avoid a kernel Oops for NULL pointer dereference.
    
    Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221114175754.1131267-9-sv@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ocfs2: fix freeing uninitialized resource on ocfs2_dlm_shutdown [+ + +]
Author: Heming Zhao <ocfs2-devel@oss.oracle.com>
Date:   Mon Aug 15 16:57:54 2022 +0800

    ocfs2: fix freeing uninitialized resource on ocfs2_dlm_shutdown
    
    commit 550842cc60987b269e31b222283ade3e1b6c7fc8 upstream.
    
    After commit 0737e01de9c4 ("ocfs2: ocfs2_mount_volume does cleanup job
    before return error"), any procedure after ocfs2_dlm_init() fails will
    trigger crash when calling ocfs2_dlm_shutdown().
    
    ie: On local mount mode, no dlm resource is initialized.  If
    ocfs2_mount_volume() fails in ocfs2_find_slot(), error handling will call
    ocfs2_dlm_shutdown(), then does dlm resource cleanup job, which will
    trigger kernel crash.
    
    This solution should bypass uninitialized resources in
    ocfs2_dlm_shutdown().
    
    Link: https://lkml.kernel.org/r/20220815085754.20417-1-heming.zhao@suse.com
    Fixes: 0737e01de9c4 ("ocfs2: ocfs2_mount_volume does cleanup job before return error")
    Signed-off-by: Heming Zhao <heming.zhao@suse.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ocfs2: fix memory leak in ocfs2_mount_volume() [+ + +]
Author: Li Zetao <ocfs2-devel@oss.oracle.com>
Date:   Wed Nov 9 15:46:27 2022 +0800

    ocfs2: fix memory leak in ocfs2_mount_volume()
    
    [ Upstream commit ce2fcf1516d674a174d9b34d1e1024d64de9fba3 ]
    
    There is a memory leak reported by kmemleak:
    
      unreferenced object 0xffff88810cc65e60 (size 32):
        comm "mount.ocfs2", pid 23753, jiffies 4302528942 (age 34735.105s)
        hex dump (first 32 bytes):
          10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01  ................
          01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff8170f73d>] __kmalloc+0x4d/0x150
          [<ffffffffa0ac3f51>] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2]
          [<ffffffffa0b65165>] ocfs2_check_volume+0x485/0x900 [ocfs2]
          [<ffffffffa0b68129>] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2]
          [<ffffffffa0b7160b>] ocfs2_fill_super+0xe0b/0x1740 [ocfs2]
          [<ffffffff818e1fe2>] mount_bdev+0x312/0x400
          [<ffffffff819a086d>] legacy_get_tree+0xed/0x1d0
          [<ffffffff818de82d>] vfs_get_tree+0x7d/0x230
          [<ffffffff81957f92>] path_mount+0xd62/0x1760
          [<ffffffff81958a5a>] do_mount+0xca/0xe0
          [<ffffffff81958d3c>] __x64_sys_mount+0x12c/0x1a0
          [<ffffffff82f26f15>] do_syscall_64+0x35/0x80
          [<ffffffff8300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    This call stack is related to two problems.  Firstly, the ocfs2 super uses
    "replay_map" to trace online/offline slots, in order to recover offline
    slots during recovery and mount.  But when ocfs2_truncate_log_init()
    returns an error in ocfs2_mount_volume(), the memory of "replay_map" will
    not be freed in error handling path.  Secondly, the memory of "replay_map"
    will not be freed if d_make_root() returns an error in ocfs2_fill_super().
    But the memory of "replay_map" will be freed normally when completing
    recovery and mount in ocfs2_complete_mount_recovery().
    
    Fix the first problem by adding error handling path to free "replay_map"
    when ocfs2_truncate_log_init() fails.  And fix the second problem by
    calling ocfs2_free_replay_slots(osb) in the error handling path
    "out_dismount".  In addition, since ocfs2_free_replay_slots() is static,
    it is necessary to remove its static attribute and declare it in header
    file.
    
    Link: https://lkml.kernel.org/r/20221109074627.2303950-1-lizetao1@huawei.com
    Fixes: 9140db04ef18 ("ocfs2: recover orphans in offline slots during recovery and mount")
    Signed-off-by: Li Zetao <lizetao1@huawei.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ocfs2: fix memory leak in ocfs2_stack_glue_init() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Tue Nov 1 19:15:33 2022 +0800

    ocfs2: fix memory leak in ocfs2_stack_glue_init()
    
    [ Upstream commit 13b6269dd022aaa69ca8d1df374ab327504121cf ]
    
    ocfs2_table_header should be free in ocfs2_stack_glue_init() if
    ocfs2_sysfs_init() failed, otherwise kmemleak will report memleak.
    
    BUG: memory leak
    unreferenced object 0xffff88810eeb5800 (size 128):
      comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s)
      hex dump (first 32 bytes):
        c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00  .@..............
        01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<000000001e59e1cd>] __register_sysctl_table+0xca/0xef0
        [<00000000c04f70f7>] 0xffffffffa0050037
        [<000000001bd12912>] do_one_initcall+0xdb/0x480
        [<0000000064f766c9>] do_init_module+0x1cf/0x680
        [<000000002ba52db0>] load_module+0x6441/0x6f20
        [<000000009772580d>] __do_sys_finit_module+0x12f/0x1c0
        [<00000000380c1f22>] do_syscall_64+0x3f/0x90
        [<000000004cf473bc>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Link: https://lkml.kernel.org/r/41651ca1-432a-db34-eb97-d35744559de1@linux.alibaba.com
    Fixes: 3878f110f71a ("ocfs2: Move the hb_ctl_path sysctl into the stack glue.")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Jun Piao <piaojun@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ocfs2: ocfs2_mount_volume does cleanup job before return error [+ + +]
Author: Heming Zhao via Ocfs2-devel <ocfs2-devel@oss.oracle.com>
Date:   Fri Apr 29 14:37:58 2022 -0700

    ocfs2: ocfs2_mount_volume does cleanup job before return error
    
    [ Upstream commit 0737e01de9c411e4db87dcedf4a9789d41b1c5c1 ]
    
    After this patch, when error, ocfs2_fill_super doesn't take care to
    release resources which are allocated in ocfs2_mount_volume.
    
    Link: https://lkml.kernel.org/r/20220424130952.2436-5-heming.zhao@suse.com
    Signed-off-by: Heming Zhao <heming.zhao@suse.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: ce2fcf1516d6 ("ocfs2: fix memory leak in ocfs2_mount_volume()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ocfs2: rewrite error handling of ocfs2_fill_super [+ + +]
Author: Heming Zhao via Ocfs2-devel <ocfs2-devel@oss.oracle.com>
Date:   Fri Apr 29 14:37:58 2022 -0700

    ocfs2: rewrite error handling of ocfs2_fill_super
    
    [ Upstream commit f1e75d128b46e3b066e7b2e7cfca10491109d44d ]
    
    Current ocfs2_fill_super() uses one goto label "read_super_error" to
    handle all error cases.  And with previous serial patches, the error
    handling should fork more branches to handle different error cases.  This
    patch rewrite the error handling of ocfs2_fill_super.
    
    Link: https://lkml.kernel.org/r/20220424130952.2436-6-heming.zhao@suse.com
    Signed-off-by: Heming Zhao <heming.zhao@suse.com>
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Gang He <ghe@suse.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Stable-dep-of: ce2fcf1516d6 ("ocfs2: fix memory leak in ocfs2_mount_volume()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
of: overlay: fix null pointer dereferencing in find_dup_cset_node_entry() and find_dup_cset_prop() [+ + +]
Author: ruanjinjie <ruanjinjie@huawei.com>
Date:   Sun Dec 11 10:33:37 2022 +0800

    of: overlay: fix null pointer dereferencing in find_dup_cset_node_entry() and find_dup_cset_prop()
    
    [ Upstream commit ee9d7a0e754568180a2f8ebc4aad226278a9116f ]
    
    When kmalloc() fail to allocate memory in kasprintf(), fn_1 or fn_2 will
    be NULL, and strcmp() will cause null pointer dereference.
    
    Fixes: 2fe0e8769df9 ("of: overlay: check prevents multiple fragments touching same property")
    Signed-off-by: ruanjinjie <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20221211023337.592266-1-ruanjinjie@huawei.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
openvswitch: Fix flow lookup to use unmasked key [+ + +]
Author: Eelco Chaudron <echaudro@redhat.com>
Date:   Thu Dec 15 15:46:33 2022 +0100

    openvswitch: Fix flow lookup to use unmasked key
    
    [ Upstream commit 68bb10101e6b0a6bb44e9c908ef795fc4af99eae ]
    
    The commit mentioned below causes the ovs_flow_tbl_lookup() function
    to be called with the masked key. However, it's supposed to be called
    with the unmasked key. This due to the fact that the datapath supports
    installing wider flows, and OVS relies on this behavior. For example
    if ipv4(src=1.1.1.1/192.0.0.0, dst=1.1.1.2/192.0.0.0) exists, a wider
    flow (smaller mask) of ipv4(src=192.1.1.1/128.0.0.0,dst=192.1.1.2/
    128.0.0.0) is allowed to be added.
    
    However, if we try to add a wildcard rule, the installation fails:
    
    $ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
      ipv4(src=1.1.1.1/192.0.0.0,dst=1.1.1.2/192.0.0.0,frag=no)" 2
    $ ovs-appctl dpctl/add-flow system@myDP "in_port(1),eth_type(0x0800), \
      ipv4(src=192.1.1.1/0.0.0.0,dst=49.1.1.2/0.0.0.0,frag=no)" 2
    ovs-vswitchd: updating flow table (File exists)
    
    The reason is that the key used to determine if the flow is already
    present in the system uses the original key ANDed with the mask.
    This results in the IP address not being part of the (miniflow) key,
    i.e., being substituted with an all-zero value. When doing the actual
    lookup, this results in the key wrongfully matching the first flow,
    and therefore the flow does not get installed.
    
    This change reverses the commit below, but rather than having the key
    on the stack, it's allocated.
    
    Fixes: 190aa3e77880 ("openvswitch: Fix Frame-size larger than 1024 bytes warning.")
    
    Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
orangefs: Fix kmemleak in orangefs_prepare_debugfs_help_string() [+ + +]
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Tue Oct 18 12:40:05 2022 +0800

    orangefs: Fix kmemleak in orangefs_prepare_debugfs_help_string()
    
    [ Upstream commit d23417a5bf3a3afc55de5442eb46e1e60458b0a1 ]
    
    When insert and remove the orangefs module, then debug_help_string will
    be leaked:
    
      unreferenced object 0xffff8881652ba000 (size 4096):
        comm "insmod", pid 1701, jiffies 4294893639 (age 13218.530s)
        hex dump (first 32 bytes):
          43 6c 69 65 6e 74 20 44 65 62 75 67 20 4b 65 79  Client Debug Key
          77 6f 72 64 73 20 61 72 65 20 75 6e 6b 6e 6f 77  words are unknow
        backtrace:
          [<0000000004e6f8e3>] kmalloc_trace+0x27/0xa0
          [<0000000006f75d85>] orangefs_prepare_debugfs_help_string+0x5e/0x480 [orangefs]
          [<0000000091270a2a>] _sub_I_65535_1+0x57/0xf70 [crc_itu_t]
          [<000000004b1ee1a3>] do_one_initcall+0x87/0x2a0
          [<000000001d0614ae>] do_init_module+0xdf/0x320
          [<00000000efef068c>] load_module+0x2f98/0x3330
          [<000000006533b44d>] __do_sys_finit_module+0x113/0x1b0
          [<00000000a0da6f99>] do_syscall_64+0x35/0x80
          [<000000007790b19b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    When remove the module, should always free debug_help_string. Should
    always free the allocated buffer when change the free_debug_help_string.
    
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Mike Marshall <hubcap@omnibond.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init() [+ + +]
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Tue Oct 18 12:40:07 2022 +0800

    orangefs: Fix kmemleak in orangefs_{kernel,client}_debug_init()
    
    [ Upstream commit 31720a2b109b3080eb77e97b8f6f50a27b4ae599 ]
    
    When insert and remove the orangefs module, there are memory leaked
    as below:
    
    unreferenced object 0xffff88816b0cc000 (size 2048):
      comm "insmod", pid 783, jiffies 4294813439 (age 65.512s)
      hex dump (first 32 bytes):
        6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00  none............
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<0000000031ab7788>] kmalloc_trace+0x27/0xa0
        [<000000005b405fee>] orangefs_debugfs_init.cold+0xaf/0x17f
        [<00000000e5a0085b>] 0xffffffffa02780f9
        [<000000004232d9f7>] do_one_initcall+0x87/0x2a0
        [<0000000054f22384>] do_init_module+0xdf/0x320
        [<000000003263bdea>] load_module+0x2f98/0x3330
        [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0
        [<00000000250ae02b>] do_syscall_64+0x35/0x80
        [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Use the golbal variable as the buffer rather than dynamic allocate to
    slove the problem.
    
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Mike Marshall <hubcap@omnibond.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

orangefs: Fix sysfs not cleanup when dev init failed [+ + +]
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Tue Oct 18 12:40:04 2022 +0800

    orangefs: Fix sysfs not cleanup when dev init failed
    
    [ Upstream commit ea60a4ad0cf88b411cde6888b8c890935686ecd7 ]
    
    When the dev init failed, should cleanup the sysfs, otherwise, the
    module will never be loaded since can not create duplicate sysfs
    directory:
    
      sysfs: cannot create duplicate filename '/fs/orangefs'
    
      CPU: 1 PID: 6549 Comm: insmod Tainted: G        W          6.0.0+ #44
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x34/0x44
       sysfs_warn_dup.cold+0x17/0x24
       sysfs_create_dir_ns+0x16d/0x180
       kobject_add_internal+0x156/0x3a0
       kobject_init_and_add+0xcf/0x120
       orangefs_sysfs_init+0x7e/0x3a0 [orangefs]
       orangefs_init+0xfe/0x1000 [orangefs]
       do_one_initcall+0x87/0x2a0
       do_init_module+0xdf/0x320
       load_module+0x2f98/0x3330
       __do_sys_finit_module+0x113/0x1b0
       do_syscall_64+0x35/0x80
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
      kobject_add_internal failed for orangefs with -EEXIST, don't try to register things with the same name in the same directory.
    
    Fixes: 2f83ace37181 ("orangefs: put register_chrdev immediately before register_filesystem")
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Mike Marshall <hubcap@omnibond.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ovl: Use ovl mounter's fsuid and fsgid in ovl_link() [+ + +]
Author: Zhang Tianci <zhangtianci.1997@bytedance.com>
Date:   Thu Sep 1 16:29:29 2022 +0800

    ovl: Use ovl mounter's fsuid and fsgid in ovl_link()
    
    commit 5b0db51215e895a361bc63132caa7cca36a53d6a upstream.
    
    There is a wrong case of link() on overlay:
      $ mkdir /lower /fuse /merge
      $ mount -t fuse /fuse
      $ mkdir /fuse/upper /fuse/work
      $ mount -t overlay /merge -o lowerdir=/lower,upperdir=/fuse/upper,\
        workdir=work
      $ touch /merge/file
      $ chown bin.bin /merge/file // the file's caller becomes "bin"
      $ ln /merge/file /merge/lnkfile
    
    Then we will get an error(EACCES) because fuse daemon checks the link()'s
    caller is "bin", it denied this request.
    
    In the changing history of ovl_link(), there are two key commits:
    
    The first is commit bb0d2b8ad296 ("ovl: fix sgid on directory") which
    overrides the cred's fsuid/fsgid using the new inode. The new inode's
    owner is initialized by inode_init_owner(), and inode->fsuid is
    assigned to the current user. So the override fsuid becomes the
    current user. We know link() is actually modifying the directory, so
    the caller must have the MAY_WRITE permission on the directory. The
    current caller may should have this permission. This is acceptable
    to use the caller's fsuid.
    
    The second is commit 51f7e52dc943 ("ovl: share inode for hard link")
    which removed the inode creation in ovl_link(). This commit move
    inode_init_owner() into ovl_create_object(), so the ovl_link() just
    give the old inode to ovl_create_or_link(). Then the override fsuid
    becomes the old inode's fsuid, neither the caller nor the overlay's
    mounter! So this is incorrect.
    
    Fix this bug by using ovl mounter's fsuid/fsgid to do underlying
    fs's link().
    
    Link: https://lore.kernel.org/all/20220817102952.xnvesg3a7rbv576x@wittgenstein/T
    Link: https://lore.kernel.org/lkml/20220825130552.29587-1-zhangtianci.1997@bytedance.com/t
    Signed-off-by: Zhang Tianci <zhangtianci.1997@bytedance.com>
    Signed-off-by: Jiachen Zhang <zhangjiachen.jaycee@bytedance.com>
    Reviewed-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Fixes: 51f7e52dc943 ("ovl: share inode for hard link")
    Cc: <stable@vger.kernel.org> # v4.8
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
parisc: Align parisc MADV_XXX constants with all other architectures [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Sun Dec 11 19:50:20 2022 +0100

    parisc: Align parisc MADV_XXX constants with all other architectures
    
    commit 71bdea6f798b425bc0003780b13e3fdecb16a010 upstream.
    
    Adjust some MADV_XXX constants to be in sync what their values are on
    all other platforms. There is currently no reason to have an own
    numbering on parisc, but it requires workarounds in many userspace
    sources (e.g. glibc, qemu, ...) - which are often forgotten and thus
    introduce bugs and different behaviour on parisc.
    
    A wrapper avoids an ABI breakage for existing userspace applications by
    translating any old values to the new ones, so this change allows us to
    move over all programs to the new ABI over time.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parisc: led: Fix potential null-ptr-deref in start_task() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Thu Nov 17 10:45:14 2022 +0800

    parisc: led: Fix potential null-ptr-deref in start_task()
    
    commit 41f563ab3c33698bdfc3403c7c2e6c94e73681e4 upstream.
    
    start_task() calls create_singlethread_workqueue() and not checked the
    ret value, which may return NULL. And a null-ptr-deref may happen:
    
    start_task()
        create_singlethread_workqueue() # failed, led_wq is NULL
        queue_delayed_work()
            queue_delayed_work_on()
                __queue_delayed_work()  # warning here, but continue
                    __queue_work()      # access wq->flags, null-ptr-deref
    
    Check the ret value and return -ENOMEM if it is NULL.
    
    Fixes: 3499495205a6 ("[PARISC] Use work queue in LED/LCD driver instead of tasklet.")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pata_ipx4xx_cf: Fix unsigned comparison with less than zero [+ + +]
Author: Junlin Yang <yangjunlin@yulong.com>
Date:   Fri Apr 9 21:54:26 2021 +0800

    pata_ipx4xx_cf: Fix unsigned comparison with less than zero
    
    [ Upstream commit c38ae56ee034623c59e39c0130ca0dec086c1a39 ]
    
    The return from the call to platform_get_irq() is int, it can be
    a negative error code, however this is being assigned to an unsigned
    int variable 'irq', so making 'irq' an int, and change the position to
    keep the code format.
    
    ./drivers/ata/pata_ixp4xx_cf.c:168:5-8:
    WARNING: Unsigned expression compared with zero: irq > 0
    
    Signed-off-by: Junlin Yang <yangjunlin@yulong.com>
    Link: https://lore.kernel.org/r/20210409135426.1773-1-angkery@163.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/sysfs: Fix double free in error path [+ + +]
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date:   Tue Nov 8 17:05:59 2022 -0600

    PCI/sysfs: Fix double free in error path
    
    commit aa382ffa705bea9931ec92b6f3c70e1fdb372195 upstream.
    
    When pci_create_attr() fails, pci_remove_resource_files() is called which
    will iterate over the res_attr[_wc] arrays and frees every non NULL entry.
    To avoid a double free here set the array entry only after it's clear we
    successfully initialized it.
    
    Fixes: b562ec8f74e4 ("PCI: Don't leak memory if sysfs_create_bin_file() fails")
    Link: https://lore.kernel.org/r/20221007070735.GX986@pengutronix.de/
    Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PCI: Check for alloc failure in pci_request_irq() [+ + +]
Author: Zeng Heng <zengheng4@huawei.com>
Date:   Mon Nov 21 10:00:29 2022 +0800

    PCI: Check for alloc failure in pci_request_irq()
    
    [ Upstream commit 2d9cd957d40c3ac491b358e7cff0515bb07a3a9c ]
    
    When kvasprintf() fails to allocate memory, it returns a NULL pointer.
    Return error from pci_request_irq() so we don't dereference it.
    
    [bhelgaas: commit log]
    Fixes: 704e8953d3e9 ("PCI/irq: Add pci_request_irq() and pci_free_irq() helpers")
    Link: https://lore.kernel.org/r/20221121020029.3759444-1-zengheng4@huawei.com
    Signed-off-by: Zeng Heng <zengheng4@huawei.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: Fix pci_device_is_present() for VFs by checking PF [+ + +]
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Wed Oct 26 02:11:21 2022 -0400

    PCI: Fix pci_device_is_present() for VFs by checking PF
    
    commit 98b04dd0b4577894520493d96bc4623387767445 upstream.
    
    pci_device_is_present() previously didn't work for VFs because it reads the
    Vendor and Device ID, which are 0xffff for VFs, which looks like they
    aren't present.  Check the PF instead.
    
    Wei Gong reported that if virtio I/O is in progress when the driver is
    unbound or "0" is written to /sys/.../sriov_numvfs, the virtio I/O
    operation hangs, which may result in output like this:
    
      task:bash state:D stack:    0 pid: 1773 ppid:  1241 flags:0x00004002
      Call Trace:
       schedule+0x4f/0xc0
       blk_mq_freeze_queue_wait+0x69/0xa0
       blk_mq_freeze_queue+0x1b/0x20
       blk_cleanup_queue+0x3d/0xd0
       virtblk_remove+0x3c/0xb0 [virtio_blk]
       virtio_dev_remove+0x4b/0x80
       ...
       device_unregister+0x1b/0x60
       unregister_virtio_device+0x18/0x30
       virtio_pci_remove+0x41/0x80
       pci_device_remove+0x3e/0xb0
    
    This happened because pci_device_is_present(VF) returned "false" in
    virtio_pci_remove(), so it called virtio_break_device().  The broken vq
    meant that vring_interrupt() skipped the vq.callback() that would have
    completed the virtio I/O operation via virtblk_done().
    
    [bhelgaas: commit log, simplify to always use pci_physfn(), add stable tag]
    Link: https://lore.kernel.org/r/20221026060912.173250-1-mst@redhat.com
    Reported-by: Wei Gong <gongwei833x@gmail.com>
    Tested-by: Wei Gong <gongwei833x@gmail.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf auxtrace: Fix address filter duplicate symbol selection [+ + +]
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Jan 10 20:56:59 2023 +0200

    perf auxtrace: Fix address filter duplicate symbol selection
    
    commit cf129830ee820f7fc90b98df193cd49d49344d09 upstream.
    
    When a match has been made to the nth duplicate symbol, return
    success not error.
    
    Example:
    
      Before:
    
        $ cat file.c
        cat: file.c: No such file or directory
        $ cat file1.c
        #include <stdio.h>
    
        static void func(void)
        {
                printf("First func\n");
        }
    
        void other(void);
    
        int main()
        {
                func();
                other();
                return 0;
        }
        $ cat file2.c
        #include <stdio.h>
    
        static void func(void)
        {
                printf("Second func\n");
        }
    
        void other(void)
        {
                func();
        }
    
        $ gcc -Wall -Wextra -o test file1.c file2.c
        $ perf record -e intel_pt//u --filter 'filter func @ ./test' -- ./test
        Multiple symbols with name 'func'
        #1      0x1149  l       func
                        which is near           main
        #2      0x1179  l       func
                        which is near           other
        Disambiguate symbol name by inserting #n after the name e.g. func #2
        Or select a global symbol by inserting #0 or #g or #G
        Failed to parse address filter: 'filter func @ ./test'
        Filter format is: filter|start|stop|tracestop <start symbol or address> [/ <end symbol or size>] [@<file name>]
        Where multiple filters are separated by space or comma.
        $ perf record -e intel_pt//u --filter 'filter func #2 @ ./test' -- ./test
        Failed to parse address filter: 'filter func #2 @ ./test'
        Filter format is: filter|start|stop|tracestop <start symbol or address> [/ <end symbol or size>] [@<file name>]
        Where multiple filters are separated by space or comma.
    
      After:
    
        $ perf record -e intel_pt//u --filter 'filter func #2 @ ./test' -- ./test
        First func
        Second func
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.016 MB perf.data ]
        $ perf script --itrace=b -Ftime,flags,ip,sym,addr --ns
        1231062.526977619:   tr strt                               0 [unknown] =>     558495708179 func
        1231062.526977619:   tr end  call               558495708188 func =>     558495708050 _init
        1231062.526979286:   tr strt                               0 [unknown] =>     55849570818d func
        1231062.526979286:   tr end  return             55849570818f func =>     55849570819d other
    
    Fixes: 1b36c03e356936d6 ("perf record: Add support for using symbols in address filters")
    Reported-by: Dmitrii Dolgov <9erthalion6@gmail.com>
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Tested-by: Dmitry Dolgov <9erthalion6@gmail.com>
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Ian Rogers <irogers@google.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230110185659.15979-1-adrian.hunter@intel.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf probe: Fix to get the DW_AT_decl_file and DW_AT_call_file as unsinged data [+ + +]
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Sat Nov 5 12:01:14 2022 +0900

    perf probe: Fix to get the DW_AT_decl_file and DW_AT_call_file as unsinged data
    
    [ Upstream commit a9dfc46c67b52ad43b8e335e28f4cf8002c67793 ]
    
    DWARF version 5 standard Sec 2.14 says that
    
      Any debugging information entry representing the declaration of an object,
      module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and
      DW_AT_decl_column attributes, each of whose value is an unsigned integer
      constant.
    
    So it should be an unsigned integer data. Also, even though the standard
    doesn't clearly say the DW_AT_call_file is signed or unsigned, the
    elfutils (eu-readelf) interprets it as unsigned integer data and it is
    natural to handle it as unsigned integer data as same as DW_AT_decl_file.
    This changes the DW_AT_call_file as unsigned integer data too.
    
    Fixes: 3f4460a28fb2f73d ("perf probe: Filter out redundant inline-instances")
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Link: https://lore.kernel.org/r/166761727445.480106.3738447577082071942.stgit@devnote3
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf probe: Use dwarf_attr_integrate as generic DWARF attr accessor [+ + +]
Author: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Date:   Tue Nov 1 22:48:39 2022 +0900

    perf probe: Use dwarf_attr_integrate as generic DWARF attr accessor
    
    [ Upstream commit f828929ab7f0dc3353e4a617f94f297fa8f3dec3 ]
    
    Use dwarf_attr_integrate() instead of dwarf_attr() for generic attribute
    acccessor functions, so that it can find the specified attribute from
    abstact origin DIE etc.
    
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Acked-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Link: https://lore.kernel.org/r/166731051988.2100653.13595339994343449770.stgit@devnote3
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: a9dfc46c67b5 ("perf probe: Fix to get the DW_AT_decl_file and DW_AT_call_file as unsinged data")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf symbol: correction while adjusting symbol [+ + +]
Author: Ajay Kaher <akaher@vmware.com>
Date:   Wed Nov 23 15:48:16 2022 +0530

    perf symbol: correction while adjusting symbol
    
    [ Upstream commit 6f520ce17920b3cdfbd2479b3ccf27f9706219d0 ]
    
    perf doesn't provide proper symbol information for specially crafted
    .debug files.
    
    Sometimes .debug file may not have similar program header as runtime
    ELF file. For example if we generate .debug file using objcopy
    --only-keep-debug resulting file will not contain .text, .data and
    other runtime sections. That means corresponding program headers will
    have zero FileSiz and modified Offset.
    
    Example: program header of text section of libxxx.so:
    
    Type           Offset             VirtAddr           PhysAddr
                   FileSiz            MemSiz              Flags  Align
    LOAD        0x00000000003d3000 0x00000000003d3000 0x00000000003d3000
                0x000000000055ae80 0x000000000055ae80  R E    0x1000
    
    Same program header after executing:
    objcopy --only-keep-debug libxxx.so libxxx.so.debug
    
    LOAD        0x0000000000001000 0x00000000003d3000 0x00000000003d3000
                0x0000000000000000 0x000000000055ae80  R E    0x1000
    
    Offset and FileSiz have been changed.
    
    Following formula will not provide correct value, if program header
    taken from .debug file (syms_ss):
    
        sym.st_value -= phdr.p_vaddr - phdr.p_offset;
    
    Correct program header information is located inside runtime ELF
    file (runtime_ss).
    
    Fixes: 2d86612aacb7805f ("perf symbol: Correct address for bss symbols")
    Signed-off-by: Ajay Kaher <akaher@vmware.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Alexey Makhalov <amakhalov@vmware.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Leo Yan <leo.yan@linaro.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Srivatsa S. Bhat <srivatsab@vmware.com>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Vasavi Sirnapalli <vsirnapalli@vmware.com>
    Link: http://lore.kernel.org/lkml/1669198696-50547-1-git-send-email-akaher@vmware.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf tools: Fix resources leak in perf_data__open_dir() [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Thu Dec 29 13:09:00 2022 +0400

    perf tools: Fix resources leak in perf_data__open_dir()
    
    [ Upstream commit 0a6564ebd953c4590663c9a3c99a3ea9920ade6f ]
    
    In perf_data__open_dir(), opendir() opens the directory stream.  Add
    missing closedir() to release it after use.
    
    Fixes: eb6176709b235b96 ("perf data: Add perf_data__open_dir_data function")
    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Alexey Bayduraev <alexey.v.bayduraev@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20221229090903.1402395-1-linmq006@gmail.com
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf trace: Add a strtoul() method to 'struct syscall_arg_fmt' [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Wed Oct 9 16:06:43 2019 -0300

    perf trace: Add a strtoul() method to 'struct syscall_arg_fmt'
    
    [ Upstream commit 3f41b77843b338e836f52cc2d486be689d6cb9c1 ]
    
    This will go from a string to a number, so that filter expressions can
    be constructed with strings and then, before applying the tracepoint
    filters (or eBPF, in the future) we can map those strings to numbers.
    
    The first one will be for 'msr' tracepoint arguments, but real quickly
    we will be able to reuse all strarrays for that.
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Luis Cláudio Gonçalves <lclaudio@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lkml.kernel.org/n/tip-wgqq48agcgr95b8dmn6fygtr@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 03e9a5d8eb55 ("perf trace: Handle failure when trace point folder is missed")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf trace: Add the syscall_arg_fmt pointer to syscall_arg [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Fri Oct 4 14:52:30 2019 -0300

    perf trace: Add the syscall_arg_fmt pointer to syscall_arg
    
    [ Upstream commit 888ca854e275fcfbb13206d32bb01c0576fc5546 ]
    
    So that the scnprintf beautifiers can access it, as will be the case
    with the char array one in the following csets, that needs to know
    the number of elements in an array.
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Luis Cláudio Gonçalves <lclaudio@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lkml.kernel.org/n/tip-01qmjqv6cb1nj1qy4khdexce@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 03e9a5d8eb55 ("perf trace: Handle failure when trace point folder is missed")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf trace: Allow associating scnprintf routines with well known arg names [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Mon Oct 7 15:50:15 2019 -0300

    perf trace: Allow associating scnprintf routines with well known arg names
    
    [ Upstream commit 5d88099bc00dccddf5da18e25e1223f01644f7a2 ]
    
    For instance 'msr' appears in several tracepoints, so we can associate
    it with a single scnprintf() routine auto-generated from kernel headers,
    as will be done in followup patches.
    
    Start with an empty array of associations.
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lkml.kernel.org/n/tip-89ptht6s5fez82lykuwq1eyb@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 03e9a5d8eb55 ("perf trace: Handle failure when trace point folder is missed")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf trace: Factor out the initialization of syscal_arg_fmt->scnprintf [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Thu Oct 3 15:57:42 2019 -0300

    perf trace: Factor out the initialization of syscal_arg_fmt->scnprintf
    
    [ Upstream commit 8d1d4ff5e239d9ef385444bc0d855127d7b32754 ]
    
    We set the default scnprint routines for the syscall args based on its
    type or on heuristics based on its names, now we'll use this for
    tracepoints as well, so move it out of syscall__set_arg_fmts() and into
    a routine that receive just an array of syscall_arg_fmt entries + the
    tracepoint format fields list.
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Luis Cláudio Gonçalves <lclaudio@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lkml.kernel.org/n/tip-xs3x0zzyes06c7scdsjn01ty@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 03e9a5d8eb55 ("perf trace: Handle failure when trace point folder is missed")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf trace: Handle failure when trace point folder is missed [+ + +]
Author: Leo Yan <leo.yan@linaro.org>
Date:   Mon Nov 21 07:52:35 2022 +0000

    perf trace: Handle failure when trace point folder is missed
    
    [ Upstream commit 03e9a5d8eb552a1bf692a9c8a5ecd50f4e428006 ]
    
    On Arm64 a case is perf tools fails to find the corresponding trace
    point folder for system calls listed in the table 'syscalltbl_arm64',
    e.g. the generated system call table contains "lookup_dcookie" but we
    cannot find out the matched trace point folder for it.
    
    We need to figure out if there have any issue for the generated system
    call table, on the other hand, we need to handle the case when trace
    point folder is missed under sysfs, this patch sets the flag
    syscall::nonexistent as true and returns the error from
    trace__read_syscall_info().
    
    Another problem is for trace__syscall_info(), it returns two different
    values if a system call doesn't exist: at the first time calling
    trace__syscall_info() it returns NULL when the system call doesn't exist,
    later if call trace__syscall_info() again for the same missed system
    call, it returns pointer of syscall.  trace__syscall_info() checks the
    condition 'syscalls.table[id].name == NULL', but the name will be
    assigned in the first invoking even the system call is not found.
    
    So checking system call's name in trace__syscall_info() is not the right
    thing to do, this patch simply checks flag syscall::nonexistent to make
    decision if a system call exists or not, finally trace__syscall_info()
    returns the consistent result (NULL) if a system call doesn't existed.
    
    Fixes: b8b1033fcaa091d8 ("perf trace: Mark syscall ids that are not allocated to avoid unnecessary error messages")
    Signed-off-by: Leo Yan <leo.yan@linaro.org>
    Acked-by: Ian Rogers <irogers@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: bpf@vger.kernel.org
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20221121075237.127706-4-leo.yan@linaro.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf trace: Return error if a system call doesn't exist [+ + +]
Author: Leo Yan <leo.yan@linaro.org>
Date:   Mon Nov 21 07:52:34 2022 +0000

    perf trace: Return error if a system call doesn't exist
    
    [ Upstream commit d4223e1776c30b2ce8d0e6eaadcbf696e60fca3c ]
    
    When a system call is not detected, the reason is either because the
    system call ID is out of scope or failure to find the corresponding path
    in the sysfs, trace__read_syscall_info() returns zero.  Finally, without
    returning an error value it introduces confusion for the caller.
    
    This patch lets the function trace__read_syscall_info() to return
    -EEXIST when a system call doesn't exist.
    
    Fixes: b8b1033fcaa091d8 ("perf trace: Mark syscall ids that are not allocated to avoid unnecessary error messages")
    Signed-off-by: Leo Yan <leo.yan@linaro.org>
    Acked-by: Ian Rogers <irogers@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: bpf@vger.kernel.org
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lore.kernel.org/r/20221121075237.127706-3-leo.yan@linaro.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf trace: Separate 'struct syscall_fmt' definition from syscall_fmts variable [+ + +]
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Tue Oct 1 15:16:33 2019 -0300

    perf trace: Separate 'struct syscall_fmt' definition from syscall_fmts variable
    
    [ Upstream commit 9b2036cd329924082acfa5dec58deec12fa1f5e8 ]
    
    As this has all the things needed to format tracepoints events, not just
    syscalls, that, after all, are just tracepoints with a set in stone ABI,
    i.e. order and number of parameters.
    
    For tracepoints we'll create a
    
      static struct syscall_fmt tracepoint_fmts[]
    
    array and will fill the ->arg[] entries with the beautifier for each
    positional argument and record the name, then, when we need it, we'll
    just check that the position has the same name, maybe even type, so that
    we can do some check that the tracepoint hasn't changed, if it has, we
    can even reorder things.
    
    Keep calling it syscall_fmt but use it as well for tracepoints, do it
    this way to minimize changes and reuse what is in place for syscalls,
    we'll see.
    
    Cc: Adrian Hunter <adrian.hunter@intel.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Luis Cláudio Gonçalves <lclaudio@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Link: https://lkml.kernel.org/n/tip-2x1jgiev13zt4njaanlnne0d@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 03e9a5d8eb55 ("perf trace: Handle failure when trace point folder is missed")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf trace: Use macro RAW_SYSCALL_ARGS_NUM to replace number [+ + +]
Author: Leo Yan <leo.yan@linaro.org>
Date:   Mon Nov 21 07:52:33 2022 +0000

    perf trace: Use macro RAW_SYSCALL_ARGS_NUM to replace number
    
    [ Upstream commit eadcab4c7a66e1df03d32da0db55d89fd9343fcc ]
    
    This patch defines a macro RAW_SYSCALL_ARGS_NUM to replace the open
    coded number '6'.
    
    Signed-off-by: Leo Yan <leo.yan@linaro.org>
    Acked-by: Ian Rogers <irogers@google.com>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jiri Olsa <jolsa@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: bpf@vger.kernel.org
    Link: https://lore.kernel.org/r/20221121075237.127706-2-leo.yan@linaro.org
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Stable-dep-of: 03e9a5d8eb55 ("perf trace: Handle failure when trace point folder is missed")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Tue Nov 15 19:55:40 2022 +0800

    perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init()
    
    [ Upstream commit 6f2d566b46436a50a80d6445e82879686b89588c ]
    
    arm_smmu_pmu_init() won't remove the callback added by
    cpuhp_setup_state_multi() when platform_driver_register() failed. Remove
    the callback by cpuhp_remove_multi_state() in fail path.
    
    Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:
    arm-ccn: Prevent hotplug callback leak")
    
    Fixes: 7d839b4b9e00 ("perf/smmuv3: Add arm64 smmuv3 pmu driver")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
    Link: https://lore.kernel.org/r/20221115115540.6245-3-shangxiaojing@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox() [+ + +]
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Fri Nov 18 14:31:35 2022 +0800

    perf/x86/intel/uncore: Fix reference count leak in hswep_has_limit_sbox()
    
    [ Upstream commit 1ff9dd6e7071a561f803135c1d684b13c7a7d01d ]
    
    pci_get_device() will increase the reference count for the returned
    'dev'. We need to call pci_dev_put() to decrease the reference count.
    Since 'dev' is only used in pci_read_config_dword(), let's add
    pci_dev_put() right after it.
    
    Fixes: 9d480158ee86 ("perf/x86/intel/uncore: Remove uncore extra PCI dev HSWEP_PCI_PCU_3")
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Link: https://lore.kernel.org/r/20221118063137.121512-3-wangxiongfeng2@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf: arm_dsu: Fix hotplug callback leak in dsu_pmu_init() [+ + +]
Author: Yuan Can <yuancan@huawei.com>
Date:   Tue Nov 15 07:02:06 2022 +0000

    perf: arm_dsu: Fix hotplug callback leak in dsu_pmu_init()
    
    [ Upstream commit facafab7611f7b872c6b9eeaff53461ef11f482e ]
    
    dsu_pmu_init() won't remove the callback added by cpuhp_setup_state_multi()
    when platform_driver_register() failed. Remove the callback by
    cpuhp_remove_multi_state() in fail path.
    
    Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:
    arm-ccn: Prevent hotplug callback leak")
    
    Fixes: 7520fa99246d ("perf: ARM DynamIQ Shared Unit PMU support")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com>
    Link: https://lore.kernel.org/r/20221115070207.32634-2-yuancan@huawei.com
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

perf: Fix possible memleak in pmu_dev_alloc() [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Fri Nov 11 18:36:53 2022 +0800

    perf: Fix possible memleak in pmu_dev_alloc()
    
    [ Upstream commit e8d7a90c08ce963c592fb49845f2ccc606a2ac21 ]
    
    In pmu_dev_alloc(), when dev_set_name() failed, it will goto free_dev
    and call put_device(pmu->dev) to release it.
    However pmu->dev->release is assigned after this, which makes warning
    and memleak.
    Call dev_set_name() after pmu->dev->release = pmu_dev_release to fix it.
    
      Device '(null)' does not have a release() function...
      WARNING: CPU: 2 PID: 441 at drivers/base/core.c:2332 device_release+0x1b9/0x240
      ...
      Call Trace:
        <TASK>
        kobject_put+0x17f/0x460
        put_device+0x20/0x30
        pmu_dev_alloc+0x152/0x400
        perf_pmu_register+0x96b/0xee0
        ...
      kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
      unreferenced object 0xffff888014759000 (size 2048):
        comm "modprobe", pid 441, jiffies 4294931444 (age 38.332s)
        backtrace:
          [<0000000005aed3b4>] kmalloc_trace+0x27/0x110
          [<000000006b38f9b8>] pmu_dev_alloc+0x50/0x400
          [<00000000735f17be>] perf_pmu_register+0x96b/0xee0
          [<00000000e38477f1>] 0xffffffffc0ad8603
          [<000000004e162216>] do_one_initcall+0xd0/0x4e0
          ...
    
    Fixes: abe43400579d ("perf: Sysfs enumeration")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20221111103653.91058-1-chenzhongjin@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: pinconf-generic: add missing of_node_put() [+ + +]
Author: ZhangPeng <zhangpeng362@huawei.com>
Date:   Fri Nov 25 07:01:56 2022 +0000

    pinctrl: pinconf-generic: add missing of_node_put()
    
    [ Upstream commit 5ead93289815a075d43c415e35c8beafafb801c9 ]
    
    of_node_put() needs to be called when jumping out of the loop, since
    for_each_available_child_of_node() will increase the refcount of node.
    
    Fixes: c7289500e29d ("pinctrl: pinconf-generic: scan also referenced phandle node")
    Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
    Link: https://lore.kernel.org/r/20221125070156.3535855-1-zhangpeng362@huawei.com
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]() [+ + +]
Author: Yu Liao <liaoyu15@huawei.com>
Date:   Tue Nov 29 09:11:01 2022 +0800

    platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]()
    
    [ Upstream commit 727cc0147f5066e359aca65cc6cc5e6d64cc15d8 ]
    
    The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method()
    is not freed after the call, so it leads to memory leak.
    
    The method results in ACPI buffer is not used, so just pass NULL to
    wmi_evaluate_method() which fixes the memory leak.
    
    Fixes: 99b38b4acc0d ("platform/x86: add MXM WMI driver.")
    Signed-off-by: Yu Liao <liaoyu15@huawei.com>
    Link: https://lore.kernel.org/r/20221129011101.2042315-1-liaoyu15@huawei.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

platform/x86: sony-laptop: Don't turn off 0x153 keyboard backlight during probe [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Tue Dec 13 13:29:43 2022 +0100

    platform/x86: sony-laptop: Don't turn off 0x153 keyboard backlight during probe
    
    commit ad75bd85b1db69c97eefea07b375567821f6ef58 upstream.
    
    The 0x153 version of the kbd backlight control SNC handle has no separate
    address to probe if the backlight is there.
    
    This turns the probe call into a set keyboard backlight call with a value
    of 0 turning off the keyboard backlight.
    
    Skip probing when there is no separate probe address to avoid this.
    
    Link: https://bugzilla.redhat.com/show_bug.cgi?id=1583752
    Fixes: 800f20170dcf ("Keyboard backlight control for some Vaio Fit models")
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Mattia Dongili <malattia@linux.it>
    Link: https://lore.kernel.org/r/20221213122943.11123-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PM/devfreq: governor: Add a private governor_data for governor [+ + +]
Author: Kant Fan <kant@allwinnertech.com>
Date:   Tue Oct 25 15:21:09 2022 +0800

    PM/devfreq: governor: Add a private governor_data for governor
    
    [ Upstream commit 5fdded8448924e3631d466eea499b11606c43640 ]
    
    The member void *data in the structure devfreq can be overwrite
    by governor_userspace. For example:
    1. The device driver assigned the devfreq governor to simple_ondemand
    by the function devfreq_add_device() and init the devfreq member
    void *data to a pointer of a static structure devfreq_simple_ondemand_data
    by the function devfreq_add_device().
    2. The user changed the devfreq governor to userspace by the command
    "echo userspace > /sys/class/devfreq/.../governor".
    3. The governor userspace alloced a dynamic memory for the struct
    userspace_data and assigend the member void *data of devfreq to
    this memory by the function userspace_init().
    4. The user changed the devfreq governor back to simple_ondemand
    by the command "echo simple_ondemand > /sys/class/devfreq/.../governor".
    5. The governor userspace exited and assigned the member void *data
    in the structure devfreq to NULL by the function userspace_exit().
    6. The governor simple_ondemand fetched the static information of
    devfreq_simple_ondemand_data in the function
    devfreq_simple_ondemand_func() but the member void *data of devfreq was
    assigned to NULL by the function userspace_exit().
    7. The information of upthreshold and downdifferential is lost
    and the governor simple_ondemand can't work correctly.
    
    The member void *data in the structure devfreq is designed for
    a static pointer used in a governor and inited by the function
    devfreq_add_device(). This patch add an element named governor_data
    in the devfreq structure which can be used by a governor(E.g userspace)
    who want to assign a private data to do some private things.
    
    Fixes: ce26c5bb9569 ("PM / devfreq: Add basic governors")
    Cc: stable@vger.kernel.org # 5.10+
    Reviewed-by: Chanwoo Choi <cwchoi00@gmail.com>
    Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
    Signed-off-by: Kant Fan <kant@allwinnertech.com>
    Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PM: hibernate: Fix mistake in kerneldoc comment [+ + +]
Author: xiongxin <xiongxin@kylinos.cn>
Date:   Tue Nov 1 10:28:39 2022 +0800

    PM: hibernate: Fix mistake in kerneldoc comment
    
    [ Upstream commit 6e5d7300cbe7c3541bc31f16db3e9266e6027b4b ]
    
    The actual maximum image size formula in hibernate_preallocate_memory()
    is as follows:
    
    max_size = (count - (size + PAGES_FOR_IO)) / 2
                - 2 * DIV_ROUND_UP(reserved_size, PAGE_SIZE);
    
    but the one in the kerneldoc comment of the function is different and
    incorrect.
    
    Fixes: ddeb64870810 ("PM / Hibernate: Add sysfs knob to control size of memory for drivers")
    Signed-off-by: xiongxin <xiongxin@kylinos.cn>
    [ rjw: Subject and changelog rewrite ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PM: runtime: Do not call __rpm_callback() from rpm_idle() [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Fri Dec 2 15:30:28 2022 +0100

    PM: runtime: Do not call __rpm_callback() from rpm_idle()
    
    [ Upstream commit bc80c2e438dcbfcf748452ec0f7ad5b79ff3ad88 ]
    
    Calling __rpm_callback() from rpm_idle() after adding device links
    support to the former is a clear mistake.
    
    Not only it causes rpm_idle() to carry out unnecessary actions, but it
    is also against the assumption regarding the stability of PM-runtime
    status across __rpm_callback() invocations, because rpm_suspend() and
    rpm_resume() may run in parallel with __rpm_callback() when it is called
    by rpm_idle() and the device's PM-runtime status can be updated by any
    of them.
    
    Fixes: 21d5c57b3726 ("PM / runtime: Use device links")
    Link: https://lore.kernel.org/linux-pm/36aed941-a73e-d937-2721-4f0decd61ce0@quicinc.com
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PM: runtime: Improve path in rpm_idle() when no callback [+ + +]
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Tue Jun 8 11:02:48 2021 +0200

    PM: runtime: Improve path in rpm_idle() when no callback
    
    [ Upstream commit 5a2bd1b1c64e1ac5627db3767ac465f18606315c ]
    
    When pm_runtime_no_callbacks() has been called for a struct device to set
    the dev->power.no_callbacks flag for it, it enables rpm_idle() to take a
    slightly quicker path by assuming that a ->runtime_idle() callback would
    have returned 0 to indicate success.
    
    A device that does not have the dev->power.no_callbacks flag set for it,
    may still be missing a corresponding ->runtime_idle() callback, in which
    case the slower path in rpm_idle() is taken. Let's improve the behaviour
    for this case, by aligning code to the quicker path.
    
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Stable-dep-of: bc80c2e438dc ("PM: runtime: Do not call __rpm_callback() from rpm_idle()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pnode: terminate at peers of source [+ + +]
Author: Christian Brauner <brauner@kernel.org>
Date:   Sat Dec 17 22:28:40 2022 +0100

    pnode: terminate at peers of source
    
    commit 11933cf1d91d57da9e5c53822a540bbdc2656c16 upstream.
    
    The propagate_mnt() function handles mount propagation when creating
    mounts and propagates the source mount tree @source_mnt to all
    applicable nodes of the destination propagation mount tree headed by
    @dest_mnt.
    
    Unfortunately it contains a bug where it fails to terminate at peers of
    @source_mnt when looking up copies of the source mount that become
    masters for copies of the source mount tree mounted on top of slaves in
    the destination propagation tree causing a NULL dereference.
    
    Once the mechanics of the bug are understood it's easy to trigger.
    Because of unprivileged user namespaces it is available to unprivileged
    users.
    
    While fixing this bug we've gotten confused multiple times due to
    unclear terminology or missing concepts. So let's start this with some
    clarifications:
    
    * The terms "master" or "peer" denote a shared mount. A shared mount
      belongs to a peer group.
    
    * A peer group is a set of shared mounts that propagate to each other.
      They are identified by a peer group id. The peer group id is available
      in @shared_mnt->mnt_group_id.
      Shared mounts within the same peer group have the same peer group id.
      The peers in a peer group can be reached via @shared_mnt->mnt_share.
    
    * The terms "slave mount" or "dependent mount" denote a mount that
      receives propagation from a peer in a peer group. IOW, shared mounts
      may have slave mounts and slave mounts have shared mounts as their
      master. Slave mounts of a given peer in a peer group are listed on
      that peers slave list available at @shared_mnt->mnt_slave_list.
    
    * The term "master mount" denotes a mount in a peer group. IOW, it
      denotes a shared mount or a peer mount in a peer group. The term
      "master mount" - or "master" for short - is mostly used when talking
      in the context of slave mounts that receive propagation from a master
      mount. A master mount of a slave identifies the closest peer group a
      slave mount receives propagation from. The master mount of a slave can
      be identified via @slave_mount->mnt_master. Different slaves may point
      to different masters in the same peer group.
    
    * Multiple peers in a peer group can have non-empty ->mnt_slave_lists.
      Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to
      ensure all slave mounts of a peer group are visited the
      ->mnt_slave_lists of all peers in a peer group have to be walked.
    
    * Slave mounts point to a peer in the closest peer group they receive
      propagation from via @slave_mnt->mnt_master (see above). Together with
      these peers they form a propagation group (see below). The closest
      peer group can thus be identified through the peer group id
      @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave
      mount receives propagation from.
    
    * A shared-slave mount is a slave mount to a peer group pg1 while also
      a peer in another peer group pg2. IOW, a peer group may receive
      propagation from another peer group.
    
      If a peer group pg1 is a slave to another peer group pg2 then all
      peers in peer group pg1 point to the same peer in peer group pg2 via
      ->mnt_master. IOW, all peers in peer group pg1 appear on the same
      ->mnt_slave_list. IOW, they cannot be slaves to different peer groups.
    
    * A pure slave mount is a slave mount that is a slave to a peer group
      but is not a peer in another peer group.
    
    * A propagation group denotes the set of mounts consisting of a single
      peer group pg1 and all slave mounts and shared-slave mounts that point
      to a peer in that peer group via ->mnt_master. IOW, all slave mounts
      such that @slave_mnt->mnt_master->mnt_group_id is equal to
      @shared_mnt->mnt_group_id.
    
      The concept of a propagation group makes it easier to talk about a
      single propagation level in a propagation tree.
    
      For example, in propagate_mnt() the immediate peers of @dest_mnt and
      all slaves of @dest_mnt's peer group form a propagation group propg1.
      So a shared-slave mount that is a slave in propg1 and that is a peer
      in another peer group pg2 forms another propagation group propg2
      together with all slaves that point to that shared-slave mount in
      their ->mnt_master.
    
    * A propagation tree refers to all mounts that receive propagation
      starting from a specific shared mount.
    
      For example, for propagate_mnt() @dest_mnt is the start of a
      propagation tree. The propagation tree ecompasses all mounts that
      receive propagation from @dest_mnt's peer group down to the leafs.
    
    With that out of the way let's get to the actual algorithm.
    
    We know that @dest_mnt is guaranteed to be a pure shared mount or a
    shared-slave mount. This is guaranteed by a check in
    attach_recursive_mnt(). So propagate_mnt() will first propagate the
    source mount tree to all peers in @dest_mnt's peer group:
    
    for (n = next_peer(dest_mnt); n != dest_mnt; n = next_peer(n)) {
            ret = propagate_one(n);
            if (ret)
                   goto out;
    }
    
    Notice, that the peer propagation loop of propagate_mnt() doesn't
    propagate @dest_mnt itself. @dest_mnt is mounted directly in
    attach_recursive_mnt() after we propagated to the destination
    propagation tree.
    
    The mount that will be mounted on top of @dest_mnt is @source_mnt. This
    copy was created earlier even before we entered attach_recursive_mnt()
    and doesn't concern us a lot here.
    
    It's just important to notice that when propagate_mnt() is called
    @source_mnt will not yet have been mounted on top of @dest_mnt. Thus,
    @source_mnt->mnt_parent will either still point to @source_mnt or - in
    the case @source_mnt is moved and thus already attached - still to its
    former parent.
    
    For each peer @m in @dest_mnt's peer group propagate_one() will create a
    new copy of the source mount tree and mount that copy @child on @m such
    that @child->mnt_parent points to @m after propagate_one() returns.
    
    propagate_one() will stash the last destination propagation node @m in
    @last_dest and the last copy it created for the source mount tree in
    @last_source.
    
    Hence, if we call into propagate_one() again for the next destination
    propagation node @m, @last_dest will point to the previous destination
    propagation node and @last_source will point to the previous copy of the
    source mount tree and mounted on @last_dest.
    
    Each new copy of the source mount tree is created from the previous copy
    of the source mount tree. This will become important later.
    
    The peer loop in propagate_mnt() is straightforward. We iterate through
    the peers copying and updating @last_source and @last_dest as we go
    through them and mount each copy of the source mount tree @child on a
    peer @m in @dest_mnt's peer group.
    
    After propagate_mnt() handled the peers in @dest_mnt's peer group
    propagate_mnt() will propagate the source mount tree down the
    propagation tree that @dest_mnt's peer group propagates to:
    
    for (m = next_group(dest_mnt, dest_mnt); m;
                    m = next_group(m, dest_mnt)) {
            /* everything in that slave group */
            n = m;
            do {
                    ret = propagate_one(n);
                    if (ret)
                            goto out;
                    n = next_peer(n);
            } while (n != m);
    }
    
    The next_group() helper will recursively walk the destination
    propagation tree, descending into each propagation group of the
    propagation tree.
    
    The important part is that it takes care to propagate the source mount
    tree to all peers in the peer group of a propagation group before it
    propagates to the slaves to those peers in the propagation group. IOW,
    it creates and mounts copies of the source mount tree that become
    masters before it creates and mounts copies of the source mount tree
    that become slaves to these masters.
    
    It is important to remember that propagating the source mount tree to
    each mount @m in the destination propagation tree simply means that we
    create and mount new copies @child of the source mount tree on @m such
    that @child->mnt_parent points to @m.
    
    Since we know that each node @m in the destination propagation tree
    headed by @dest_mnt's peer group will be overmounted with a copy of the
    source mount tree and since we know that the propagation properties of
    each copy of the source mount tree we create and mount at @m will mostly
    mirror the propagation properties of @m. We can use that information to
    create and mount the copies of the source mount tree that become masters
    before their slaves.
    
    The easy case is always when @m and @last_dest are peers in a peer group
    of a given propagation group. In that case we know that we can simply
    copy @last_source without having to figure out what the master for the
    new copy @child of the source mount tree needs to be as we've done that
    in a previous call to propagate_one().
    
    The hard case is when we're dealing with a slave mount or a shared-slave
    mount @m in a destination propagation group that we need to create and
    mount a copy of the source mount tree on.
    
    For each propagation group in the destination propagation tree we
    propagate the source mount tree to we want to make sure that the copies
    @child of the source mount tree we create and mount on slaves @m pick an
    ealier copy of the source mount tree that we mounted on a master @m of
    the destination propagation group as their master. This is a mouthful
    but as far as we can tell that's the core of it all.
    
    But, if we keep track of the masters in the destination propagation tree
    @m we can use the information to find the correct master for each copy
    of the source mount tree we create and mount at the slaves in the
    destination propagation tree @m.
    
    Let's walk through the base case as that's still fairly easy to grasp.
    
    If we're dealing with the first slave in the propagation group that
    @dest_mnt is in then we don't yet have marked any masters in the
    destination propagation tree.
    
    We know the master for the first slave to @dest_mnt's peer group is
    simple @dest_mnt. So we expect this algorithm to yield a copy of the
    source mount tree that was mounted on a peer in @dest_mnt's peer group
    as the master for the copy of the source mount tree we want to mount at
    the first slave @m:
    
    for (n = m; ; n = p) {
            p = n->mnt_master;
            if (p == dest_master || IS_MNT_MARKED(p))
                    break;
    }
    
    For the first slave we walk the destination propagation tree all the way
    up to a peer in @dest_mnt's peer group. IOW, the propagation hierarchy
    can be walked by walking up the @mnt->mnt_master hierarchy of the
    destination propagation tree @m. We will ultimately find a peer in
    @dest_mnt's peer group and thus ultimately @dest_mnt->mnt_master.
    
    Btw, here the assumption we listed at the beginning becomes important.
    Namely, that peers in a peer group pg1 that are slaves in another peer
    group pg2 appear on the same ->mnt_slave_list. IOW, all slaves who are
    peers in peer group pg1 point to the same peer in peer group pg2 via
    their ->mnt_master. Otherwise the termination condition in the code
    above would be wrong and next_group() would be broken too.
    
    So the first iteration sets:
    
    n = m;
    p = n->mnt_master;
    
    such that @p now points to a peer or @dest_mnt itself. We walk up one
    more level since we don't have any marked mounts. So we end up with:
    
    n = dest_mnt;
    p = dest_mnt->mnt_master;
    
    If @dest_mnt's peer group is not slave to another peer group then @p is
    now NULL. If @dest_mnt's peer group is a slave to another peer group
    then @p now points to @dest_mnt->mnt_master points which is a master
    outside the propagation tree we're dealing with.
    
    Now we need to figure out the master for the copy of the source mount
    tree we're about to create and mount on the first slave of @dest_mnt's
    peer group:
    
    do {
            struct mount *parent = last_source->mnt_parent;
            if (last_source == first_source)
                    break;
            done = parent->mnt_master == p;
            if (done && peers(n, parent))
                    break;
            last_source = last_source->mnt_master;
    } while (!done);
    
    We know that @last_source->mnt_parent points to @last_dest and
    @last_dest is the last peer in @dest_mnt's peer group we propagated to
    in the peer loop in propagate_mnt().
    
    Consequently, @last_source is the last copy we created and mount on that
    last peer in @dest_mnt's peer group. So @last_source is the master we
    want to pick.
    
    We know that @last_source->mnt_parent->mnt_master points to
    @last_dest->mnt_master. We also know that @last_dest->mnt_master is
    either NULL or points to a master outside of the destination propagation
    tree and so does @p. Hence:
    
    done = parent->mnt_master == p;
    
    is trivially true in the base condition.
    
    We also know that for the first slave mount of @dest_mnt's peer group
    that @last_dest either points @dest_mnt itself because it was
    initialized to:
    
    last_dest = dest_mnt;
    
    at the beginning of propagate_mnt() or it will point to a peer of
    @dest_mnt in its peer group. In both cases it is guaranteed that on the
    first iteration @n and @parent are peers (Please note the check for
    peers here as that's important.):
    
    if (done && peers(n, parent))
            break;
    
    So, as we expected, we select @last_source, which referes to the last
    copy of the source mount tree we mounted on the last peer in @dest_mnt's
    peer group, as the master of the first slave in @dest_mnt's peer group.
    The rest is taken care of by clone_mnt(last_source, ...). We'll skip
    over that part otherwise this becomes a blogpost.
    
    At the end of propagate_mnt() we now mark @m->mnt_master as the first
    master in the destination propagation tree that is distinct from
    @dest_mnt->mnt_master. IOW, we mark @dest_mnt itself as a master.
    
    By marking @dest_mnt or one of it's peers we are able to easily find it
    again when we later lookup masters for other copies of the source mount
    tree we mount copies of the source mount tree on slaves @m to
    @dest_mnt's peer group. This, in turn allows us to find the master we
    selected for the copies of the source mount tree we mounted on master in
    the destination propagation tree again.
    
    The important part is to realize that the code makes use of the fact
    that the last copy of the source mount tree stashed in @last_source was
    mounted on top of the previous destination propagation node @last_dest.
    What this means is that @last_source allows us to walk the destination
    propagation hierarchy the same way each destination propagation node @m
    does.
    
    If we take @last_source, which is the copy of @source_mnt we have
    mounted on @last_dest in the previous iteration of propagate_one(), then
    we know @last_source->mnt_parent points to @last_dest but we also know
    that as we walk through the destination propagation tree that
    @last_source->mnt_master will point to an earlier copy of the source
    mount tree we mounted one an earlier destination propagation node @m.
    
    IOW, @last_source->mnt_parent will be our hook into the destination
    propagation tree and each consecutive @last_source->mnt_master will lead
    us to an earlier propagation node @m via
    @last_source->mnt_master->mnt_parent.
    
    Hence, by walking up @last_source->mnt_master, each of which is mounted
    on a node that is a master @m in the destination propagation tree we can
    also walk up the destination propagation hierarchy.
    
    So, for each new destination propagation node @m we use the previous
    copy of @last_source and the fact it's mounted on the previous
    propagation node @last_dest via @last_source->mnt_master->mnt_parent to
    determine what the master of the new copy of @last_source needs to be.
    
    The goal is to find the _closest_ master that the new copy of the source
    mount tree we are about to create and mount on a slave @m in the
    destination propagation tree needs to pick. IOW, we want to find a
    suitable master in the propagation group.
    
    As the propagation structure of the source mount propagation tree we
    create mirrors the propagation structure of the destination propagation
    tree we can find @m's closest master - i.e., a marked master - which is
    a peer in the closest peer group that @m receives propagation from. We
    store that closest master of @m in @p as before and record the slave to
    that master in @n
    
    We then search for this master @p via @last_source by walking up the
    master hierarchy starting from the last copy of the source mount tree
    stored in @last_source that we created and mounted on the previous
    destination propagation node @m.
    
    We will try to find the master by walking @last_source->mnt_master and
    by comparing @last_source->mnt_master->mnt_parent->mnt_master to @p. If
    we find @p then we can figure out what earlier copy of the source mount
    tree needs to be the master for the new copy of the source mount tree
    we're about to create and mount at the current destination propagation
    node @m.
    
    If @last_source->mnt_master->mnt_parent and @n are peers then we know
    that the closest master they receive propagation from is
    @last_source->mnt_master->mnt_parent->mnt_master. If not then the
    closest immediate peer group that they receive propagation from must be
    one level higher up.
    
    This builds on the earlier clarification at the beginning that all peers
    in a peer group which are slaves of other peer groups all point to the
    same ->mnt_master, i.e., appear on the same ->mnt_slave_list, of the
    closest peer group that they receive propagation from.
    
    However, terminating the walk has corner cases.
    
    If the closest marked master for a given destination node @m cannot be
    found by walking up the master hierarchy via @last_source->mnt_master
    then we need to terminate the walk when we encounter @source_mnt again.
    
    This isn't an arbitrary termination. It simply means that the new copy
    of the source mount tree we're about to create has a copy of the source
    mount tree we created and mounted on a peer in @dest_mnt's peer group as
    its master. IOW, @source_mnt is the peer in the closest peer group that
    the new copy of the source mount tree receives propagation from.
    
    We absolutely have to stop @source_mnt because @last_source->mnt_master
    either points outside the propagation hierarchy we're dealing with or it
    is NULL because @source_mnt isn't a shared-slave.
    
    So continuing the walk past @source_mnt would cause a NULL dereference
    via @last_source->mnt_master->mnt_parent. And so we have to stop the
    walk when we encounter @source_mnt again.
    
    One scenario where this can happen is when we first handled a series of
    slaves of @dest_mnt's peer group and then encounter peers in a new peer
    group that is a slave to @dest_mnt's peer group. We handle them and then
    we encounter another slave mount to @dest_mnt that is a pure slave to
    @dest_mnt's peer group. That pure slave will have a peer in @dest_mnt's
    peer group as its master. Consequently, the new copy of the source mount
    tree will need to have @source_mnt as it's master. So we walk the
    propagation hierarchy all the way up to @source_mnt based on
    @last_source->mnt_master.
    
    So terminate on @source_mnt, easy peasy. Except, that the check misses
    something that the rest of the algorithm already handles.
    
    If @dest_mnt has peers in it's peer group the peer loop in
    propagate_mnt():
    
    for (n = next_peer(dest_mnt); n != dest_mnt; n = next_peer(n)) {
            ret = propagate_one(n);
            if (ret)
                    goto out;
    }
    
    will consecutively update @last_source with each previous copy of the
    source mount tree we created and mounted at the previous peer in
    @dest_mnt's peer group. So after that loop terminates @last_source will
    point to whatever copy of the source mount tree was created and mounted
    on the last peer in @dest_mnt's peer group.
    
    Furthermore, if there is even a single additional peer in @dest_mnt's
    peer group then @last_source will __not__ point to @source_mnt anymore.
    Because, as we mentioned above, @dest_mnt isn't even handled in this
    loop but directly in attach_recursive_mnt(). So it can't even accidently
    come last in that peer loop.
    
    So the first time we handle a slave mount @m of @dest_mnt's peer group
    the copy of the source mount tree we create will make the __last copy of
    the source mount tree we created and mounted on the last peer in
    @dest_mnt's peer group the master of the new copy of the source mount
    tree we create and mount on the first slave of @dest_mnt's peer group__.
    
    But this means that the termination condition that checks for
    @source_mnt is wrong. The @source_mnt cannot be found anymore by
    propagate_one(). Instead it will find the last copy of the source mount
    tree we created and mounted for the last peer of @dest_mnt's peer group
    again. And that is a peer of @source_mnt not @source_mnt itself.
    
    IOW, we fail to terminate the loop correctly and ultimately dereference
    @last_source->mnt_master->mnt_parent. When @source_mnt's peer group
    isn't slave to another peer group then @last_source->mnt_master is NULL
    causing the splat below.
    
    For example, assume @dest_mnt is a pure shared mount and has three peers
    in its peer group:
    
    ===================================================================================
                                             mount-id   mount-parent-id   peer-group-id
    ===================================================================================
    (@dest_mnt) mnt_master[216]              309        297               shared:216
        \
         (@source_mnt) mnt_master[218]:      609        609               shared:218
    
    (1) mnt_master[216]:                     607        605               shared:216
        \
         (P1) mnt_master[218]:               624        607               shared:218
    
    (2) mnt_master[216]:                     576        574               shared:216
        \
         (P2) mnt_master[218]:               625        576               shared:218
    
    (3) mnt_master[216]:                     545        543               shared:216
        \
         (P3) mnt_master[218]:               626        545               shared:218
    
    After this sequence has been processed @last_source will point to (P3),
    the copy generated for the third peer in @dest_mnt's peer group we
    handled. So the copy of the source mount tree (P4) we create and mount
    on the first slave of @dest_mnt's peer group:
    
    ===================================================================================
                                             mount-id   mount-parent-id   peer-group-id
    ===================================================================================
        mnt_master[216]                      309        297               shared:216
       /
      /
    (S0) mnt_slave                           483        481               master:216
      \
       \    (P3) mnt_master[218]             626        545               shared:218
        \  /
         \/
        (P4) mnt_slave                       627        483               master:218
    
    will pick the last copy of the source mount tree (P3) as master, not (S0).
    
    When walking the propagation hierarchy via @last_source's master
    hierarchy we encounter (P3) but not (S0), i.e., @source_mnt.
    
    We can fix this in multiple ways:
    
    (1) By setting @last_source to @source_mnt after we processed the peers
        in @dest_mnt's peer group right after the peer loop in
        propagate_mnt().
    
    (2) By changing the termination condition that relies on finding exactly
        @source_mnt to finding a peer of @source_mnt.
    
    (3) By only moving @last_source when we actually venture into a new peer
        group or some clever variant thereof.
    
    The first two options are minimally invasive and what we want as a fix.
    The third option is more intrusive but something we'd like to explore in
    the near future.
    
    This passes all LTP tests and specifically the mount propagation
    testsuite part of it. It also holds up against all known reproducers of
    this issues.
    
    Final words.
    First, this is a clever but __worringly__ underdocumented algorithm.
    There isn't a single detailed comment to be found in next_group(),
    propagate_one() or anywhere else in that file for that matter. This has
    been a giant pain to understand and work through and a bug like this is
    insanely difficult to fix without a detailed understanding of what's
    happening. Let's not talk about the amount of time that was sunk into
    fixing this.
    
    Second, all the cool kids with access to
    unshare --mount --user --map-root --propagation=unchanged
    are going to have a lot of fun. IOW, triggerable by unprivileged users
    while namespace_lock() lock is held.
    
    [  115.848393] BUG: kernel NULL pointer dereference, address: 0000000000000010
    [  115.848967] #PF: supervisor read access in kernel mode
    [  115.849386] #PF: error_code(0x0000) - not-present page
    [  115.849803] PGD 0 P4D 0
    [  115.850012] Oops: 0000 [#1] PREEMPT SMP PTI
    [  115.850354] CPU: 0 PID: 15591 Comm: mount Not tainted 6.1.0-rc7 #3
    [  115.850851] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
    VirtualBox 12/01/2006
    [  115.851510] RIP: 0010:propagate_one.part.0+0x7f/0x1a0
    [  115.851924] Code: 75 eb 4c 8b 05 c2 25 37 02 4c 89 ca 48 8b 4a 10
    49 39 d0 74 1e 48 3b 81 e0 00 00 00 74 26 48 8b 92 e0 00 00 00 be 01
    00 00 00 <48> 8b 4a 10 49 39 d0 75 e2 40 84 f6 74 38 4c 89 05 84 25 37
    02 4d
    [  115.853441] RSP: 0018:ffffb8d5443d7d50 EFLAGS: 00010282
    [  115.853865] RAX: ffff8e4d87c41c80 RBX: ffff8e4d88ded780 RCX: ffff8e4da4333a00
    [  115.854458] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e4d88ded780
    [  115.855044] RBP: ffff8e4d88ded780 R08: ffff8e4da4338000 R09: ffff8e4da43388c0
    [  115.855693] R10: 0000000000000002 R11: ffffb8d540158000 R12: ffffb8d5443d7da8
    [  115.856304] R13: ffff8e4d88ded780 R14: 0000000000000000 R15: 0000000000000000
    [  115.856859] FS:  00007f92c90c9800(0000) GS:ffff8e4dfdc00000(0000)
    knlGS:0000000000000000
    [  115.857531] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  115.858006] CR2: 0000000000000010 CR3: 0000000022f4c002 CR4: 00000000000706f0
    [  115.858598] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  115.859393] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  115.860099] Call Trace:
    [  115.860358]  <TASK>
    [  115.860535]  propagate_mnt+0x14d/0x190
    [  115.860848]  attach_recursive_mnt+0x274/0x3e0
    [  115.861212]  path_mount+0x8c8/0xa60
    [  115.861503]  __x64_sys_mount+0xf6/0x140
    [  115.861819]  do_syscall_64+0x5b/0x80
    [  115.862117]  ? do_faccessat+0x123/0x250
    [  115.862435]  ? syscall_exit_to_user_mode+0x17/0x40
    [  115.862826]  ? do_syscall_64+0x67/0x80
    [  115.863133]  ? syscall_exit_to_user_mode+0x17/0x40
    [  115.863527]  ? do_syscall_64+0x67/0x80
    [  115.863835]  ? do_syscall_64+0x67/0x80
    [  115.864144]  ? do_syscall_64+0x67/0x80
    [  115.864452]  ? exc_page_fault+0x70/0x170
    [  115.864775]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
    [  115.865187] RIP: 0033:0x7f92c92b0ebe
    [  115.865480] Code: 48 8b 0d 75 4f 0c 00 f7 d8 64 89 01 48 83 c8 ff
    c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00
    00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 42 4f 0c 00 f7 d8 64 89
    01 48
    [  115.866984] RSP: 002b:00007fff000aa728 EFLAGS: 00000246 ORIG_RAX:
    00000000000000a5
    [  115.867607] RAX: ffffffffffffffda RBX: 000055a77888d6b0 RCX: 00007f92c92b0ebe
    [  115.868240] RDX: 000055a77888d8e0 RSI: 000055a77888e6e0 RDI: 000055a77888e620
    [  115.868823] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
    [  115.869403] R10: 0000000000001000 R11: 0000000000000246 R12: 000055a77888e620
    [  115.869994] R13: 000055a77888d8e0 R14: 00000000ffffffff R15: 00007f92c93e4076
    [  115.870581]  </TASK>
    [  115.870763] Modules linked in: nft_fib_inet nft_fib_ipv4
    nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
    nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6
    nf_defrag_ipv4 ip_set rfkill nf_tables nfnetlink qrtr snd_intel8x0
    sunrpc snd_ac97_codec ac97_bus snd_pcm snd_timer intel_rapl_msr
    intel_rapl_common snd vboxguest intel_powerclamp video rapl joydev
    soundcore i2c_piix4 wmi fuse zram xfs vmwgfx crct10dif_pclmul
    crc32_pclmul crc32c_intel polyval_clmulni polyval_generic
    drm_ttm_helper ttm e1000 ghash_clmulni_intel serio_raw ata_generic
    pata_acpi scsi_dh_rdac scsi_dh_emc scsi_dh_alua dm_multipath
    [  115.875288] CR2: 0000000000000010
    [  115.875641] ---[ end trace 0000000000000000 ]---
    [  115.876135] RIP: 0010:propagate_one.part.0+0x7f/0x1a0
    [  115.876551] Code: 75 eb 4c 8b 05 c2 25 37 02 4c 89 ca 48 8b 4a 10
    49 39 d0 74 1e 48 3b 81 e0 00 00 00 74 26 48 8b 92 e0 00 00 00 be 01
    00 00 00 <48> 8b 4a 10 49 39 d0 75 e2 40 84 f6 74 38 4c 89 05 84 25 37
    02 4d
    [  115.878086] RSP: 0018:ffffb8d5443d7d50 EFLAGS: 00010282
    [  115.878511] RAX: ffff8e4d87c41c80 RBX: ffff8e4d88ded780 RCX: ffff8e4da4333a00
    [  115.879128] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8e4d88ded780
    [  115.879715] RBP: ffff8e4d88ded780 R08: ffff8e4da4338000 R09: ffff8e4da43388c0
    [  115.880359] R10: 0000000000000002 R11: ffffb8d540158000 R12: ffffb8d5443d7da8
    [  115.880962] R13: ffff8e4d88ded780 R14: 0000000000000000 R15: 0000000000000000
    [  115.881548] FS:  00007f92c90c9800(0000) GS:ffff8e4dfdc00000(0000)
    knlGS:0000000000000000
    [  115.882234] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  115.882713] CR2: 0000000000000010 CR3: 0000000022f4c002 CR4: 00000000000706f0
    [  115.883314] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  115.883966] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    
    Fixes: f2ebb3a921c1 ("smarter propagate_mnt()")
    Fixes: 5ec0811d3037 ("propogate_mnt: Handle the first propogated copy being a slave")
    Cc: <stable@vger.kernel.org>
    Reported-by: Ditang Chen <ditang.c@gmail.com>
    Signed-off-by: Seth Forshee (Digital Ocean) <sforshee@kernel.org>
    Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
PNP: fix name memory leak in pnp_alloc_dev() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Nov 11 09:23:58 2022 +0800

    PNP: fix name memory leak in pnp_alloc_dev()
    
    [ Upstream commit 110d7b0325c55ff3620073ba4201845f59e22ebf ]
    
    After commit 1fa5ae857bb1 ("driver core: get rid of struct device's
    bus_id string array"), the name of device is allocated dynamically,
    move dev_set_name() after pnp_add_id() to avoid memory leak.
    
    Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
power: supply: fix null pointer dereferencing in power_supply_get_battery_info [+ + +]
Author: ruanjinjie <ruanjinjie@huawei.com>
Date:   Mon Dec 5 15:51:53 2022 +0800

    power: supply: fix null pointer dereferencing in power_supply_get_battery_info
    
    [ Upstream commit 104bb8a663451404a26331263ce5b96c34504049 ]
    
    when kmalloc() fail to allocate memory in kasprintf(), propname
    will be NULL, strcmp() called by of_get_property() will cause
    null pointer dereference.
    
    So return ENOMEM if kasprintf() return NULL pointer.
    
    Fixes: 3afb50d7125b ("power: supply: core: Add some helpers to use the battery OCV capacity table")
    Signed-off-by: ruanjinjie <ruanjinjie@huawei.com>
    Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

power: supply: fix residue sysfs file in error handle route of __power_supply_register() [+ + +]
Author: Zeng Heng <zengheng4@huawei.com>
Date:   Thu Nov 17 16:32:19 2022 +0800

    power: supply: fix residue sysfs file in error handle route of __power_supply_register()
    
    [ Upstream commit 5b79480ce1978864ac3f06f2134dfa3b6691fe74 ]
    
    If device_add() succeeds, we should call device_del() when want to
    get rid of it, so move it into proper jump symbol.
    
    Otherwise, when __power_supply_register() returns fail and goto
    wakeup_init_failed to exit, there is still residue device file in sysfs.
    When attempt to probe device again, sysfs would complain as below:
    
    sysfs: cannot create duplicate filename '/devices/platform/i2c/i2c-0/0-001c/power_supply/adp5061'
    Call Trace:
     dump_stack_lvl+0x68/0x85
     sysfs_warn_dup.cold+0x1c/0x29
     sysfs_create_dir_ns+0x1b1/0x1d0
     kobject_add_internal+0x143/0x390
     kobject_add+0x108/0x170
    
    Fixes: 80c6463e2fa3 ("power_supply: Fix Oops from NULL pointer dereference from wakeup_source_activate")
    Signed-off-by: Zeng Heng <zengheng4@huawei.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/52xx: Fix a resource leak in an error handling path [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Jan 29 08:16:04 2022 +0100

    powerpc/52xx: Fix a resource leak in an error handling path
    
    [ Upstream commit 5836947613ef33d311b4eff6a32d019580a214f5 ]
    
    The error handling path of mpc52xx_lpbfifo_probe() has a request_irq()
    that is not balanced by a corresponding free_irq().
    
    Add the missing call, as already done in the remove function.
    
    Fixes: 3c9059d79f5e ("powerpc/5200: add LocalPlus bus FIFO device driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/dec1496d46ccd5311d0f6e9f9ca4238be11bf6a6.1643440531.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/83xx/mpc832x_rdb: call platform_device_put() in error case in of_fsl_spi_probe() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Sat Oct 29 19:16:26 2022 +0800

    powerpc/83xx/mpc832x_rdb: call platform_device_put() in error case in of_fsl_spi_probe()
    
    [ Upstream commit 4d0eea415216fe3791da2f65eb41399e70c7bedf ]
    
    If platform_device_add() is not called or failed, it can not call
    platform_device_del() to clean up memory, it should call
    platform_device_put() in error case.
    
    Fixes: 26f6cb999366 ("[POWERPC] fsl_soc: add support for fsl_spi")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221029111626.429971-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/hv-gpci: Fix hv_gpci event list [+ + +]
Author: Kajol Jain <kjain@linux.ibm.com>
Date:   Wed Nov 30 23:15:13 2022 +0530

    powerpc/hv-gpci: Fix hv_gpci event list
    
    [ Upstream commit 03f7c1d2a49acd30e38789cd809d3300721e9b0e ]
    
    Based on getPerfCountInfo v1.018 documentation, some of the
    hv_gpci events were deprecated for platform firmware that
    supports counter_info_version 0x8 or above.
    
    Fix the hv_gpci event list by adding a new attribute group
    called "hv_gpci_event_attrs_v6" and a "ENABLE_EVENTS_COUNTERINFO_V6"
    macro to enable these events for platform firmware
    that supports counter_info_version 0x6 or below. And assigning
    the hv_gpci event list based on output counter info version
    of underlying plaform.
    
    Fixes: 97bf2640184f ("powerpc/perf/hv-gpci: add the remaining gpci requests")
    Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
    Reviewed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
    Reviewed-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221130174513.87501-1-kjain@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/imc-pmu: Fix use of mutex in IRQs disabled section [+ + +]
Author: Kajol Jain <kjain@linux.ibm.com>
Date:   Fri Jan 6 12:21:57 2023 +0530

    powerpc/imc-pmu: Fix use of mutex in IRQs disabled section
    
    commit 76d588dddc459fefa1da96e0a081a397c5c8e216 upstream.
    
    Current imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP
    and CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.
    
    Command to trigger the warning:
      # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5
    
       Performance counter stats for 'sleep 5':
    
                       0      thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/
    
             5.002117947 seconds time elapsed
    
             0.000131000 seconds user
             0.001063000 seconds sys
    
    Below is snippet of the warning in dmesg:
    
      BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
      in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec
      preempt_count: 2, expected: 0
      4 locks held by perf-exec/2869:
       #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90
       #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0
       #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510
       #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510
      irq event stamp: 4806
      hardirqs last  enabled at (4805): [<c000000000f65b94>] _raw_spin_unlock_irqrestore+0x94/0xd0
      hardirqs last disabled at (4806): [<c0000000003fae44>] perf_event_exec+0x394/0x510
      softirqs last  enabled at (0): [<c00000000013c404>] copy_process+0xc34/0x1ff0
      softirqs last disabled at (0): [<0000000000000000>] 0x0
      CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61
      Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV
      Call Trace:
        dump_stack_lvl+0x98/0xe0 (unreliable)
        __might_resched+0x2f8/0x310
        __mutex_lock+0x6c/0x13f0
        thread_imc_event_add+0xf4/0x1b0
        event_sched_in+0xe0/0x210
        merge_sched_in+0x1f0/0x600
        visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0
        ctx_flexible_sched_in+0xcc/0x140
        ctx_sched_in+0x20c/0x2a0
        ctx_resched+0x104/0x1c0
        perf_event_exec+0x340/0x510
        begin_new_exec+0x730/0xef0
        load_elf_binary+0x3f8/0x1e10
      ...
      do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0
      WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0
      CPU: 36 PID: 2869 Comm: sleep Tainted: G        W          6.2.0-rc2-00011-g1247637727f2 #61
      Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV
      NIP:  c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670
      REGS: c00000004d2134e0 TRAP: 0700   Tainted: G        W           (6.2.0-rc2-00011-g1247637727f2)
      MSR:  9000000000021033 <SF,HV,ME,IR,DR,RI,LE>  CR: 48002824  XER: 00000000
      CFAR: c00000000013fb64 IRQMASK: 1
    
    The above warning triggered because the current imc-pmu code uses mutex
    lock in interrupt disabled sections. The function mutex_lock()
    internally calls __might_resched(), which will check if IRQs are
    disabled and in case IRQs are disabled, it will trigger the warning.
    
    Fix the issue by changing the mutex lock to spinlock.
    
    Fixes: 8f95faaac56c ("powerpc/powernv: Detect and create IMC device")
    Reported-by: Michael Petlan <mpetlan@redhat.com>
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
    [mpe: Fix comments, trim oops in change log, add reported-by tags]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20230106065157.182648-1-kjain@linux.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
powerpc/perf: callchain validate kernel stack pointer bounds [+ + +]
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Sun Nov 27 22:49:28 2022 +1000

    powerpc/perf: callchain validate kernel stack pointer bounds
    
    [ Upstream commit 32c5209214bd8d4f8c4e9d9b630ef4c671f58e79 ]
    
    The interrupt frame detection and loads from the hypothetical pt_regs
    are not bounds-checked. The next-frame validation only bounds-checks
    STACK_FRAME_OVERHEAD, which does not include the pt_regs. Add another
    test for this.
    
    The user could set r1 to be equal to the address matching the first
    interrupt frame - STACK_INT_FRAME_SIZE, which is in the previous page
    due to the kernel redzone, and induce the kernel to load the marker from
    there. Possibly this could cause a crash at least. If the user could
    induce the previous page to contain a valid marker, then it might be
    able to direct perf to read specific memory addresses in a way that
    could be transmitted back to the user in the perf data.
    
    Fixes: 20002ded4d93 ("perf_counter: powerpc: Add callchain support")
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221127124942.1665522-4-npiggin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/rtas: avoid device tree lookups in rtas_os_term() [+ + +]
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Fri Nov 18 09:07:41 2022 -0600

    powerpc/rtas: avoid device tree lookups in rtas_os_term()
    
    [ Upstream commit ed2213bfb192ab51f09f12e9b49b5d482c6493f3 ]
    
    rtas_os_term() is called during panic. Its behavior depends on a couple
    of conditions in the /rtas node of the device tree, the traversal of
    which entails locking and local IRQ state changes. If the kernel panics
    while devtree_lock is held, rtas_os_term() as currently written could
    hang.
    
    Instead of discovering the relevant characteristics at panic time,
    cache them in file-static variables at boot. Note the lookup for
    "ibm,extended-os-term" is converted to of_property_read_bool() since it
    is a boolean property, not an RTAS function token.
    
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
    [mpe: Incorporate suggested change from Nick]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221118150751.469393-4-nathanl@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

powerpc/rtas: avoid scheduling in rtas_os_term() [+ + +]
Author: Nathan Lynch <nathanl@linux.ibm.com>
Date:   Fri Nov 18 09:07:42 2022 -0600

    powerpc/rtas: avoid scheduling in rtas_os_term()
    
    [ Upstream commit 6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4 ]
    
    It's unsafe to use rtas_busy_delay() to handle a busy status from
    the ibm,os-term RTAS function in rtas_os_term():
    
    Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
    BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618
    in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
    preempt_count: 2, expected: 0
    CPU: 7 PID: 1 Comm: swapper/0 Tainted: G      D            6.0.0-rc5-02182-gf8553a572277-dirty #9
    Call Trace:
    [c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)
    [c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0
    [c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0
    [c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4
    [c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68
    [c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50
    [c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0
    [c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0
    [c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0
    [c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420
    [c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200
    
    Use rtas_busy_delay_time() instead, which signals without side effects
    whether to attempt the ibm,os-term RTAS call again.
    
    Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
    Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
    Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221118150751.469393-5-nathanl@linux.ibm.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/xive: add missing iounmap() in error path in xive_spapr_populate_irq_data() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Oct 17 11:23:33 2022 +0800

    powerpc/xive: add missing iounmap() in error path in xive_spapr_populate_irq_data()
    
    [ Upstream commit 8b49670f3bb3f10cd4d5a6dca17f5a31b173ecdc ]
    
    If remapping 'data->trig_page' fails, the 'data->eoi_mmio' need be unmapped
    before returning from xive_spapr_populate_irq_data().
    
    Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Reviewed-by: Cédric Le Goater <clg@kaod.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221017032333.1852406-1-yangyingliang@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ppp: associate skb with a device at tx [+ + +]
Author: Stanislav Fomichev <sdf@google.com>
Date:   Mon Nov 21 10:29:13 2022 -0800

    ppp: associate skb with a device at tx
    
    [ Upstream commit 9f225444467b98579cf28d94f4ad053460dfdb84 ]
    
    Syzkaller triggered flow dissector warning with the following:
    
    r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0)
    ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0))
    ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})
    pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0)
    
    [    9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0
    [    9.485929]  skb_get_poff+0x53/0xa0
    [    9.485937]  bpf_skb_get_pay_offset+0xe/0x20
    [    9.485944]  ? ppp_send_frame+0xc2/0x5b0
    [    9.485949]  ? _raw_spin_unlock_irqrestore+0x40/0x60
    [    9.485958]  ? __ppp_xmit_process+0x7a/0xe0
    [    9.485968]  ? ppp_xmit_process+0x5b/0xb0
    [    9.485974]  ? ppp_write+0x12a/0x190
    [    9.485981]  ? do_iter_write+0x18e/0x2d0
    [    9.485987]  ? __import_iovec+0x30/0x130
    [    9.485997]  ? do_pwritev+0x1b6/0x240
    [    9.486016]  ? trace_hardirqs_on+0x47/0x50
    [    9.486023]  ? __x64_sys_pwritev+0x24/0x30
    [    9.486026]  ? do_syscall_64+0x3d/0x80
    [    9.486031]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Flow dissector tries to find skb net namespace either via device
    or via socket. Neigher is set in ppp_send_frame, so let's manually
    use ppp->dev.
    
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: linux-ppp@vger.kernel.org
    Reported-by: syzbot+41cab52ab62ee99ed24a@syzkaller.appspotmail.com
    Signed-off-by: Stanislav Fomichev <sdf@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
proc: fixup uptime selftest [+ + +]
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date:   Mon Oct 24 21:08:09 2022 +0300

    proc: fixup uptime selftest
    
    [ Upstream commit 5cc81d5c81af0dee54da9a67a3ebe4be076a13db ]
    
    syscall(3) returns -1 and sets errno on error, unlike "syscall"
    instruction.
    
    Systems which have <= 32/64 CPUs are unaffected. Test won't bounce
    to all CPUs before completing if there are more of them.
    
    Link: https://lkml.kernel.org/r/Y1bUiT7VRXlXPQa1@p183
    Fixes: 1f5bd0547654 ("proc: selftests: test /proc/uptime")
    Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pstore/ram: Fix error return code in ramoops_probe() [+ + +]
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Fri Dec 2 16:22:54 2022 +0800

    pstore/ram: Fix error return code in ramoops_probe()
    
    [ Upstream commit e1fce564900f8734edf15b87f028c57e14f6e28d ]
    
    In the if (dev_of_node(dev) && !pdata) path, the "err" may be assigned a
    value of 0, so the error return code -EINVAL may be incorrectly set
    to 0. To fix set valid return code before calling to goto.
    
    Fixes: 35da60941e44 ("pstore/ram: add Device Tree bindings")
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/1669969374-46582-1-git-send-email-wangyufen@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP [+ + +]
Author: Stephen Boyd <swboyd@chromium.org>
Date:   Mon Dec 5 15:31:36 2022 -0800

    pstore: Avoid kcore oops by vmap()ing with VM_IOREMAP
    
    [ Upstream commit e6b842741b4f39007215fd7e545cb55aa3d358a2 ]
    
    An oops can be induced by running 'cat /proc/kcore > /dev/null' on
    devices using pstore with the ram backend because kmap_atomic() assumes
    lowmem pages are accessible with __va().
    
     Unable to handle kernel paging request at virtual address ffffff807ff2b000
     Mem abort info:
     ESR = 0x96000006
     EC = 0x25: DABT (current EL), IL = 32 bits
     SET = 0, FnV = 0
     EA = 0, S1PTW = 0
     FSC = 0x06: level 2 translation fault
     Data abort info:
     ISV = 0, ISS = 0x00000006
     CM = 0, WnR = 0
     swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000
     [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000
     Internal error: Oops: 96000006 [#1] PREEMPT SMP
     Modules linked in: dm_integrity
     CPU: 7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba
     Hardware name: Google Lazor (rev3 - 8) (DT)
     pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : __memcpy+0x110/0x260
     lr : vread+0x194/0x294
     sp : ffffffc013ee39d0
     x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000
     x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000
     x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21: ffffffc0085a2000
     x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000
     x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60
     x14: ffffffffad588000 x13: 0000000000000000 x12: 0000000000000001
     x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b
     x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000
     x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 : ffffffc013ee3a78
     x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000
     Call trace:
     __memcpy+0x110/0x260
     read_kcore+0x584/0x778
     proc_reg_read+0xb4/0xe4
    
    During early boot, memblock reserves the pages for the ramoops reserved
    memory node in DT that would otherwise be part of the direct lowmem
    mapping. Pstore's ram backend reuses those reserved pages to change the
    memory type (writeback or non-cached) by passing the pages to vmap()
    (see pfn_to_page() usage in persistent_ram_vmap() for more details) with
    specific flags. When read_kcore() starts iterating over the vmalloc
    region, it runs over the virtual address that vmap() returned for
    ramoops. In aligned_vread() the virtual address is passed to
    vmalloc_to_page() which returns the page struct for the reserved lowmem
    area. That lowmem page is passed to kmap_atomic(), which effectively
    calls page_to_virt() that assumes a lowmem page struct must be directly
    accessible with __va() and friends. These pages are mapped via vmap()
    though, and the lowmem mapping was never made, so accessing them via the
    lowmem virtual address oopses like above.
    
    Let's side-step this problem by passing VM_IOREMAP to vmap(). This will
    tell vread() to not include the ramoops region in the kcore. Instead the
    area will look like a bunch of zeros. The alternative is to teach kmap()
    about vmalloc areas that intersect with lowmem. Presumably such a change
    isn't a one-liner, and there isn't much interest in inspecting the
    ramoops region in kcore files anyway, so the most expedient route is
    taken for now.
    
    Cc: Brian Geffon <bgeffon@google.com>
    Cc: Mike Rapoport <rppt@kernel.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Fixes: 404a6043385d ("staging: android: persistent_ram: handle reserving and mapping memory")
    Signed-off-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221205233136.3420802-1-swboyd@chromium.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pstore: Make sure CONFIG_PSTORE_PMSG selects CONFIG_RT_MUTEXES [+ + +]
Author: John Stultz <jstultz@google.com>
Date:   Wed Dec 21 05:18:55 2022 +0000

    pstore: Make sure CONFIG_PSTORE_PMSG selects CONFIG_RT_MUTEXES
    
    [ Upstream commit 2f4fec5943407318b9523f01ce1f5d668c028332 ]
    
    In commit 76d62f24db07 ("pstore: Switch pmsg_lock to an rt_mutex
    to avoid priority inversion") I changed a lock to an rt_mutex.
    
    However, its possible that CONFIG_RT_MUTEXES is not enabled,
    which then results in a build failure, as the 0day bot detected:
      https://lore.kernel.org/linux-mm/202212211244.TwzWZD3H-lkp@intel.com/
    
    Thus this patch changes CONFIG_PSTORE_PMSG to select
    CONFIG_RT_MUTEXES, which ensures the build will not fail.
    
    Cc: Wei Wang <wvw@google.com>
    Cc: Midas Chien<midaschieh@google.com>
    Cc: Connor O'Brien <connoro@google.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Anton Vorontsov <anton@enomsg.org>
    Cc: Colin Cross <ccross@android.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: kernel test robot <lkp@intel.com>
    Cc: kernel-team@android.com
    Fixes: 76d62f24db07 ("pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: John Stultz <jstultz@google.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221221051855.15761-1-jstultz@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion [+ + +]
Author: John Stultz <jstultz@google.com>
Date:   Wed Dec 14 23:18:34 2022 +0000

    pstore: Switch pmsg_lock to an rt_mutex to avoid priority inversion
    
    [ Upstream commit 76d62f24db07f22ccf9bc18ca793c27d4ebef721 ]
    
    Wei Wang reported seeing priority inversion caused latencies
    caused by contention on pmsg_lock, and suggested it be switched
    to a rt_mutex.
    
    I was initially hesitant this would help, as the tasks in that
    trace all seemed to be SCHED_NORMAL, so the benefit would be
    limited to only nice boosting.
    
    However, another similar issue was raised where the priority
    inversion was seen did involve a blocked RT task so it is clear
    this would be helpful in that case.
    
    Cc: Wei Wang <wvw@google.com>
    Cc: Midas Chien<midaschieh@google.com>
    Cc: Connor O'Brien <connoro@google.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Anton Vorontsov <anton@enomsg.org>
    Cc: Colin Cross <ccross@android.com>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: kernel-team@android.com
    Fixes: 9d5438f462ab ("pstore: Add pmsg - user-space accessible pstore object")
    Reported-by: Wei Wang <wvw@google.com>
    Signed-off-by: John Stultz <jstultz@google.com>
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: https://lore.kernel.org/r/20221214231834.3711880-1-jstultz@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pwm: sifive: Call pwm_sifive_update_clock() while mutex is held [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Dec 2 19:35:05 2022 +0100

    pwm: sifive: Call pwm_sifive_update_clock() while mutex is held
    
    [ Upstream commit 45558b3abb87eeb2cedb8a59cb2699c120b5102a ]
    
    As was documented in commit 0f02f491b786 ("pwm: sifive: Reduce time the
    controller lock is held") a caller of pwm_sifive_update_clock() must
    hold the mutex. So fix pwm_sifive_clock_notifier() to grab the lock.
    
    While this necessity was only documented later, the race exists since
    the driver was introduced.
    
    Fixes: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM")
    Reported-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
    Link: https://lore.kernel.org/r/20221018061656.1428111-1-u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failure [+ + +]
Author: Daniil Tatianin <d-tatianin@yandex-team.ru>
Date:   Thu Dec 22 14:52:28 2022 +0300

    qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failure
    
    [ Upstream commit 13a7c8964afcd8ca43c0b6001ebb0127baa95362 ]
    
    adapter->dcb would get silently freed inside qlcnic_dcb_enable() in
    case qlcnic_dcb_attach() would return an error, which always happens
    under OOM conditions. This would lead to use-after-free because both
    of the existing callers invoke qlcnic_dcb_get_info() on the obtained
    pointer, which is potentially freed at that point.
    
    Propagate errors from qlcnic_dcb_enable(), and instead free the dcb
    pointer at callsite using qlcnic_dcb_free(). This also removes the now
    unused qlcnic_clear_dcb_ops() helper, which was a simple wrapper around
    kfree() also causing memory leaks for partially initialized dcb.
    
    Found by Linux Verification Center (linuxtesting.org) with the SVACE
    static analysis tool.
    
    Fixes: 3c44bba1d270 ("qlcnic: Disable DCB operations from SR-IOV VFs")
    Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
    Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
quota: Factor out setup of quota inode [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Fri Nov 1 17:45:31 2019 +0100

    quota: Factor out setup of quota inode
    
    [ Upstream commit c7d3d28360fdb3ed3a5aa0bab19315e0fdc994a1 ]
    
    Factor out setting up of quota inode and eventual error cleanup from
    vfs_load_quota_inode(). This will simplify situation for filesystems
    that don't have any quota inodes.
    
    Signed-off-by: Jan Kara <jack@suse.cz>
    Stable-dep-of: d32387748476 ("ext4: fix bug_on in __es_tree_search caused by bad quota inode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
r6040: Fix kmemleak in probe and remove [+ + +]
Author: Li Zetao <lizetao1@huawei.com>
Date:   Tue Dec 13 20:56:14 2022 +0800

    r6040: Fix kmemleak in probe and remove
    
    [ Upstream commit 7e43039a49c2da45edc1d9d7c9ede4003ab45a5f ]
    
    There is a memory leaks reported by kmemleak:
    
      unreferenced object 0xffff888116111000 (size 2048):
        comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s)
        hex dump (first 32 bytes):
          00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff  ................
          08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60
          [<ffffffff827e20ee>] phy_device_create+0x4e/0x90
          [<ffffffff827e6072>] get_phy_device+0xd2/0x220
          [<ffffffff827e7844>] mdiobus_scan+0xa4/0x2e0
          [<ffffffff827e8be2>] __mdiobus_register+0x482/0x8b0
          [<ffffffffa01f5d24>] r6040_init_one+0x714/0xd2c [r6040]
          ...
    
    The problem occurs in probe process as follows:
      r6040_init_one:
        mdiobus_register
          mdiobus_scan    <- alloc and register phy_device,
                             the reference count of phy_device is 3
        r6040_mii_probe
          phy_connect     <- connect to the first phy_device,
                             so the reference count of the first
                             phy_device is 4, others are 3
        register_netdev   <- fault inject succeeded, goto error handling path
    
        // error handling path
        err_out_mdio_unregister:
          mdiobus_unregister(lp->mii_bus);
        err_out_mdio:
          mdiobus_free(lp->mii_bus);    <- the reference count of the first
                                           phy_device is 1, it is not released
                                           and other phy_devices are released
      // similarly, the remove process also has the same problem
    
    The root cause is traced to the phy_device is not disconnected when
    removes one r6040 device in r6040_remove_one() or on error handling path
    after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet
    device is connected to the first PHY device of mii_bus, in order to
    notify the connected driver when the link status changes, which is the
    default behavior of the PHY infrastructure to handle everything.
    Therefore the phy_device should be disconnected when removes one r6040
    device or on error handling path.
    
    Fix it by adding phy_disconnect() when removes one r6040 device or on
    error handling path after r6040_mii probed successfully.
    
    Fixes: 3831861b4ad8 ("r6040: implement phylib")
    Signed-off-by: Li Zetao <lizetao1@huawei.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/20221213125614.927754-1-lizetao1@huawei.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rapidio: devices: fix missing put_device in mport_cdev_open [+ + +]
Author: Cai Xinchen <caixinchen1@huawei.com>
Date:   Sat Dec 3 08:57:21 2022 +0000

    rapidio: devices: fix missing put_device in mport_cdev_open
    
    [ Upstream commit d5b6e6eba3af11cb2a2791fa36a2524990fcde1a ]
    
    When kfifo_alloc fails, the refcount of chdev->dev is left incremental.
    We should use put_device(&chdev->dev) to decrease the ref count of
    chdev->dev to avoid refcount leak.
    
    Link: https://lkml.kernel.org/r/20221203085721.13146-1-caixinchen1@huawei.com
    Fixes: e8de370188d0 ("rapidio: add mport char device driver")
    Signed-off-by: Cai Xinchen <caixinchen1@huawei.com>
    Cc: Alexandre Bounine <alex.bou9@gmail.com>
    Cc: Dan Carpenter <error27@gmail.com>
    Cc: Jakob Koschel <jakobkoschel@gmail.com>
    Cc: John Hubbard <jhubbard@nvidia.com>
    Cc: Matt Porter <mporter@kernel.crashing.org>
    Cc: Wang Weiyang <wangweiyang2@huawei.com>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rapidio: fix possible name leaks when rio_add_device() fails [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Nov 14 23:26:35 2022 +0800

    rapidio: fix possible name leaks when rio_add_device() fails
    
    [ Upstream commit f9574cd48679926e2a569e1957a5a1bcc8a719ac ]
    
    Patch series "rapidio: fix three possible memory leaks".
    
    This patchset fixes three name leaks in error handling.
     - patch #1 fixes two name leaks while rio_add_device() fails.
     - patch #2 fixes a name leak while  rio_register_mport() fails.
    
    This patch (of 2):
    
    If rio_add_device() returns error, the name allocated by dev_set_name()
    need be freed.  It should use put_device() to give up the reference in the
    error path, so that the name can be freed in kobject_cleanup(), and the
    'rdev' can be freed in rio_release_dev().
    
    Link: https://lkml.kernel.org/r/20221114152636.2939035-1-yangyingliang@huawei.com
    Link: https://lkml.kernel.org/r/20221114152636.2939035-2-yangyingliang@huawei.com
    Fixes: e8de370188d0 ("rapidio: add mport char device driver")
    Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Cc: Alexandre Bounine <alex.bou9@gmail.com>
    Cc: Matt Porter <mporter@kernel.crashing.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rapidio: fix possible UAF when kfifo_alloc() fails [+ + +]
Author: Wang Weiyang <wangweiyang2@huawei.com>
Date:   Wed Nov 23 17:51:47 2022 +0800

    rapidio: fix possible UAF when kfifo_alloc() fails
    
    [ Upstream commit 02d7d89f816951e0862147d751b1150d67aaebdd ]
    
    If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free
    priv. But priv is still in the chdev->file_list, then list traversal
    may cause UAF. This fixes the following smatch warning:
    
    drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: '&priv->list' not removed from list
    
    Link: https://lkml.kernel.org/r/20221123095147.52408-1-wangweiyang2@huawei.com
    Fixes: e8de370188d0 ("rapidio: add mport char device driver")
    Signed-off-by: Wang Weiyang <wangweiyang2@huawei.com>
    Cc: Alexandre Bounine <alex.bou9@gmail.com>
    Cc: Dan Carpenter <error27@gmail.com>
    Cc: Jakob Koschel <jakobkoschel@gmail.com>
    Cc: John Hubbard <jhubbard@nvidia.com>
    Cc: Matt Porter <mporter@kernel.crashing.org>
    Cc: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rapidio: rio: fix possible name leak in rio_register_mport() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Nov 14 23:26:36 2022 +0800

    rapidio: rio: fix possible name leak in rio_register_mport()
    
    [ Upstream commit e92a216d16bde65d21a3227e0fb2aa0794576525 ]
    
    If device_register() returns error, the name allocated by dev_set_name()
    need be freed.  It should use put_device() to give up the reference in the
    error path, so that the name can be freed in kobject_cleanup(), and
    list_del() is called to delete the port from rio_mports.
    
    Link: https://lkml.kernel.org/r/20221114152636.2939035-3-yangyingliang@huawei.com
    Fixes: 2aaf308b95b2 ("rapidio: rework device hierarchy and introduce mport class of devices")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Cc: Alexandre Bounine <alex.bou9@gmail.com>
    Cc: Matt Porter <mporter@kernel.crashing.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ravb: Fix "failed to switch device to config mode" message during unbind [+ + +]
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date:   Wed Dec 14 10:51:18 2022 +0000

    ravb: Fix "failed to switch device to config mode" message during unbind
    
    [ Upstream commit c72a7e42592b2e18d862cf120876070947000d7a ]
    
    This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch
    device to config mode" during unbind.
    
    We are doing register access after pm_runtime_put_sync().
    
    We usually do cleanup in reverse order of init. Currently in
    remove(), the "pm_runtime_put_sync" is not in reverse order.
    
    Probe
            reset_control_deassert(rstc);
            pm_runtime_enable(&pdev->dev);
            pm_runtime_get_sync(&pdev->dev);
    
    remove
            pm_runtime_put_sync(&pdev->dev);
            unregister_netdev(ndev);
            ..
            ravb_mdio_release(priv);
            pm_runtime_disable(&pdev->dev);
    
    Consider the call to unregister_netdev()
    unregister_netdev->unregister_netdevice_queue->rollback_registered_many
    that calls the below functions which access the registers after
    pm_runtime_put_sync()
     1) ravb_get_stats
     2) ravb_close
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Cc: stable@vger.kernel.org
    Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
    Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state() [+ + +]
Author: Zqiang <qiang1.zhang@intel.com>
Date:   Thu Oct 13 12:41:48 2022 +0800

    rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state()
    
    [ Upstream commit ceb1c8c9b8aa9199da46a0f29d2d5f08d9b44c15 ]
    
    Running rcutorture with non-zero fqs_duration module parameter in a
    kernel built with CONFIG_PREEMPTION=y results in the following splat:
    
    BUG: using __this_cpu_read() in preemptible [00000000]
    code: rcu_torture_fqs/398
    caller is __this_cpu_preempt_check+0x13/0x20
    CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+
    Call Trace:
    <TASK>
    dump_stack_lvl+0x5b/0x86
    dump_stack+0x10/0x16
    check_preemption_disabled+0xe5/0xf0
    __this_cpu_preempt_check+0x13/0x20
    rcu_force_quiescent_state.part.0+0x1c/0x170
    rcu_force_quiescent_state+0x1e/0x30
    rcu_torture_fqs+0xca/0x160
    ? rcu_torture_boost+0x430/0x430
    kthread+0x192/0x1d0
    ? kthread_complete_and_exit+0x30/0x30
    ret_from_fork+0x22/0x30
    </TASK>
    
    The problem is that rcu_force_quiescent_state() uses __this_cpu_read()
    in preemptible code instead of the proper raw_cpu_read().  This commit
    therefore changes __this_cpu_read() to raw_cpu_read().
    
    Signed-off-by: Zqiang <qiang1.zhang@intel.com>
    Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
    Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/core: Fix order of nldev_exit call [+ + +]
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue Oct 25 10:37:13 2022 +0300

    RDMA/core: Fix order of nldev_exit call
    
    [ Upstream commit 4508d32ccced24c972bc4592104513e1ff8439b5 ]
    
    Create symmetrical exit flow by calling to nldev_exit() after
    call to rdma_nl_unregister(RDMA_NL_LS).
    
    Fixes: 6c80b41abe22 ("RDMA/netlink: Add nldev initialization flows")
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/64e676774a53a406f4cde265d5a4cfd6b8e97df9.1666683334.git.leonro@nvidia.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/hfi1: Fix error return code in parse_platform_config() [+ + +]
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Fri Dec 2 12:00:37 2022 +0800

    RDMA/hfi1: Fix error return code in parse_platform_config()
    
    [ Upstream commit 725349f8ba1e78a146c6ff8f3ee5e2712e517106 ]
    
    In the previous iteration of the while loop, the "ret" may have been
    assigned a value of 0, so the error return code -EINVAL may have been
    incorrectly set to 0. To fix set valid return code before calling to
    goto.
    
    Fixes: 97167e813415 ("staging/rdma/hfi1: Tune for unknown channel if configuration file is absent")
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Link: https://lore.kernel.org/r/1669953638-11747-1-git-send-email-wangyufen@huawei.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/hfi: Decrease PCI device reference count in error path [+ + +]
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Thu Nov 17 21:15:46 2022 +0800

    RDMA/hfi: Decrease PCI device reference count in error path
    
    [ Upstream commit 9b51d072da1d27e1193e84708201c48e385ad912 ]
    
    pci_get_device() will increase the reference count for the returned
    pci_dev, and also decrease the reference count for the input parameter
    *from* if it is not NULL.
    
    If we break out the loop in node_affinity_init() with 'dev' not NULL, we
    need to call pci_dev_put() to decrease the reference count. Add missing
    pci_dev_put() in error path.
    
    Fixes: c513de490f80 ("IB/hfi1: Invalid NUMA node information can cause a divide by zero")
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Link: https://lore.kernel.org/r/20221117131546.113280-1-wangxiongfeng2@huawei.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/mlx5: Fix validation of max_rd_atomic caps for DC [+ + +]
Author: Maor Gottlieb <maorg@nvidia.com>
Date:   Wed Dec 28 14:56:10 2022 +0200

    RDMA/mlx5: Fix validation of max_rd_atomic caps for DC
    
    [ Upstream commit 8de8482fe5732fbef4f5af82bc0c0362c804cd1f ]
    
    Currently, when modifying DC, we validate max_rd_atomic user attribute
    against the RC cap, validate against DC. RC and DC QP types have different
    device limitations.
    
    This can cause userspace created DC QPs to malfunction.
    
    Fixes: c32a4f296e1d ("IB/mlx5: Add support for DC Initiator QP")
    Link: https://lore.kernel.org/r/0c5aee72cea188c3bb770f4207cce7abc9b6fc74.1672231736.git.leonro@nvidia.com
    Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/nldev: Add checks for nla_nest_start() in fill_stat_counter_qps() [+ + +]
Author: Yuan Can <yuancan@huawei.com>
Date:   Sat Nov 26 04:34:10 2022 +0000

    RDMA/nldev: Add checks for nla_nest_start() in fill_stat_counter_qps()
    
    [ Upstream commit ea5ef136e215fdef35f14010bc51fcd6686e6922 ]
    
    As the nla_nest_start() may fail with NULL returned, the return value needs
    to be checked.
    
    Fixes: c4ffee7c9bdb ("RDMA/netlink: Implement counter dumpit calback")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Link: https://lore.kernel.org/r/20221126043410.85632-1-yuancan@huawei.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/nldev: Return "-EAGAIN" if the cm_id isn't from expected port [+ + +]
Author: Mark Zhang <markzhang@nvidia.com>
Date:   Mon Nov 7 10:51:36 2022 +0200

    RDMA/nldev: Return "-EAGAIN" if the cm_id isn't from expected port
    
    [ Upstream commit ecacb3751f254572af0009b9501e2cdc83a30b6a ]
    
    When filling a cm_id entry, return "-EAGAIN" instead of 0 if the cm_id
    doesn'the have the same port as requested, otherwise an incomplete entry
    may be returned, which causes "rdam res show cm_id" to return an error.
    
    For example on a machine with two rdma devices with "rping -C 1 -v -s"
    running background, the "rdma" command fails:
      $ rdma -V
      rdma utility, iproute2-5.19.0
      $ rdma res show cm_id
      link mlx5_0/- cm-idn 0 state LISTEN ps TCP pid 28056 comm rping src-addr 0.0.0.0:7174
      error: Protocol not available
    
    While with this fix it succeeds:
      $ rdma res show cm_id
      link mlx5_0/- cm-idn 0 state LISTEN ps TCP pid 26395 comm rping src-addr 0.0.0.0:7174
      link mlx5_1/- cm-idn 0 state LISTEN ps TCP pid 26395 comm rping src-addr 0.0.0.0:7174
    
    Fixes: 00313983cda6 ("RDMA/nldev: provide detailed CM_ID information")
    Signed-off-by: Mark Zhang <markzhang@nvidia.com>
    Link: https://lore.kernel.org/r/a08e898cdac5e28428eb749a99d9d981571b8ea7.1667810736.git.leonro@nvidia.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/rxe: Fix NULL-ptr-deref in rxe_qp_do_cleanup() when socket create failed [+ + +]
Author: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Date:   Tue Nov 22 23:14:37 2022 +0800

    RDMA/rxe: Fix NULL-ptr-deref in rxe_qp_do_cleanup() when socket create failed
    
    [ Upstream commit f67376d801499f4fa0838c18c1efcad8840e550d ]
    
    There is a null-ptr-deref when mount.cifs over rdma:
    
      BUG: KASAN: null-ptr-deref in rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe]
      Read of size 8 at addr 0000000000000018 by task mount.cifs/3046
    
      CPU: 2 PID: 3046 Comm: mount.cifs Not tainted 6.1.0-rc5+ #62
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc3
      Call Trace:
       <TASK>
       dump_stack_lvl+0x34/0x44
       kasan_report+0xad/0x130
       rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe]
       execute_in_process_context+0x25/0x90
       __rxe_cleanup+0x101/0x1d0 [rdma_rxe]
       rxe_create_qp+0x16a/0x180 [rdma_rxe]
       create_qp.part.0+0x27d/0x340
       ib_create_qp_kernel+0x73/0x160
       rdma_create_qp+0x100/0x230
       _smbd_get_connection+0x752/0x20f0
       smbd_get_connection+0x21/0x40
       cifs_get_tcp_session+0x8ef/0xda0
       mount_get_conns+0x60/0x750
       cifs_mount+0x103/0xd00
       cifs_smb3_do_mount+0x1dd/0xcb0
       smb3_get_tree+0x1d5/0x300
       vfs_get_tree+0x41/0xf0
       path_mount+0x9b3/0xdd0
       __x64_sys_mount+0x190/0x1d0
       do_syscall_64+0x35/0x80
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    The root cause of the issue is the socket create failed in
    rxe_qp_init_req().
    
    So move the reset rxe_qp_do_cleanup() after the NULL ptr check.
    
    Fixes: 8700e3e7c485 ("Soft RoCE driver")
    Link: https://lore.kernel.org/r/20221122151437.1057671-1-zhangxiaoxu5@huawei.com
    Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/siw: Fix immediate work request flush to completion queue [+ + +]
Author: Bernard Metzler <bmt@zurich.ibm.com>
Date:   Mon Nov 7 15:50:57 2022 +0100

    RDMA/siw: Fix immediate work request flush to completion queue
    
    [ Upstream commit bdf1da5df9da680589a7f74448dd0a94dd3e1446 ]
    
    Correctly set send queue element opcode during immediate work request
    flushing in post sendqueue operation, if the QP is in ERROR state.
    An undefined ocode value results in out-of-bounds access to an array
    for mapping the opcode between siw internal and RDMA core representation
    in work completion generation. It resulted in a KASAN BUG report
    of type 'global-out-of-bounds' during NFSoRDMA testing.
    
    This patch further fixes a potential case of a malicious user which may
    write undefined values for completion queue elements status or opcode,
    if the CQ is memory mapped to user land. It avoids the same out-of-bounds
    access to arrays for status and opcode mapping as described above.
    
    Fixes: 303ae1cdfdf7 ("rdma/siw: application interface")
    Fixes: b0fff7317bb4 ("rdma/siw: completion queue methods")
    Reported-by: Olga Kornievskaia <kolga@netapp.com>
    Reviewed-by: Tom Talpey <tom@talpey.com>
    Signed-off-by: Bernard Metzler <bmt@zurich.ibm.com>
    Link: https://lore.kernel.org/r/20221107145057.895747-1-bmt@zurich.ibm.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/siw: Fix pointer cast warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Dec 15 18:03:43 2022 +0100

    RDMA/siw: Fix pointer cast warning
    
    [ Upstream commit 5244ca88671a1981ceec09c5c8809f003e6a62aa ]
    
    The previous build fix left a remaining issue in configurations with
    64-bit dma_addr_t on 32-bit architectures:
    
    drivers/infiniband/sw/siw/siw_qp_tx.c: In function 'siw_get_pblpage':
    drivers/infiniband/sw/siw/siw_qp_tx.c:32:37: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
       32 |                 return virt_to_page((void *)paddr);
          |                                     ^
    
    Use the same double cast here that the driver uses elsewhere to convert
    between dma_addr_t and void*.
    
    Fixes: 0d1b756acf60 ("RDMA/siw: Pass a pointer to virt_to_page()")
    Link: https://lore.kernel.org/r/20221215170347.2612403-1-arnd@kernel.org
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Bernard Metzler <bmt@zurich.ibm.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

RDMA/siw: Set defined status for work completion with undefined status [+ + +]
Author: Bernard Metzler <bmt@zurich.ibm.com>
Date:   Tue Nov 15 18:07:47 2022 +0100

    RDMA/siw: Set defined status for work completion with undefined status
    
    [ Upstream commit 60da2d11fcbc043304910e4d2ca82f9bab953e63 ]
    
    A malicious user may write undefined values into memory mapped completion
    queue elements status or opcode. Undefined status or opcode values will
    result in out-of-bounds access to an array mapping siw internal
    representation of opcode and status to RDMA core representation when
    reaping CQ elements. While siw detects those undefined values, it did not
    correctly set completion status to a defined value, thus defeating the
    whole purpose of the check.
    
    This bug leads to the following Smatch static checker warning:
    
            drivers/infiniband/sw/siw/siw_cq.c:96 siw_reap_cqe()
            error: buffer overflow 'map_cqe_status' 10 <= 21
    
    Fixes: bdf1da5df9da ("RDMA/siw: Fix immediate work request flush to completion queue")
    Link: https://lore.kernel.org/r/20221115170747.1263298-1-bmt@zurich.ibm.com
    Reported-by: Dan Carpenter <error27@gmail.com>
    Signed-off-by: Bernard Metzler <bmt@zurich.ibm.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/uverbs: Silence shiftTooManyBitsSigned warning [+ + +]
Author: Leon Romanovsky <leon@kernel.org>
Date:   Mon Jul 20 20:56:27 2020 +0300

    RDMA/uverbs: Silence shiftTooManyBitsSigned warning
    
    [ Upstream commit 9b8d846924856570625b93f83ae0624391193bce ]
    
    Fix reported by kbuild warning.
    
       drivers/infiniband/core/uverbs_cmd.c:1897:47: warning: Shifting signed 32-bit value by 31 bits is undefined behaviour [shiftTooManyBitsSigned]
        BUILD_BUG_ON(IB_USER_LAST_QP_ATTR_MASK == (1 << 31));
                                                     ^
    Link: https://lore.kernel.org/r/20200720175627.1273096-3-leon@kernel.org
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Stable-dep-of: 8de8482fe573 ("RDMA/mlx5: Fix validation of max_rd_atomic caps for DC")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
regulator: core: fix deadlock on regulator enable [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Thu Dec 15 11:46:46 2022 +0100

    regulator: core: fix deadlock on regulator enable
    
    commit cb3543cff90a4448ed560ac86c98033ad5fecda9 upstream.
    
    When updating the operating mode as part of regulator enable, the caller
    has already locked the regulator tree and drms_uA_update() must not try
    to do the same in order not to trigger a deadlock.
    
    The lock inversion is reported by lockdep as:
    
      ======================================================
      WARNING: possible circular locking dependency detected
      6.1.0-next-20221215 #142 Not tainted
      ------------------------------------------------------
      udevd/154 is trying to acquire lock:
      ffffc11f123d7e50 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x280
    
      but task is already holding lock:
      ffff80000e4c36e8 (regulator_ww_class_acquire){+.+.}-{0:0}, at: regulator_enable+0x34/0x80
    
      which lock already depends on the new lock.
    
      ...
    
       Possible unsafe locking scenario:
    
             CPU0                    CPU1
             ----                    ----
        lock(regulator_ww_class_acquire);
                                     lock(regulator_list_mutex);
                                     lock(regulator_ww_class_acquire);
        lock(regulator_list_mutex);
    
       *** DEADLOCK ***
    
    just before probe of a Qualcomm UFS controller (occasionally) deadlocks
    when enabling one of its regulators.
    
    Fixes: 9243a195be7a ("regulator: core: Change voltage setting path")
    Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
    Cc: stable@vger.kernel.org      # 5.0
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Link: https://lore.kernel.org/r/20221215104646.19818-1-johan+linaro@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

regulator: core: fix module refcount leak in set_supply() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Dec 1 20:27:05 2022 +0800

    regulator: core: fix module refcount leak in set_supply()
    
    [ Upstream commit da46ee19cbd8344d6860816b4827a7ce95764867 ]
    
    If create_regulator() fails in set_supply(), the module refcount
    needs be put to keep refcount balanced.
    
    Fixes: e2c09ae7a74d ("regulator: core: Increase refcount for regulator supply's module")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221201122706.4055992-2-yangyingliang@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: core: fix resource leak in regulator_register() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Dec 2 10:51:11 2022 +0800

    regulator: core: fix resource leak in regulator_register()
    
    [ Upstream commit ba62319a42c50e6254e98b3f316464fac8e77968 ]
    
    I got some resource leak reports while doing fault injection test:
    
      OF: ERROR: memory leak, expected refcount 1 instead of 100,
      of_node_get()/of_node_put() unbalanced - destroy cset entry:
      attach overlay node /i2c/pmic@64/regulators/buck1
    
    unreferenced object 0xffff88810deea000 (size 512):
      comm "490-i2c-rt5190a", pid 253, jiffies 4294859840 (age 5061.046s)
      hex dump (first 32 bytes):
        00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
        ff ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff  ................
      backtrace:
        [<00000000d78541e2>] kmalloc_trace+0x21/0x110
        [<00000000b343d153>] device_private_init+0x32/0xd0
        [<00000000be1f0c70>] device_add+0xb2d/0x1030
        [<00000000e3e6344d>] regulator_register+0xaf2/0x12a0
        [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0
        [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]
    
    unreferenced object 0xffff88810b617b80 (size 32):
      comm "490-i2c-rt5190a", pid 253, jiffies 4294859904 (age 5060.983s)
      hex dump (first 32 bytes):
        72 65 67 75 6c 61 74 6f 72 2e 32 38 36 38 2d 53  regulator.2868-S
        55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00  UPPLY...)...+...
      backtrace:
        [<000000009da9280d>] __kmalloc_node_track_caller+0x44/0x1b0
        [<0000000025c6a4e5>] kstrdup+0x3a/0x70
        [<00000000790efb69>] create_regulator+0xc0/0x4e0
        [<0000000005ed203a>] regulator_resolve_supply+0x2d4/0x440
        [<0000000045796214>] regulator_register+0x10b3/0x12a0
        [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0
        [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]
    
    After calling regulator_resolve_supply(), the 'rdev->supply' is set
    by set_supply(), after this set, in the error path, the resources
    need be released, so call regulator_put() to avoid the leaks.
    
    Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator")
    Fixes: 8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221202025111.496402-1-yangyingliang@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: core: fix unbalanced of node refcount in regulator_dev_lookup() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 15 17:15:08 2022 +0800

    regulator: core: fix unbalanced of node refcount in regulator_dev_lookup()
    
    [ Upstream commit f2b41b748c19962b82709d9f23c6b2b0ce9d2f91 ]
    
    I got the the following report:
    
      OF: ERROR: memory leak, expected refcount 1 instead of 2,
      of_node_get()/of_node_put() unbalanced - destroy cset entry:
      attach overlay node /i2c/pmic@62/regulators/exten
    
    In of_get_regulator(), the node is returned from of_parse_phandle()
    with refcount incremented, after using it, of_node_put() need be called.
    
    Fixes: 69511a452e6d ("regulator: map consumer regulator based on device tree")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221115091508.900752-1-yangyingliang@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: core: fix use_count leakage when handling boot-on [+ + +]
Author: Rui Zhang <zr.zhang@vivo.com>
Date:   Thu Dec 1 11:38:06 2022 +0800

    regulator: core: fix use_count leakage when handling boot-on
    
    [ Upstream commit 0591b14ce0398125439c759f889647369aa616a0 ]
    
    I found a use_count leakage towards supply regulator of rdev with
    boot-on option.
    
    ┌───────────────────┐           ┌───────────────────┐
    │  regulator_dev A  │           │  regulator_dev B  │
    │     (boot-on)     │           │     (boot-on)     │
    │    use_count=0    │◀──supply──│    use_count=1    │
    │                   │           │                   │
    └───────────────────┘           └───────────────────┘
    
    In case of rdev(A) configured with `regulator-boot-on', the use_count
    of supplying regulator(B) will increment inside
    regulator_enable(rdev->supply).
    
    Thus, B will acts like always-on, and further balanced
    regulator_enable/disable cannot actually disable it anymore.
    
    However, B was also configured with `regulator-boot-on', we wish it
    could be disabled afterwards.
    
    Signed-off-by: Rui Zhang <zr.zhang@vivo.com>
    Link: https://lore.kernel.org/r/20221201033806.2567812-1-zr.zhang@vivo.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: core: use kfree_const() to free space conditionally [+ + +]
Author: Wang ShaoBo <bobo.shaobowang@huawei.com>
Date:   Wed Nov 23 11:46:16 2022 +0800

    regulator: core: use kfree_const() to free space conditionally
    
    [ Upstream commit dc8d006d15b623c1d80b90b45d6dcb6e890dad09 ]
    
    Use kfree_const() to free supply_name conditionally in create_regulator()
    as supply_name may be allocated from kmalloc() or directly from .rodata
    section.
    
    Fixes: 87fe29b61f95 ("regulator: push allocations in create_regulator() outside of lock")
    Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Link: https://lore.kernel.org/r/20221123034616.3609537-1-bobo.shaobowang@huawei.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

regulator: da9211: Use irq handler when ready [+ + +]
Author: Ricardo Ribalda <ribalda@chromium.org>
Date:   Sun Nov 27 22:06:02 2022 +0100

    regulator: da9211: Use irq handler when ready
    
    [ Upstream commit 02228f6aa6a64d588bc31e3267d05ff184d772eb ]
    
    If the system does not come from reset (like when it is kexec()), the
    regulator might have an IRQ waiting for us.
    
    If we enable the IRQ handler before its structures are ready, we crash.
    
    This patch fixes:
    
    [    1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078
    [    1.316096] Call trace:
    [    1.316101]  blocking_notifier_call_chain+0x20/0xa8
    [    1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests
    [    1.327823]  regulator_notifier_call_chain+0x1c/0x2c
    [    1.327825]  da9211_irq_handler+0x68/0xf8
    [    1.327829]  irq_thread+0x11c/0x234
    [    1.327833]  kthread+0x13c/0x154
    
    Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
    Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com>
    Link: https://lore.kernel.org/r/20221124-da9211-v2-0-1779e3c5d491@chromium.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
reiserfs: Add missing calls to reiserfs_security_free() [+ + +]
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Thu Nov 10 10:46:35 2022 +0100

    reiserfs: Add missing calls to reiserfs_security_free()
    
    commit 572302af1258459e124437b8f3369357447afac7 upstream.
    
    Commit 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes
    during inode creation") defined reiserfs_security_free() to free the name
    and value of a security xattr allocated by the active LSM through
    security_old_inode_init_security(). However, this function is not called
    in the reiserfs code.
    
    Thus, add a call to reiserfs_security_free() whenever
    reiserfs_security_init() is called, and initialize value to NULL, to avoid
    to call kfree() on an uninitialized pointer.
    
    Finally, remove the kfree() for the xattr name, as it is not allocated
    anymore.
    
    Fixes: 57fe60df6241 ("reiserfs: add atomic addition of selinux attributes during inode creation")
    Cc: stable@vger.kernel.org
    Cc: Jeff Mahoney <jeffm@suse.com>
    Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reported-by: Mimi Zohar <zohar@linux.ibm.com>
    Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
relay: fix type mismatch when allocating memory in relay_create_buf() [+ + +]
Author: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
Date:   Tue Nov 29 09:23:38 2022 +0000

    relay: fix type mismatch when allocating memory in relay_create_buf()
    
    [ Upstream commit 4d8586e04602fe42f0a782d2005956f8b6302678 ]
    
    The 'padding' field of the 'rchan_buf' structure is an array of 'size_t'
    elements, but the memory is allocated for an array of 'size_t *' elements.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Link: https://lkml.kernel.org/r/20221129092002.3538384-1-Ilia.Gavrilov@infotecs.ru
    Fixes: b86ff981a825 ("[PATCH] relay: migrate from relayfs to a generic relay API")
    Signed-off-by: Ilia.Gavrilov <Ilia.Gavrilov@infotecs.ru>
    Cc: Colin Ian King <colin.i.king@gmail.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: wuchi <wuchi.zero@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
remoteproc: qcom_q6v5_pas: Fix missing of_node_put() in adsp_alloc_memory_region() [+ + +]
Author: Yuan Can <yuancan@huawei.com>
Date:   Sat Dec 3 07:06:39 2022 +0000

    remoteproc: qcom_q6v5_pas: Fix missing of_node_put() in adsp_alloc_memory_region()
    
    [ Upstream commit 38e7d9c19276832ebb0277f415b9214bf7baeb37 ]
    
    The pointer node is returned by of_parse_phandle() with refcount
    incremented. We should use of_node_put() on it when done.
    
    Fixes: b9e718e950c3 ("remoteproc: Introduce Qualcomm ADSP PIL")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221203070639.15128-1-yuancan@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

remoteproc: sysmon: fix memory leak in qcom_add_sysmon_subdev() [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Tue Nov 29 18:56:50 2022 +0800

    remoteproc: sysmon: fix memory leak in qcom_add_sysmon_subdev()
    
    [ Upstream commit e01ce676aaef3b13d02343d7e70f9637d93a3367 ]
    
    The kfree() should be called when of_irq_get_byname() fails or
    devm_request_threaded_irq() fails in qcom_add_sysmon_subdev(),
    otherwise there will be a memory leak, so add kfree() to fix it.
    
    Fixes: 027045a6e2b7 ("remoteproc: qcom: Add shutdown-ack irq")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221129105650.1539187-1-cuigaosheng1@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "usb: ulpi: defer ulpi_register on ulpi_read_id timeout" [+ + +]
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Thu Dec 22 21:53:02 2022 +0100

    Revert "usb: ulpi: defer ulpi_register on ulpi_read_id timeout"
    
    commit b659b613cea2ae39746ca8bd2b69d1985dd9d770 upstream.
    
    This reverts commit 8a7b31d545d3a15f0e6f5984ae16f0ca4fd76aac.
    
    This patch results in some qemu test failures, specifically xilinx-zynq-a9
    machine and zynq-zc702 as well as zynq-zed devicetree files, when trying
    to boot from USB drive.
    
    Link: https://lore.kernel.org/lkml/20221220194334.GA942039@roeck-us.net/
    Fixes: 8a7b31d545d3 ("usb: ulpi: defer ulpi_register on ulpi_read_id timeout")
    Cc: stable@vger.kernel.org
    Reported-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
    Link: https://lore.kernel.org/r/20221222205302.45761-1-ftoth@exalondelft.nl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
riscv: uaccess: fix type of 0 variable on error in get_user() [+ + +]
Author: Ben Dooks <ben-linux@fluff.org>
Date:   Thu Dec 29 17:05:45 2022 +0000

    riscv: uaccess: fix type of 0 variable on error in get_user()
    
    commit b9b916aee6715cd7f3318af6dc360c4729417b94 upstream.
    
    If the get_user(x, ptr) has x as a pointer, then the setting
    of (x) = 0 is going to produce the following sparse warning,
    so fix this by forcing the type of 'x' when access_ok() fails.
    
    fs/aio.c:2073:21: warning: Using plain integer as NULL pointer
    
    Signed-off-by: Ben Dooks <ben-linux@fluff.org>
    Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
    Link: https://lore.kernel.org/r/20221229170545.718264-1-ben-linux@fluff.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rtc: mxc_v2: Add missing clk_disable_unprepare() [+ + +]
Author: GUO Zihua <guozihua@huawei.com>
Date:   Tue Nov 22 16:50:46 2022 +0800

    rtc: mxc_v2: Add missing clk_disable_unprepare()
    
    [ Upstream commit 55d5a86618d3b1a768bce01882b74cbbd2651975 ]
    
    The call to clk_disable_unprepare() is left out in the error handling of
    devm_rtc_allocate_device. Add it back.
    
    Fixes: 5490a1e018a4 ("rtc: mxc_v2: fix possible race condition")
    Signed-off-by: GUO Zihua <guozihua@huawei.com>
    Link: https://lore.kernel.org/r/20221122085046.21689-1-guozihua@huawei.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rtc: pcf85063: Fix reading alarm [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Wed Sep 21 09:41:41 2022 +0200

    rtc: pcf85063: Fix reading alarm
    
    [ Upstream commit a6ceee26fd5ed9b5bd37322b1ca88e4548cee4a3 ]
    
    If the alarms are disabled the topmost bit (AEN_*) is set in the alarm
    registers. This is also interpreted in BCD number leading to this warning:
    rtc rtc0: invalid alarm value: 2022-09-21T80:80:80
    
    Fix this by masking alarm enabling and reserved bits.
    
    Fixes: 05cb3a56ee8c ("rtc: pcf85063: add alarm support")
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Link: https://lore.kernel.org/r/20220921074141.3903104-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rtc: pic32: Move devm_rtc_allocate_device earlier in pic32_rtc_probe() [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Wed Nov 23 09:59:53 2022 +0800

    rtc: pic32: Move devm_rtc_allocate_device earlier in pic32_rtc_probe()
    
    [ Upstream commit 90cd5c88830140c9fade92a8027e0fb2c6e4cc49 ]
    
    The pic32_rtc_enable(pdata, 0) and clk_disable_unprepare(pdata->clk)
    should be called in the error handling of devm_rtc_allocate_device(),
    so we should move devm_rtc_allocate_device earlier in pic32_rtc_probe()
    to fix it.
    
    Fixes: 6515e23b9fde ("rtc: pic32: convert to devm_rtc_allocate_device")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221123015953.1998521-1-cuigaosheng1@huawei.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rtc: snvs: Allow a time difference on clock register read [+ + +]
Author: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Date:   Sun Nov 6 12:59:15 2022 +0100

    rtc: snvs: Allow a time difference on clock register read
    
    [ Upstream commit 0462681e207ccc44778a77b3297af728b1cf5b9f ]
    
    On an iMX6ULL the following message appears when a wakealarm is set:
    
    echo 0 > /sys/class/rtc/rtc1/wakealarm
    rtc rtc1: Timeout trying to get valid LPSRT Counter read
    
    This does not always happen but is reproducible quite often (7 out of 10
    times). The problem appears because the iMX6ULL is not able to read the
    registers within one 32kHz clock cycle which is the base clock of the
    RTC. Therefore, this patch allows a difference of up to 320 cycles
    (10ms). 10ms was chosen to be big enough even on systems with less cpu
    power (e.g. iMX6ULL). According to the reference manual a difference is
    fine:
    - If the two consecutive reads are similar, the value is correct.
    The values have to be similar, not equal.
    
    Fixes: cd7f3a249dbe ("rtc: snvs: Add timeouts to avoid kernel lockups")
    Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
    Signed-off-by: Francesco Dolcini <francesco@dolcini.it>
    Link: https://lore.kernel.org/r/20221106115915.7930-1-francesco@dolcini.it
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rtc: st-lpc: Add missing clk_disable_unprepare in st_rtc_probe() [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Wed Nov 23 09:48:05 2022 +0800

    rtc: st-lpc: Add missing clk_disable_unprepare in st_rtc_probe()
    
    [ Upstream commit 5fb733d7bd6949e90028efdce8bd528c6ab7cf1e ]
    
    The clk_disable_unprepare() should be called in the error handling
    of clk_get_rate(), fix it.
    
    Fixes: b5b2bdfc2893 ("rtc: st: Add new driver for ST's LPC RTC")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221123014805.1993052-1-cuigaosheng1@huawei.com
    Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
rxrpc: Fix ack.bufferSize to be 0 when generating an ack [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Wed Sep 7 19:17:29 2022 +0100

    rxrpc: Fix ack.bufferSize to be 0 when generating an ack
    
    [ Upstream commit 8889a711f9b4dcf4dd1330fa493081beebd118c9 ]
    
    ack.bufferSize should be set to 0 when generating an ack.
    
    Fixes: 8d94aa381dab ("rxrpc: Calls shouldn't hold socket refs")
    Reported-by: Jeffrey Altman <jaltman@auristor.com>
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

rxrpc: Fix missing unlock in rxrpc_do_sendmsg() [+ + +]
Author: David Howells <dhowells@redhat.com>
Date:   Thu Dec 15 16:19:47 2022 +0000

    rxrpc: Fix missing unlock in rxrpc_do_sendmsg()
    
    [ Upstream commit 4feb2c44629e6f9b459b41a5a60491069d346a95 ]
    
    One of the error paths in rxrpc_do_sendmsg() doesn't unlock the call mutex
    before returning.  Fix it to do this.
    
    Note that this still doesn't get rid of the checker warning:
    
       ../net/rxrpc/sendmsg.c:617:5: warning: context imbalance in 'rxrpc_do_sendmsg' - wrong count at exit
    
    I think the interplay between the socket lock and the call's user_mutex may
    be too complicated for checker to analyse, especially as
    rxrpc_new_client_call_for_sendmsg(), which it calls, returns with the
    call's user_mutex if successful but unconditionally drops the socket lock.
    
    Fixes: e754eba685aa ("rxrpc: Provide a cmsg to specify the amount of Tx data for a call")
    Signed-off-by: David Howells <dhowells@redhat.com>
    cc: Marc Dionne <marc.dionne@auristor.com>
    cc: linux-afs@lists.infradead.org
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/ctcm: Fix return type of ctc{mp,}m_tx() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Thu Nov 3 10:01:28 2022 -0700

    s390/ctcm: Fix return type of ctc{mp,}m_tx()
    
    [ Upstream commit aa5bf80c3c067b82b4362cd6e8e2194623bcaca6 ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed. A
    proposed warning in clang aims to catch these at compile time, which
    reveals:
    
      drivers/s390/net/ctcm_main.c:1064:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .ndo_start_xmit         = ctcm_tx,
                                        ^~~~~~~
      drivers/s390/net/ctcm_main.c:1072:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .ndo_start_xmit         = ctcmpc_tx,
                                        ^~~~~~~~~
    
    ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
    'netdev_tx_t', not 'int'. Adjust the return type of ctc{mp,}m_tx() to
    match the prototype's to resolve the warning and potential CFI failure,
    should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.
    
    Additionally, while in the area, remove a comment block that is no
    longer relevant.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1750
    Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/kexec: fix ipl report address for kdump [+ + +]
Author: Alexander Egorenkov <egorenar@linux.ibm.com>
Date:   Mon Nov 14 11:40:08 2022 +0100

    s390/kexec: fix ipl report address for kdump
    
    commit c2337a40e04dde1692b5b0a46ecc59f89aaba8a1 upstream.
    
    This commit addresses the following erroneous situation with file-based
    kdump executed on a system with a valid IPL report.
    
    On s390, a kdump kernel, its initrd and IPL report if present are loaded
    into a special and reserved on boot memory region - crashkernel. When
    a system crashes and kdump was activated before, the purgatory code
    is entered first which swaps the crashkernel and [0 - crashkernel size]
    memory regions. Only after that the kdump kernel is entered. For this
    reason, the pointer to an IPL report in lowcore must point to the IPL report
    after the swap and not to the address of the IPL report that was located in
    crashkernel memory region before the swap. Failing to do so, makes the
    kdump's decompressor try to read memory from the crashkernel memory region
    which already contains the production's kernel memory.
    
    The situation described above caused spontaneous kdump failures/hangs
    on systems where the Secure IPL is activated because on such systems
    an IPL report is always present. In that case kdump's decompressor tried
    to parse an IPL report which frequently lead to illegal memory accesses
    because an IPL report contains addresses to various data.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 99feaa717e55 ("s390/kexec_file: Create ipl report and pass to next kernel")
    Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/lcs: Fix return type of lcs_start_xmit() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Thu Nov 3 10:01:30 2022 -0700

    s390/lcs: Fix return type of lcs_start_xmit()
    
    [ Upstream commit bb16db8393658e0978c3f0d30ae069e878264fa3 ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed. A
    proposed warning in clang aims to catch these at compile time, which
    reveals:
    
      drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .ndo_start_xmit         = lcs_start_xmit,
                                        ^~~~~~~~~~~~~~
      drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .ndo_start_xmit         = lcs_start_xmit,
                                        ^~~~~~~~~~~~~~
    
    ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
    'netdev_tx_t', not 'int'. Adjust the return type of lcs_start_xmit() to
    match the prototype's to resolve the warning and potential CFI failure,
    should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1750
    Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/netiucv: Fix return type of netiucv_tx() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Thu Nov 3 10:01:29 2022 -0700

    s390/netiucv: Fix return type of netiucv_tx()
    
    [ Upstream commit 88d86d18d7cf7e9137c95f9d212bb9fff8a1b4be ]
    
    With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
    indirect call targets are validated against the expected function
    pointer prototype to make sure the call target is valid to help mitigate
    ROP attacks. If they are not identical, there is a failure at run time,
    which manifests as either a kernel panic or thread getting killed. A
    proposed warning in clang aims to catch these at compile time, which
    reveals:
    
      drivers/s390/net/netiucv.c:1854:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
              .ndo_start_xmit         = netiucv_tx,
                                        ^~~~~~~~~~
    
    ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
    'netdev_tx_t', not 'int'. Adjust the return type of netiucv_tx() to
    match the prototype's to resolve the warning and potential CFI failure,
    should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.
    
    Additionally, while in the area, remove a comment block that is no
    longer relevant.
    
    Link: https://github.com/ClangBuiltLinux/linux/issues/1750
    Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple() [+ + +]
Author: Heiko Carstens <hca@linux.ibm.com>
Date:   Mon Jan 9 11:51:20 2023 +0100

    s390/percpu: add READ_ONCE() to arch_this_cpu_to_op_simple()
    
    commit e3f360db08d55a14112bd27454e616a24296a8b0 upstream.
    
    Make sure that *ptr__ within arch_this_cpu_to_op_simple() is only
    dereferenced once by using READ_ONCE(). Otherwise the compiler could
    generate incorrect code.
    
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
samples: vfio-mdev: Fix missing pci_disable_device() in mdpy_fb_probe() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Thu Dec 8 09:33:41 2022 +0800

    samples: vfio-mdev: Fix missing pci_disable_device() in mdpy_fb_probe()
    
    [ Upstream commit d1f0f50fbbbbca1e3e8157e51934613bf88f6d44 ]
    
    Add missing pci_disable_device() in fail path of mdpy_fb_probe().
    Besides, fix missing release functions in mdpy_fb_remove().
    
    Fixes: cacade1946a4 ("sample: vfio mdev display - guest driver")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Link: https://lore.kernel.org/r/20221208013341.3999-1-shangxiaojing@huawei.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scsi: fcoe: Fix possible name leak when device_register() fails [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Sat Nov 12 17:43:10 2022 +0800

    scsi: fcoe: Fix possible name leak when device_register() fails
    
    [ Upstream commit 47b6a122c7b69a876c7ee2fc064a26b09627de9d ]
    
    If device_register() returns an error, the name allocated by dev_set_name()
    needs to be freed. As the comment of device_register() says, one should use
    put_device() to give up the reference in the error path. Fix this by
    calling put_device(), then the name can be freed in kobject_cleanup().
    
    The 'fcf' is freed in fcoe_fcf_device_release(), so the kfree() in the
    error path can be removed.
    
    The 'ctlr' is freed in fcoe_ctlr_device_release(), so don't use the error
    label, just return NULL after calling put_device().
    
    Fixes: 9a74e884ee71 ("[SCSI] libfcoe: Add fcoe_sysfs")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221112094310.3633291-1-yangyingliang@huawei.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Tue Nov 15 17:24:42 2022 +0800

    scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails
    
    [ Upstream commit 4155658cee394b22b24c6d64e49247bf26d95b92 ]
    
    fcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when
    fcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed
    &fcoe_sw_transport on fcoe_transports list. This causes panic when
    reinserting module.
    
     BUG: unable to handle page fault for address: fffffbfff82e2213
     RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe]
     Call Trace:
      <TASK>
      do_one_initcall+0xd0/0x4e0
      load_module+0x5eee/0x7210
      ...
    
    Fixes: 78a582463c1e ("[SCSI] fcoe: convert fcoe.ko to become an fcoe transport provider driver")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Link: https://lore.kernel.org/r/20221115092442.133088-1-chenzhongjin@huawei.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: hpsa: Fix error handling in hpsa_add_sas_host() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Thu Nov 10 23:11:29 2022 +0800

    scsi: hpsa: Fix error handling in hpsa_add_sas_host()
    
    [ Upstream commit 4ef174a3ad9b5d73c1b6573e244ebba2b0d86eac ]
    
    hpsa_sas_port_add_phy() does:
      ...
      sas_phy_add()  -> may return error here
      sas_port_add_phy()
      ...
    
    Whereas hpsa_free_sas_phy() does:
      ...
      sas_port_delete_phy()
      sas_phy_delete()
      ...
    
    If hpsa_sas_port_add_phy() returns an error, hpsa_free_sas_phy() can not be
    called to free the memory because the port and the phy have not been added
    yet.
    
    Replace hpsa_free_sas_phy() with sas_phy_free() and kfree() to avoid kernel
    crash in this case.
    
    Fixes: d04e62b9d63a ("hpsa: add in sas transport class")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221110151129.394389-1-yangyingliang@huawei.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: hpsa: Fix possible memory leak in hpsa_add_sas_device() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Fri Nov 11 12:30:12 2022 +0800

    scsi: hpsa: Fix possible memory leak in hpsa_add_sas_device()
    
    [ Upstream commit fda34a5d304d0b98cc967e8763b52221b66dc202 ]
    
    If hpsa_sas_port_add_rphy() returns an error, the 'rphy' allocated in
    sas_end_device_alloc() needs to be freed. Address this by calling
    sas_rphy_free() in the error path.
    
    Fixes: d04e62b9d63a ("hpsa: add in sas transport class")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221111043012.1074466-1-yangyingliang@huawei.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: hpsa: Fix possible memory leak in hpsa_init_one() [+ + +]
Author: Yuan Can <yuancan@huawei.com>
Date:   Tue Nov 22 01:57:51 2022 +0000

    scsi: hpsa: Fix possible memory leak in hpsa_init_one()
    
    [ Upstream commit 9c9ff300e0de07475796495d86f449340d454a0c ]
    
    The hpda_alloc_ctlr_info() allocates h and its field reply_map. However, in
    hpsa_init_one(), if alloc_percpu() failed, the hpsa_init_one() jumps to
    clean1 directly, which frees h and leaks the h->reply_map.
    
    Fix by calling hpda_free_ctlr_info() to release h->replay_map and h instead
    free h directly.
    
    Fixes: 8b834bff1b73 ("scsi: hpsa: fix selection of reply queue")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Link: https://lore.kernel.org/r/20221122015751.87284-1-yuancan@huawei.com
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: ipr: Fix WARNING in ipr_init() [+ + +]
Author: Shang XiaoJing <shangxiaojing@huawei.com>
Date:   Sun Nov 13 14:45:13 2022 +0800

    scsi: ipr: Fix WARNING in ipr_init()
    
    [ Upstream commit e6f108bffc3708ddcff72324f7d40dfcd0204894 ]
    
    ipr_init() will not call unregister_reboot_notifier() when
    pci_register_driver() fails, which causes a WARNING. Call
    unregister_reboot_notifier() when pci_register_driver() fails.
    
    notifier callback ipr_halt [ipr] already registered
    WARNING: CPU: 3 PID: 299 at kernel/notifier.c:29
    notifier_chain_register+0x16d/0x230
    Modules linked in: ipr(+) xhci_pci_renesas xhci_hcd ehci_hcd usbcore
    led_class gpu_sched drm_buddy video wmi drm_ttm_helper ttm
    drm_display_helper drm_kms_helper drm drm_panel_orientation_quirks
    agpgart cfbft
    CPU: 3 PID: 299 Comm: modprobe Tainted: G        W
    6.1.0-rc1-00190-g39508d23b672-dirty #332
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
    RIP: 0010:notifier_chain_register+0x16d/0x230
    Call Trace:
     <TASK>
     __blocking_notifier_chain_register+0x73/0xb0
     ipr_init+0x30/0x1000 [ipr]
     do_one_initcall+0xdb/0x480
     do_init_module+0x1cf/0x680
     load_module+0x6a50/0x70a0
     __do_sys_finit_module+0x12f/0x1c0
     do_syscall_64+0x3f/0x90
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: f72919ec2bbb ("[SCSI] ipr: implement shutdown changes and remove obsolete write cache parameter")
    Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
    Link: https://lore.kernel.org/r/20221113064513.14028-1-shangxiaojing@huawei.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Wed Nov 9 11:24:03 2022 +0800

    scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()
    
    [ Upstream commit 78316e9dfc24906dd474630928ed1d3c562b568e ]
    
    In mpt3sas_transport_port_add(), if sas_rphy_add() returns error,
    sas_rphy_free() needs be called to free the resource allocated in
    sas_end_device_alloc(). Otherwise a kernel crash will happen:
    
    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108
    CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G        W          6.1.0-rc1+ #189
    pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : device_del+0x54/0x3d0
    lr : device_del+0x37c/0x3d0
    Call trace:
     device_del+0x54/0x3d0
     attribute_container_class_device_del+0x28/0x38
     transport_remove_classdev+0x6c/0x80
     attribute_container_device_trigger+0x108/0x110
     transport_remove_device+0x28/0x38
     sas_rphy_remove+0x50/0x78 [scsi_transport_sas]
     sas_port_delete+0x30/0x148 [scsi_transport_sas]
     do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]
     device_for_each_child+0x68/0xb0
     sas_remove_children+0x30/0x50 [scsi_transport_sas]
     sas_rphy_remove+0x38/0x78 [scsi_transport_sas]
     sas_port_delete+0x30/0x148 [scsi_transport_sas]
     do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]
     device_for_each_child+0x68/0xb0
     sas_remove_children+0x30/0x50 [scsi_transport_sas]
     sas_remove_host+0x20/0x38 [scsi_transport_sas]
     scsih_remove+0xd8/0x420 [mpt3sas]
    
    Because transport_add_device() is not called when sas_rphy_add() fails, the
    device is not added. When sas_rphy_remove() is subsequently called to
    remove the device in the remove() path, a NULL pointer dereference happens.
    
    Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221109032403.1636422-1-yangyingliang@huawei.com
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: scsi_debug: Fix a warning in resp_write_scat() [+ + +]
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Fri Nov 11 02:05:25 2022 -0800

    scsi: scsi_debug: Fix a warning in resp_write_scat()
    
    [ Upstream commit 216e179724c1d9f57a8ababf8bd7aaabef67f01b ]
    
    As 'lbdof_blen' is coming from user, if the size in kzalloc() is >=
    MAX_ORDER then we hit a warning.
    
    Call trace:
    
    sg_ioctl
     sg_ioctl_common
       scsi_ioctl
        sg_scsi_ioctl
         blk_execute_rq
          blk_mq_sched_insert_request
           blk_mq_run_hw_queue
            __blk_mq_delay_run_hw_queue
             __blk_mq_run_hw_queue
              blk_mq_sched_dispatch_requests
               __blk_mq_sched_dispatch_requests
                blk_mq_dispatch_rq_list
                 scsi_queue_rq
                  scsi_dispatch_cmd
                   scsi_debug_queuecommand
                    schedule_resp
                     resp_write_scat
    
    If you try to allocate a memory larger than(>=) MAX_ORDER, then kmalloc()
    will definitely fail.  It creates a stack trace and messes up dmesg.  The
    user controls the size here so if they specify a too large size it will
    fail.
    
    Add __GFP_NOWARN in order to avoid too large allocation warning.  This is
    detected by static analysis using smatch.
    
    Fixes: 481b5e5c7949 ("scsi: scsi_debug: add resp_write_scat function")
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Link: https://lore.kernel.org/r/20221111100526.1790533-1-harshit.m.mogalapalli@oracle.com
    Acked-by: Douglas Gilbert <dgilbert@interlog.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: snic: Fix possible UAF in snic_tgt_create() [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Thu Nov 17 11:51:00 2022 +0800

    scsi: snic: Fix possible UAF in snic_tgt_create()
    
    [ Upstream commit e118df492320176af94deec000ae034cc92be754 ]
    
    Smatch reports a warning as follows:
    
    drivers/scsi/snic/snic_disc.c:307 snic_tgt_create() warn:
      '&tgt->list' not removed from list
    
    If device_add() fails in snic_tgt_create(), tgt will be freed, but
    tgt->list will not be removed from snic->disc.tgt_list, then list traversal
    may cause UAF.
    
    Remove from snic->disc.tgt_list before free().
    
    Fixes: c8806b6c9e82 ("snic: driver for Cisco SCSI HBA")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221117035100.2944812-1-cuigaosheng1@huawei.com
    Acked-by: Narsimhulu Musini <nmusini@cisco.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/efivarfs: Add checking of the test return value [+ + +]
Author: Zhao Gongyi <zhaogongyi@huawei.com>
Date:   Tue Nov 22 19:26:26 2022 +0800

    selftests/efivarfs: Add checking of the test return value
    
    [ Upstream commit c93924267fe6f2b44af1849f714ae9cd8117a9cd ]
    
    Add checking of the test return value, otherwise it will report success
    forever for test_create_read().
    
    Fixes: dff6d2ae56d0 ("selftests/efivarfs: clean up test files from test_create*()")
    Signed-off-by: Zhao Gongyi <zhaogongyi@huawei.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/ftrace: event_triggers: wait longer for test_event_enable [+ + +]
Author: Yipeng Zou <zouyipeng@huawei.com>
Date:   Fri Nov 4 10:09:31 2022 +0800

    selftests/ftrace: event_triggers: wait longer for test_event_enable
    
    [ Upstream commit a1d6cd88c8973cfb08ee85722488b1d6d5d16327 ]
    
    In some platform, the schedule event may came slowly, delay 100ms can't
    cover it.
    
    I was notice that on my board which running in low cpu_freq,and this
    selftests allways gose fail.
    
    So maybe we can check more times here to wait longer.
    
    Fixes: 43bb45da82f9 ("selftests: ftrace: Add a selftest to test event enable/disable func trigger")
    Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests/powerpc: Fix resource leaks [+ + +]
Author: Miaoqian Lin <linmq006@gmail.com>
Date:   Mon Dec 5 12:44:27 2022 +0400

    selftests/powerpc: Fix resource leaks
    
    [ Upstream commit 8f4ab7da904ab7027ccd43ddb4f0094e932a5877 ]
    
    In check_all_cpu_dscr_defaults, opendir() opens the directory stream.
    Add missing closedir() in the error path to release it.
    
    In check_cpu_dscr_default, open() creates an open file descriptor.
    Add missing close() in the error path to release it.
    
    Fixes: ebd5858c904b ("selftests/powerpc: Add test for all DSCR sysfs interfaces")
    Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20221205084429.570654-1-linmq006@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: Fix kselftest O=objdir build from cluttering top level objdir [+ + +]
Author: Shuah Khan <skhan@linuxfoundation.org>
Date:   Wed Feb 26 15:54:49 2020 -0700

    selftests: Fix kselftest O=objdir build from cluttering top level objdir
    
    commit 29e911ef7b706215caf02a82b0d3076611d6abe8 upstream.
    
    make kselftest-all O=objdir builds create generated objects in objdir.
    This clutters the top level directory with kselftest objects. Fix it
    to create sub-directory under objdir for kselftest objects.
    
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Tyler Hicks (Microsoft) <code@tyhicks.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: set the BUILD variable to absolute path [+ + +]
Author: Muhammad Usama Anjum <usama.anjum@collabora.com>
Date:   Wed Jan 19 15:15:22 2022 +0500

    selftests: set the BUILD variable to absolute path
    
    commit 5ad51ab618de5d05f4e692ebabeb6fe6289aaa57 upstream.
    
    The build of kselftests fails if relative path is specified through
    KBUILD_OUTPUT or O=<path> method. BUILD variable is used to determine
    the path of the output objects. When make is run from other directories
    with relative paths, the exact path of the build objects is ambiguous
    and build fails.
    
            make[1]: Entering directory '/home/usama/repos/kernel/linux_mainline2/tools/testing/selftests/alsa'
            gcc     mixer-test.c -L/usr/lib/x86_64-linux-gnu -lasound  -o build/kselftest/alsa/mixer-test
            /usr/bin/ld: cannot open output file build/kselftest/alsa/mixer-test
    
    Set the BUILD variable to the absolute path of the output directory.
    Make the logic readable and easy to follow. Use spaces instead of tabs
    for indentation as if with tab indentation is considered recipe in make.
    
    Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Tyler Hicks (Microsoft) <code@tyhicks.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

selftests: Use optional USERCFLAGS and USERLDFLAGS [+ + +]
Author: Mickaël Salaün <mic@digikod.net>
Date:   Fri Sep 9 12:39:01 2022 +0200

    selftests: Use optional USERCFLAGS and USERLDFLAGS
    
    commit de3ee3f63400a23954e7c1ad1cb8c20f29ab6fe3 upstream.
    
    This change enables to extend CFLAGS and LDFLAGS from command line, e.g.
    to extend compiler checks: make USERCFLAGS=-Werror USERLDFLAGS=-static
    
    USERCFLAGS and USERLDFLAGS are documented in
    Documentation/kbuild/makefiles.rst and Documentation/kbuild/kbuild.rst
    
    This should be backported (down to 5.10) to improve previous kernel
    versions testing as well.
    
    Cc: Shuah Khan <skhan@linuxfoundation.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mickaël Salaün <mic@digikod.net>
    Link: https://lore.kernel.org/r/20220909103901.1503436-1-mic@digikod.net
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
serial: altera_uart: fix locking in polling mode [+ + +]
Author: Gabriel Somlo <gsomlo@gmail.com>
Date:   Tue Nov 22 15:04:26 2022 -0500

    serial: altera_uart: fix locking in polling mode
    
    [ Upstream commit 1307c5d33cce8a41dd77c2571e4df65a5b627feb ]
    
    Since altera_uart_interrupt() may also be called from
    a poll timer in "serving_softirq" context, use
    spin_[lock_irqsave|unlock_irqrestore] variants, which
    are appropriate for both softirq and hardware interrupt
    contexts.
    
    Fixes: 2f8b9c15cd88 ("altera_uart: Add support for polling mode (IRQ-less)")
    Signed-off-by: Gabriel Somlo <gsomlo@gmail.com>
    Link: https://lore.kernel.org/r/20221122200426.888349-1-gsomlo@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: amba-pl011: avoid SBSA UART accessing DMACR register [+ + +]
Author: Jiamei Xie <jiamei.xie@arm.com>
Date:   Thu Nov 17 18:32:37 2022 +0800

    serial: amba-pl011: avoid SBSA UART accessing DMACR register
    
    [ Upstream commit 94cdb9f33698478b0e7062586633c42c6158a786 ]
    
    Chapter "B Generic UART" in "ARM Server Base System Architecture" [1]
    documentation describes a generic UART interface. Such generic UART
    does not support DMA. In current code, sbsa_uart_pops and
    amba_pl011_pops share the same stop_rx operation, which will invoke
    pl011_dma_rx_stop, leading to an access of the DMACR register. This
    commit adds a using_rx_dma check in pl011_dma_rx_stop to avoid the
    access to DMACR register for SBSA UARTs which does not support DMA.
    
    When the kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", Linux
    SBSA PL011 driver will access PL011 DMACR register in some functions.
    For most real SBSA Pl011 hardware implementations, the DMACR write
    behaviour will be ignored. So these DMACR operations will not cause
    obvious problems. But for some virtual SBSA PL011 hardware, like Xen
    virtual SBSA PL011 (vpl011) device, the behaviour might be different.
    Xen vpl011 emulation will inject a data abort to guest, when guest is
    accessing an unimplemented UART register. As Xen VPL011 is SBSA
    compatible, it will not implement DMACR register. So when Linux SBSA
    PL011 driver access DMACR register, it will get an unhandled data abort
    fault and the application will get a segmentation fault:
    Unhandled fault at 0xffffffc00944d048
    Mem abort info:
      ESR = 0x96000000
      EC = 0x25: DABT (current EL), IL = 32 bits
      SET = 0, FnV = 0
      EA = 0, S1PTW = 0
      FSC = 0x00: ttbr address size fault
    Data abort info:
      ISV = 0, ISS = 0x00000000
      CM = 0, WnR = 0
    swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000
    [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13
    Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP
    ...
    Call trace:
     pl011_stop_rx+0x70/0x80
     tty_port_shutdown+0x7c/0xb4
     tty_port_close+0x60/0xcc
     uart_close+0x34/0x8c
     tty_release+0x144/0x4c0
     __fput+0x78/0x220
     ____fput+0x1c/0x30
     task_work_run+0x88/0xc0
     do_notify_resume+0x8d0/0x123c
     el0_svc+0xa8/0xc0
     el0t_64_sync_handler+0xa4/0x130
     el0t_64_sync+0x1a0/0x1a4
    Code: b9000083 b901f001 794038a0 8b000042 (b9000041)
    ---[ end trace 83dd93df15c3216f ]---
    note: bootlogd[132] exited with preempt_count 1
    /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon
    
    This has been discussed in the Xen community, and we think it should fix
    this in Linux. See [2] for more information.
    
    [1] https://developer.arm.com/documentation/den0094/c/?lang=en
    [2] https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg00543.html
    
    Fixes: 0dd1e247fd39 (drivers: PL011: add support for the ARM SBSA generic UART)
    Signed-off-by: Jiamei Xie <jiamei.xie@arm.com>
    Reviewed-by: Andre Przywara <andre.przywara@arm.com>
    Link: https://lore.kernel.org/r/20221117103237.86856-1-jiamei.xie@arm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: pch: Fix PCI device refcount leak in pch_request_dma() [+ + +]
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Tue Nov 22 19:45:59 2022 +0800

    serial: pch: Fix PCI device refcount leak in pch_request_dma()
    
    [ Upstream commit 8be3a7bf773700534a6e8f87f6ed2ed111254be5 ]
    
    As comment of pci_get_slot() says, it returns a pci_device with its
    refcount increased. The caller must decrement the reference count by
    calling pci_dev_put().
    
    Since 'dma_dev' is only used to filter the channel in filter(), we can
    call pci_dev_put() before exiting from pch_request_dma(). Add the
    missing pci_dev_put() for the normal and error path.
    
    Fixes: 3c6a483275f4 ("Serial: EG20T: add PCH_UART driver")
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Link: https://lore.kernel.org/r/20221122114559.27692-1-wangxiongfeng2@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: pl011: Do not clear RX FIFO & RX interrupt in unthrottle. [+ + +]
Author: delisun <delisun@pateo.com.cn>
Date:   Thu Nov 10 10:01:08 2022 +0800

    serial: pl011: Do not clear RX FIFO & RX interrupt in unthrottle.
    
    [ Upstream commit 032d5a71ed378ffc6a2d41a187d8488a4f9fe415 ]
    
    Clearing the RX FIFO will cause data loss.
    Copy the pl011_enabl_interrupts implementation, and remove the clear
    interrupt and FIFO part of the code.
    
    Fixes: 211565b10099 ("serial: pl011: UPSTAT_AUTORTS requires .throttle/unthrottle")
    Signed-off-by: delisun <delisun@pateo.com.cn>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20221110020108.7700-1-delisun@pateo.com.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: sunsab: Fix error handling in sunsab_init() [+ + +]
Author: Yuan Can <yuancan@huawei.com>
Date:   Wed Nov 23 06:12:12 2022 +0000

    serial: sunsab: Fix error handling in sunsab_init()
    
    [ Upstream commit 1a6ec673fb627c26e2267ca0a03849f91dbd9b40 ]
    
    The sunsab_init() returns the platform_driver_register() directly without
    checking its return value, if platform_driver_register() failed, the
    allocated sunsab_ports is leaked.
    Fix by free sunsab_ports and set it to NULL when platform_driver_register()
    failed.
    
    Fixes: c4d37215a824 ("[SERIAL] sunsab: Convert to of_driver framework.")
    Signed-off-by: Yuan Can <yuancan@huawei.com>
    Link: https://lore.kernel.org/r/20221123061212.52593-1-yuancan@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: tegra: Read DMA status before terminating [+ + +]
Author: Kartik <kkartik@nvidia.com>
Date:   Tue Oct 18 20:28:06 2022 +0530

    serial: tegra: Read DMA status before terminating
    
    [ Upstream commit 109a951a9f1fd8a34ebd1896cbbd5d5cede880a7 ]
    
    Read the DMA status before terminating the DMA, as doing so deletes
    the DMA desc.
    
    Also, to get the correct transfer status information, pause the DMA
    using dmaengine_pause() before reading the DMA status.
    
    Fixes: e9ea096dd225 ("serial: tegra: add serial driver")
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Acked-by: Thierry Reding <treding@nvidia.com>
    Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
    Signed-off-by: Kartik <kkartik@nvidia.com>
    Link: https://lore.kernel.org/r/1666105086-17326-1-git-send-email-kkartik@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
skbuff: Account for tail adjustment during pull operations [+ + +]
Author: Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com>
Date:   Wed Dec 14 23:11:58 2022 -0700

    skbuff: Account for tail adjustment during pull operations
    
    [ Upstream commit 2d7afdcbc9d32423f177ee12b7c93783aea338fb ]
    
    Extending the tail can have some unexpected side effects if a program uses
    a helper like BPF_FUNC_skb_pull_data to read partial content beyond the
    head skb headlen when all the skbs in the gso frag_list are linear with no
    head_frag -
    
      kernel BUG at net/core/skbuff.c:4219!
      pc : skb_segment+0xcf4/0xd2c
      lr : skb_segment+0x63c/0xd2c
      Call trace:
       skb_segment+0xcf4/0xd2c
       __udp_gso_segment+0xa4/0x544
       udp4_ufo_fragment+0x184/0x1c0
       inet_gso_segment+0x16c/0x3a4
       skb_mac_gso_segment+0xd4/0x1b0
       __skb_gso_segment+0xcc/0x12c
       udp_rcv_segment+0x54/0x16c
       udp_queue_rcv_skb+0x78/0x144
       udp_unicast_rcv_skb+0x8c/0xa4
       __udp4_lib_rcv+0x490/0x68c
       udp_rcv+0x20/0x30
       ip_protocol_deliver_rcu+0x1b0/0x33c
       ip_local_deliver+0xd8/0x1f0
       ip_rcv+0x98/0x1a4
       deliver_ptype_list_skb+0x98/0x1ec
       __netif_receive_skb_core+0x978/0xc60
    
    Fix this by marking these skbs as GSO_DODGY so segmentation can handle
    the tail updates accordingly.
    
    Fixes: 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list")
    Signed-off-by: Sean Tranchetti <quic_stranche@quicinc.com>
    Signed-off-by: Subash Abhinov Kasiviswanathan <quic_subashab@quicinc.com>
    Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
    Link: https://lore.kernel.org/r/1671084718-24796-1-git-send-email-quic_subashab@quicinc.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
soc: qcom: Select REMAP_MMIO for LLCC driver [+ + +]
Author: Manivannan Sadhasivam <mani@kernel.org>
Date:   Tue Nov 29 12:41:59 2022 +0530

    soc: qcom: Select REMAP_MMIO for LLCC driver
    
    commit 5d2fe2d7b616b8baa18348ead857b504fc2de336 upstream.
    
    LLCC driver uses REGMAP_MMIO for accessing the hardware registers. So
    select the dependency in Kconfig. Without this, there will be errors
    while building the driver with COMPILE_TEST only:
    
    ERROR: modpost: "__devm_regmap_init_mmio_clk" [drivers/soc/qcom/llcc-qcom.ko] undefined!
    make[1]: *** [scripts/Makefile.modpost:126: Module.symvers] Error 1
    make: *** [Makefile:1944: modpost] Error 2
    
    Cc: <stable@vger.kernel.org> # 4.19
    Fixes: a3134fb09e0b ("drivers: soc: Add LLCC driver")
    Reported-by: Borislav Petkov <bp@alien8.de>
    Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Link: https://lore.kernel.org/r/20221129071201.30024-2-manivannan.sadhasivam@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

soc: ti: knav_qmss_queue: Fix PM disable depth imbalance in knav_queue_probe [+ + +]
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Tue Nov 8 16:03:21 2022 +0800

    soc: ti: knav_qmss_queue: Fix PM disable depth imbalance in knav_queue_probe
    
    [ Upstream commit e961c0f19450fd4a26bd043dd2979990bf12caf6 ]
    
    The pm_runtime_enable will increase power disable depth. Thus
    a pairing decrement is needed on the error handling path to
    keep it balanced according to context.
    
    Fixes: 41f93af900a2 ("soc: ti: add Keystone Navigator QMSS driver")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Link: https://lore.kernel.org/r/20221108080322.52268-2-zhangqilong3@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: ti: knav_qmss_queue: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync [+ + +]
Author: Minghao Chi <chi.minghao@zte.com.cn>
Date:   Mon Apr 18 06:29:55 2022 +0000

    soc: ti: knav_qmss_queue: Use pm_runtime_resume_and_get instead of pm_runtime_get_sync
    
    [ Upstream commit 12eeb74925da70eb39d90abead9de9793be3d4c8 ]
    
    Using pm_runtime_resume_and_get is more appropriate for simplifying
    code.
    
    Reported-by: Zeal Robot <zealci@zte.com.cn>
    Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Link: https://lore.kernel.org/r/20220418062955.2557949-1-chi.minghao@zte.com.cn
    Stable-dep-of: e961c0f19450 ("soc: ti: knav_qmss_queue: Fix PM disable depth imbalance in knav_queue_probe")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: ti: smartreflex: Fix PM disable depth imbalance in omap_sr_probe [+ + +]
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date:   Tue Nov 8 16:03:22 2022 +0800

    soc: ti: smartreflex: Fix PM disable depth imbalance in omap_sr_probe
    
    [ Upstream commit 69460e68eb662064ab4188d4e129ff31c1f23ed9 ]
    
    The pm_runtime_enable will increase power disable depth. Thus
    a pairing decrement is needed on the error handling path to
    keep it balanced according to context.
    
    Fixes: 984aa6dbf4ca ("OMAP3: PM: Adding smartreflex driver support.")
    Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Link: https://lore.kernel.org/r/20221108080322.52268-3-zhangqilong3@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
spi: spi-gpio: Don't set MOSI as an input if not 3WIRE mode [+ + +]
Author: Kris Bahnsen <kris@embeddedTS.com>
Date:   Wed Dec 7 15:08:53 2022 -0800

    spi: spi-gpio: Don't set MOSI as an input if not 3WIRE mode
    
    [ Upstream commit 3a6f994f848a69deb2bf3cd9d130dd0c09730e55 ]
    
    The addition of 3WIRE support would affect MOSI direction even
    when still in standard (4 wire) mode. This can lead to MOSI being
    at an invalid logic level when a device driver sets an SPI
    message with a NULL tx_buf.
    
    spi.h states that if tx_buf is NULL then "zeros will be shifted
    out ... " If MOSI is tristated then the data shifted out is subject
    to pull resistors, keepers, or in the absence of those, noise.
    
    This issue came to light when using spi-gpio connected to an
    ADS7843 touchscreen controller. MOSI pulled high when clocking
    MISO data in caused the SPI device to interpret this as a command
    which would put the device in an unexpected and non-functional
    state.
    
    Fixes: 4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support")
    Fixes: 5132b3d28371 ("spi: gpio: Support 3WIRE high-impedance turn-around")
    Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
    Link: https://lore.kernel.org/r/20221207230853.6174-1-kris@embeddedTS.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: spidev: mask SPI_CS_HIGH in SPI_IOC_RD_MODE [+ + +]
Author: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Date:   Wed Nov 30 17:29:27 2022 +0100

    spi: spidev: mask SPI_CS_HIGH in SPI_IOC_RD_MODE
    
    [ Upstream commit 7dbfa445ff7393d1c4c066c1727c9e0af1251958 ]
    
    Commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
    has changed the user-space interface so that bogus SPI_CS_HIGH started
    to appear in the mask returned by SPI_IOC_RD_MODE even for active-low CS
    pins. Commit 138c9c32f090
    ("spi: spidev: Fix CS polarity if GPIO descriptors are used") fixed only
    SPI_IOC_WR_MODE part of the problem. Let's fix SPI_IOC_RD_MODE
    symmetrically.
    
    Test case:
    
            #include <sys/ioctl.h>
            #include <fcntl.h>
            #include <linux/spi/spidev.h>
    
            int main(int argc, char **argv)
            {
                    char modew = SPI_CPHA;
                    char moder;
                    int f = open("/dev/spidev0.0", O_RDWR);
    
                    if (f < 0)
                            return 1;
    
                    ioctl(f, SPI_IOC_WR_MODE, &modew);
                    ioctl(f, SPI_IOC_RD_MODE, &moder);
    
                    return moder == modew ? 0 : 2;
            }
    
    Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
    Link: https://lore.kernel.org/r/20221130162927.539512-1-alexander.sverdlin@siemens.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

spi: Update reference to struct spi_controller [+ + +]
Author: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Date:   Tue Nov 1 18:32:51 2022 +0100

    spi: Update reference to struct spi_controller
    
    [ Upstream commit bf585ccee22faf469d82727cf375868105b362f7 ]
    
    struct spi_master has been renamed to struct spi_controller. Update the
    reference in spi.rst to make it clickable again.
    
    Fixes: 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
    Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
    Link: https://lore.kernel.org/r/20221101173252.1069294-1-j.neuschaefer@gmx.net
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
staging: rtl8192e: Fix potential use-after-free in rtllib_rx_Monitor() [+ + +]
Author: YueHaibing <yuehaibing@huawei.com>
Date:   Wed Nov 23 16:12:53 2022 +0800

    staging: rtl8192e: Fix potential use-after-free in rtllib_rx_Monitor()
    
    [ Upstream commit d30f4436f364b4ad915ca2c09be07cd0f93ceb44 ]
    
    The skb is delivered to netif_rx() in rtllib_monitor_rx(), which may free it,
    after calling this, dereferencing skb may trigger use-after-free.
    Found by Smatch.
    
    Fixes: 94a799425eee ("From: wlanfae <wlanfae@realtek.com> [PATCH 1/8] rtl8192e: Import new version of driver from realtek")
    Signed-off-by: YueHaibing <yuehaibing@huawei.com>
    Link: https://lore.kernel.org/r/20221123081253.22296-1-yuehaibing@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

staging: rtl8192u: Fix use after free in ieee80211_rx() [+ + +]
Author: Dan Carpenter <error27@gmail.com>
Date:   Wed Nov 23 09:43:14 2022 +0300

    staging: rtl8192u: Fix use after free in ieee80211_rx()
    
    [ Upstream commit bcc5e2dcf09089b337b76fc1a589f6ff95ca19ac ]
    
    We cannot dereference the "skb" pointer after calling
    ieee80211_monitor_rx(), because it is a use after free.
    
    Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging")
    Signed-off-by: Dan Carpenter <error27@gmail.com>
    Link: https://lore.kernel.org/r/Y33BArx3k/aw6yv/@kili
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

staging: vme_user: Fix possible UAF in tsi148_dma_list_add [+ + +]
Author: Gaosheng Cui <cuigaosheng1@huawei.com>
Date:   Thu Nov 17 11:59:14 2022 +0800

    staging: vme_user: Fix possible UAF in tsi148_dma_list_add
    
    [ Upstream commit 357057ee55d3c99a5de5abe8150f7bca04f8e53b ]
    
    Smatch report warning as follows:
    
    drivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn:
      '&entry->list' not removed from list
    
    In tsi148_dma_list_add(), the error path "goto err_dma" will not
    remove entry->list from list->entries, but entry will be freed,
    then list traversal may cause UAF.
    
    Fix by removeing it from list->entries before free().
    
    Fixes: b2383c90a9d6 ("vme: tsi148: fix first DMA item mapping")
    Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
    Link: https://lore.kernel.org/r/20221117035914.2954454-1-cuigaosheng1@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
stmmac: fix potential division by 0 [+ + +]
Author: Piergiorgio Beruto <piergiorgio.beruto@gmail.com>
Date:   Sat Dec 10 23:37:22 2022 +0100

    stmmac: fix potential division by 0
    
    [ Upstream commit ede5a389852d3640a28e7187fb32b7f204380901 ]
    
    When the MAC is connected to a 10 Mb/s PHY and the PTP clock is derived
    from the MAC reference clock (default), the clk_ptp_rate becomes too
    small and the calculated sub second increment becomes 0 when computed by
    the stmmac_config_sub_second_increment() function within
    stmmac_init_tstamp_counter().
    
    Therefore, the subsequent div_u64 in stmmac_init_tstamp_counter()
    operation triggers a divide by 0 exception as shown below.
    
    [   95.062067] socfpga-dwmac ff700000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
    [   95.076440] socfpga-dwmac ff700000.ethernet eth0: PHY [stmmac-0:08] driver [NCN26000] (irq=49)
    [   95.095964] dwmac1000: Master AXI performs any burst length
    [   95.101588] socfpga-dwmac ff700000.ethernet eth0: No Safety Features support found
    [   95.109428] Division by zero in kernel.
    [   95.113447] CPU: 0 PID: 239 Comm: ifconfig Not tainted 6.1.0-rc7-centurion3-1.0.3.0-01574-gb624218205b7-dirty #77
    [   95.123686] Hardware name: Altera SOCFPGA
    [   95.127695]  unwind_backtrace from show_stack+0x10/0x14
    [   95.132938]  show_stack from dump_stack_lvl+0x40/0x4c
    [   95.137992]  dump_stack_lvl from Ldiv0+0x8/0x10
    [   95.142527]  Ldiv0 from __aeabi_uidivmod+0x8/0x18
    [   95.147232]  __aeabi_uidivmod from div_u64_rem+0x1c/0x40
    [   95.152552]  div_u64_rem from stmmac_init_tstamp_counter+0xd0/0x164
    [   95.158826]  stmmac_init_tstamp_counter from stmmac_hw_setup+0x430/0xf00
    [   95.165533]  stmmac_hw_setup from __stmmac_open+0x214/0x2d4
    [   95.171117]  __stmmac_open from stmmac_open+0x30/0x44
    [   95.176182]  stmmac_open from __dev_open+0x11c/0x134
    [   95.181172]  __dev_open from __dev_change_flags+0x168/0x17c
    [   95.186750]  __dev_change_flags from dev_change_flags+0x14/0x50
    [   95.192662]  dev_change_flags from devinet_ioctl+0x2b4/0x604
    [   95.198321]  devinet_ioctl from inet_ioctl+0x1ec/0x214
    [   95.203462]  inet_ioctl from sock_ioctl+0x14c/0x3c4
    [   95.208354]  sock_ioctl from vfs_ioctl+0x20/0x38
    [   95.212984]  vfs_ioctl from sys_ioctl+0x250/0x844
    [   95.217691]  sys_ioctl from ret_fast_syscall+0x0/0x4c
    [   95.222743] Exception stack(0xd0ee1fa8 to 0xd0ee1ff0)
    [   95.227790] 1fa0:                   00574c4f be9aeca4 00000003 00008914 be9aeca4 be9aec50
    [   95.235945] 1fc0: 00574c4f be9aeca4 0059f078 00000036 be9aee8c be9aef7a 00000015 00000000
    [   95.244096] 1fe0: 005a01f0 be9aec38 004d7484 b6e67d74
    
    Signed-off-by: Piergiorgio Beruto <piergiorgio.beruto@gmail.com>
    Fixes: 91a2559c1dc5 ("net: stmmac: Fix sub-second increment")
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/de4c64ccac9084952c56a06a8171d738604c4770.1670678513.git.piergiorgio.beruto@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
SUNRPC: Don't leak netobj memory when gss_read_proxy_verf() fails [+ + +]
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Sat Nov 26 15:55:18 2022 -0500

    SUNRPC: Don't leak netobj memory when gss_read_proxy_verf() fails
    
    commit da522b5fe1a5f8b7c20a0023e87b52a150e53bf5 upstream.
    
    Fixes: 030d794bf498 ("SUNRPC: Use gssproxy upcall for server RPCGSS authentication.")
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

SUNRPC: ensure the matching upcall is in-flight upon downcall [+ + +]
Author: minoura makoto <minoura@valinux.co.jp>
Date:   Tue Dec 13 13:14:31 2022 +0900

    SUNRPC: ensure the matching upcall is in-flight upon downcall
    
    [ Upstream commit b18cba09e374637a0a3759d856a6bca94c133952 ]
    
    Commit 9130b8dbc6ac ("SUNRPC: allow for upcalls for the same uid
    but different gss service") introduced `auth` argument to
    __gss_find_upcall(), but in gss_pipe_downcall() it was left as NULL
    since it (and auth->service) was not (yet) determined.
    
    When multiple upcalls with the same uid and different service are
    ongoing, it could happen that __gss_find_upcall(), which returns the
    first match found in the pipe->in_downcall list, could not find the
    correct gss_msg corresponding to the downcall we are looking for.
    Moreover, it might return a msg which is not sent to rpc.gssd yet.
    
    We could see mount.nfs process hung in D state with multiple mount.nfs
    are executed in parallel.  The call trace below is of CentOS 7.9
    kernel-3.10.0-1160.24.1.el7.x86_64 but we observed the same hang w/
    elrepo kernel-ml-6.0.7-1.el7.
    
    PID: 71258  TASK: ffff91ebd4be0000  CPU: 36  COMMAND: "mount.nfs"
     #0 [ffff9203ca3234f8] __schedule at ffffffffa3b8899f
     #1 [ffff9203ca323580] schedule at ffffffffa3b88eb9
     #2 [ffff9203ca323590] gss_cred_init at ffffffffc0355818 [auth_rpcgss]
     #3 [ffff9203ca323658] rpcauth_lookup_credcache at ffffffffc0421ebc
    [sunrpc]
     #4 [ffff9203ca3236d8] gss_lookup_cred at ffffffffc0353633 [auth_rpcgss]
     #5 [ffff9203ca3236e8] rpcauth_lookupcred at ffffffffc0421581 [sunrpc]
     #6 [ffff9203ca323740] rpcauth_refreshcred at ffffffffc04223d3 [sunrpc]
     #7 [ffff9203ca3237a0] call_refresh at ffffffffc04103dc [sunrpc]
     #8 [ffff9203ca3237b8] __rpc_execute at ffffffffc041e1c9 [sunrpc]
     #9 [ffff9203ca323820] rpc_execute at ffffffffc0420a48 [sunrpc]
    
    The scenario is like this. Let's say there are two upcalls for
    services A and B, A -> B in pipe->in_downcall, B -> A in pipe->pipe.
    
    When rpc.gssd reads pipe to get the upcall msg corresponding to
    service B from pipe->pipe and then writes the response, in
    gss_pipe_downcall the msg corresponding to service A will be picked
    because only uid is used to find the msg and it is before the one for
    B in pipe->in_downcall.  And the process waiting for the msg
    corresponding to service A will be woken up.
    
    Actual scheduing of that process might be after rpc.gssd processes the
    next msg.  In rpc_pipe_generic_upcall it clears msg->errno (for A).
    The process is scheduled to see gss_msg->ctx == NULL and
    gss_msg->msg.errno == 0, therefore it cannot break the loop in
    gss_create_upcall and is never woken up after that.
    
    This patch adds a simple check to ensure that a msg which is not
    sent to rpc.gssd yet is not chosen as the matching upcall upon
    receiving a downcall.
    
    Signed-off-by: minoura makoto <minoura@valinux.co.jp>
    Signed-off-by: Hiroshi Shimamoto <h-shimamoto@nec.com>
    Tested-by: Hiroshi Shimamoto <h-shimamoto@nec.com>
    Cc: Trond Myklebust <trondmy@hammerspace.com>
    Fixes: 9130b8dbc6ac ("SUNRPC: allow for upcalls for same uid but different gss service")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

SUNRPC: Fix missing release socket in rpc_sockname() [+ + +]
Author: Wang ShaoBo <bobo.shaobowang@huawei.com>
Date:   Thu Nov 24 17:23:42 2022 +0800

    SUNRPC: Fix missing release socket in rpc_sockname()
    
    [ Upstream commit 50fa355bc0d75911fe9d5072a5ba52cdb803aff7 ]
    
    socket dynamically created is not released when getting an unintended
    address family type in rpc_sockname(), direct to out_release for calling
    sock_release().
    
    Fixes: 2e738fdce22f ("SUNRPC: Add API to acquire source address")
    Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
test_firmware: fix memory leak in test_firmware_init() [+ + +]
Author: Zhengchao Shao <shaozhengchao@huawei.com>
Date:   Sat Nov 19 11:57:21 2022 +0800

    test_firmware: fix memory leak in test_firmware_init()
    
    [ Upstream commit 7610615e8cdb3f6f5bbd9d8e7a5d8a63e3cabf2e ]
    
    When misc_register() failed in test_firmware_init(), the memory pointed
    by test_fw_config->name is not released. The memory leak information is
    as follows:
    unreferenced object 0xffff88810a34cb00 (size 32):
      comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s)
      hex dump (first 32 bytes):
        74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69  test-firmware.bi
        6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  n...............
      backtrace:
        [<ffffffff81b21fcb>] __kmalloc_node_track_caller+0x4b/0xc0
        [<ffffffff81affb96>] kstrndup+0x46/0xc0
        [<ffffffffa0403a49>] __test_firmware_config_init+0x29/0x380 [test_firmware]
        [<ffffffffa040f068>] 0xffffffffa040f068
        [<ffffffff81002c41>] do_one_initcall+0x141/0x780
        [<ffffffff816a72c3>] do_init_module+0x1c3/0x630
        [<ffffffff816adb9e>] load_module+0x623e/0x76a0
        [<ffffffff816af471>] __do_sys_finit_module+0x181/0x240
        [<ffffffff89978f99>] do_syscall_64+0x39/0xb0
        [<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests")
    Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
    Acked-by: Luis Chamberlain <mcgrof@kernel.org>
    Link: https://lore.kernel.org/r/20221119035721.18268-1-shaozhengchao@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
timerqueue: Use rb_entry_safe() in timerqueue_getnext() [+ + +]
Author: Barnabás Pőcze <pobrn@protonmail.com>
Date:   Mon Nov 14 19:54:23 2022 +0000

    timerqueue: Use rb_entry_safe() in timerqueue_getnext()
    
    [ Upstream commit 2f117484329b233455ee278f2d9b0a4356835060 ]
    
    When `timerqueue_getnext()` is called on an empty timer queue, it will
    use `rb_entry()` on a NULL pointer, which is invalid. Fix that by using
    `rb_entry_safe()` which handles NULL pointers.
    
    This has not caused any issues so far because the offset of the `rb_node`
    member in `timerqueue_node` is 0, so `rb_entry()` is essentially a no-op.
    
    Fixes: 511885d7061e ("lib/timerqueue: Rely on rbtree semantics for next timer")
    Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Link: https://lore.kernel.org/r/20221114195421.342929-1-pobrn@protonmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tipc: Add a missing case of TIPC_DIRECT_MSG type [+ + +]
Author: Hoang Le <hoang.h.le@dektech.com.au>
Date:   Thu Mar 26 09:50:29 2020 +0700

    tipc: Add a missing case of TIPC_DIRECT_MSG type
    
    commit 8b1e5b0a99f04bda2d6c85ecfe5e68a356c10914 upstream.
    
    In the commit f73b12812a3d
    ("tipc: improve throughput between nodes in netns"), we're missing a check
    to handle TIPC_DIRECT_MSG type, it's still using old sending mechanism for
    this message type. So, throughput improvement is not significant as
    expected.
    
    Besides that, when sending a large message with that type, we're also
    handle wrong receiving queue, it should be enqueued in socket receiving
    instead of multicast messages.
    
    Fix this by adding the missing case for TIPC_DIRECT_MSG.
    
    Fixes: f73b12812a3d ("tipc: improve throughput between nodes in netns")
    Reported-by: Tuong Lien <tuong.t.lien@dektech.com.au>
    Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tipc: call tipc_lxc_xmit without holding node_read_lock [+ + +]
Author: Xin Long <lucien.xin@gmail.com>
Date:   Sat Dec 3 18:37:21 2022 -0500

    tipc: call tipc_lxc_xmit without holding node_read_lock
    
    commit 88956177db179e4eba7cd590971961857d1565b8 upstream.
    
    When sending packets between nodes in netns, it calls tipc_lxc_xmit() for
    peer node to receive the packets where tipc_sk_mcast_rcv()/tipc_sk_rcv()
    might be called, and it's pretty much like in tipc_rcv().
    
    Currently the local 'node rw lock' is held during calling tipc_lxc_xmit()
    to protect the peer_net not being freed by another thread. However, when
    receiving these packets, tipc_node_add_conn() might be called where the
    peer 'node rw lock' is acquired. Then a dead lock warning is triggered by
    lockdep detector, although it is not a real dead lock:
    
        WARNING: possible recursive locking detected
        --------------------------------------------
        conn_server/1086 is trying to acquire lock:
        ffff8880065cb020 (&n->lock#2){++--}-{2:2}, \
                         at: tipc_node_add_conn.cold.76+0xaa/0x211 [tipc]
    
        but task is already holding lock:
        ffff8880065cd020 (&n->lock#2){++--}-{2:2}, \
                         at: tipc_node_xmit+0x285/0xb30 [tipc]
    
        other info that might help us debug this:
         Possible unsafe locking scenario:
    
               CPU0
               ----
          lock(&n->lock#2);
          lock(&n->lock#2);
    
         *** DEADLOCK ***
    
         May be due to missing lock nesting notation
    
        4 locks held by conn_server/1086:
         #0: ffff8880036d1e40 (sk_lock-AF_TIPC){+.+.}-{0:0}, \
                              at: tipc_accept+0x9c0/0x10b0 [tipc]
         #1: ffff8880036d5f80 (sk_lock-AF_TIPC/1){+.+.}-{0:0}, \
                              at: tipc_accept+0x363/0x10b0 [tipc]
         #2: ffff8880065cd020 (&n->lock#2){++--}-{2:2}, \
                              at: tipc_node_xmit+0x285/0xb30 [tipc]
         #3: ffff888012e13370 (slock-AF_TIPC){+...}-{2:2}, \
                              at: tipc_sk_rcv+0x2da/0x1b40 [tipc]
    
        Call Trace:
         <TASK>
         dump_stack_lvl+0x44/0x5b
         __lock_acquire.cold.77+0x1f2/0x3d7
         lock_acquire+0x1d2/0x610
         _raw_write_lock_bh+0x38/0x80
         tipc_node_add_conn.cold.76+0xaa/0x211 [tipc]
         tipc_sk_finish_conn+0x21e/0x640 [tipc]
         tipc_sk_filter_rcv+0x147b/0x3030 [tipc]
         tipc_sk_rcv+0xbb4/0x1b40 [tipc]
         tipc_lxc_xmit+0x225/0x26b [tipc]
         tipc_node_xmit.cold.82+0x4a/0x102 [tipc]
         __tipc_sendstream+0x879/0xff0 [tipc]
         tipc_accept+0x966/0x10b0 [tipc]
         do_accept+0x37d/0x590
    
    This patch avoids this warning by not holding the 'node rw lock' before
    calling tipc_lxc_xmit(). As to protect the 'peer_net', rcu_read_lock()
    should be enough, as in cleanup_net() when freeing the netns, it calls
    synchronize_rcu() before the free is continued.
    
    Also since tipc_lxc_xmit() is like the RX path in tipc_rcv(), it makes
    sense to call it under rcu_read_lock(). Note that the right lock order
    must be:
    
       rcu_read_lock();
       tipc_node_read_lock(n);
       tipc_node_read_unlock(n);
       tipc_lxc_xmit();
       rcu_read_unlock();
    
    instead of:
    
       tipc_node_read_lock(n);
       rcu_read_lock();
       tipc_node_read_unlock(n);
       tipc_lxc_xmit();
       rcu_read_unlock();
    
    and we have to call tipc_node_read_lock/unlock() twice in
    tipc_node_xmit().
    
    Fixes: f73b12812a3d ("tipc: improve throughput between nodes in netns")
    Reported-by: Shuang Li <shuali@redhat.com>
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Link: https://lore.kernel.org/r/5bdd1f8fee9db695cfff4528a48c9b9d0523fb00.1670110641.git.lucien.xin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tipc: eliminate checking netns if node established [+ + +]
Author: Hoang Le <hoang.h.le@dektech.com.au>
Date:   Fri Nov 8 10:02:37 2019 +0700

    tipc: eliminate checking netns if node established
    
    [ Upstream commit d408bef4bfa60bac665b6e7239269570039a968b ]
    
    Currently, we scan over all network namespaces at each received
    discovery message in order to check if the sending peer might be
    present in a host local namespaces.
    
    This is unnecessary since we can assume that a peer will not change its
    location during an established session.
    
    We now improve the condition for this testing so that we don't perform
    any redundant scans.
    
    Fixes: f73b12812a3d ("tipc: improve throughput between nodes in netns")
    Acked-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: c244c092f1ed ("tipc: fix unexpected link reset due to discovery messages")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tipc: fix unexpected link reset due to discovery messages [+ + +]
Author: Tung Nguyen <tung.q.nguyen@dektech.com.au>
Date:   Thu Jan 5 06:02:51 2023 +0000

    tipc: fix unexpected link reset due to discovery messages
    
    [ Upstream commit c244c092f1ed2acfb5af3d3da81e22367d3dd733 ]
    
    This unexpected behavior is observed:
    
    node 1                    | node 2
    ------                    | ------
    link is established       | link is established
    reboot                    | link is reset
    up                        | send discovery message
    receive discovery message |
    link is established       | link is established
    send discovery message    |
                              | receive discovery message
                              | link is reset (unexpected)
                              | send reset message
    link is reset             |
    
    It is due to delayed re-discovery as described in function
    tipc_node_check_dest(): "this link endpoint has already reset
    and re-established contact with the peer, before receiving a
    discovery message from that node."
    
    However, commit 598411d70f85 has changed the condition for calling
    tipc_node_link_down() which was the acceptance of new media address.
    
    This commit fixes this by restoring the old and correct behavior.
    
    Fixes: 598411d70f85 ("tipc: make resetting of links non-atomic")
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tipc: fix use-after-free in tipc_disc_rcv() [+ + +]
Author: Tuong Lien <tuong.t.lien@dektech.com.au>
Date:   Tue Dec 10 15:21:05 2019 +0700

    tipc: fix use-after-free in tipc_disc_rcv()
    
    commit 31e4ccc99eda8a5a7e6902c98bee6e78ffd3edb9 upstream.
    
    In the function 'tipc_disc_rcv()', the 'msg_peer_net_hash()' is called
    to read the header data field but after the message skb has been freed,
    that might result in a garbage value...
    
    This commit fixes it by defining a new local variable to store the data
    first, just like the other header fields' handling.
    
    Fixes: f73b12812a3d ("tipc: improve throughput between nodes in netns")
    Acked-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tipc: improve throughput between nodes in netns [+ + +]
Author: Hoang Le <hoang.h.le@dektech.com.au>
Date:   Tue Oct 29 07:51:21 2019 +0700

    tipc: improve throughput between nodes in netns
    
    [ Upstream commit f73b12812a3d1d798b7517547ccdcf864844d2cd ]
    
    Currently, TIPC transports intra-node user data messages directly
    socket to socket, hence shortcutting all the lower layers of the
    communication stack. This gives TIPC very good intra node performance,
    both regarding throughput and latency.
    
    We now introduce a similar mechanism for TIPC data traffic across
    network namespaces located in the same kernel. On the send path, the
    call chain is as always accompanied by the sending node's network name
    space pointer. However, once we have reliably established that the
    receiving node is represented by a namespace on the same host, we just
    replace the namespace pointer with the receiving node/namespace's
    ditto, and follow the regular socket receive patch though the receiving
    node. This technique gives us a throughput similar to the node internal
    throughput, several times larger than if we let the traffic go though
    the full network stacks. As a comparison, max throughput for 64k
    messages is four times larger than TCP throughput for the same type of
    traffic.
    
    To meet any security concerns, the following should be noted.
    
    - All nodes joining a cluster are supposed to have been be certified
    and authenticated by mechanisms outside TIPC. This is no different for
    nodes/namespaces on the same host; they have to auto discover each
    other using the attached interfaces, and establish links which are
    supervised via the regular link monitoring mechanism. Hence, a kernel
    local node has no other way to join a cluster than any other node, and
    have to obey to policies set in the IP or device layers of the stack.
    
    - Only when a sender has established with 100% certainty that the peer
    node is located in a kernel local namespace does it choose to let user
    data messages, and only those, take the crossover path to the receiving
    node/namespace.
    
    - If the receiving node/namespace is removed, its namespace pointer
    is invalidated at all peer nodes, and their neighbor link monitoring
    will eventually note that this node is gone.
    
    - To ensure the "100% certainty" criteria, and prevent any possible
    spoofing, received discovery messages must contain a proof that the
    sender knows a common secret. We use the hash mix of the sending
    node/namespace for this purpose, since it can be accessed directly by
    all other namespaces in the kernel. Upon reception of a discovery
    message, the receiver checks this proof against all the local
    namespaces'hash_mix:es. If it finds a match, that, along with a
    matching node id and cluster id, this is deemed sufficient proof that
    the peer node in question is in a local namespace, and a wormhole can
    be opened.
    
    - We should also consider that TIPC is intended to be a cluster local
    IPC mechanism (just like e.g. UNIX sockets) rather than a network
    protocol, and hence we think it can justified to allow it to shortcut the
    lower protocol layers.
    
    Regarding traceability, we should notice that since commit 6c9081a3915d
    ("tipc: add loopback device tracking") it is possible to follow the node
    internal packet flow by just activating tcpdump on the loopback
    interface. This will be true even for this mechanism; by activating
    tcpdump on the involved nodes' loopback interfaces their inter-name
    space messaging can easily be tracked.
    
    v2:
    - update 'net' pointer when node left/rejoined
    v3:
    - grab read/write lock when using node ref obj
    v4:
    - clone traffics between netns to loopback
    
    Suggested-by: Jon Maloy <jon.maloy@ericsson.com>
    Acked-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Hoang Le <hoang.h.le@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: c244c092f1ed ("tipc: fix unexpected link reset due to discovery messages")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tpm/tpm_crb: Fix error message in __crb_relinquish_locality() [+ + +]
Author: Michael Kelley <mikelley@microsoft.com>
Date:   Fri Nov 11 11:38:53 2022 -0800

    tpm/tpm_crb: Fix error message in __crb_relinquish_locality()
    
    [ Upstream commit f5264068071964b56dc02c9dab3d11574aaca6ff ]
    
    The error message in __crb_relinquish_locality() mentions requestAccess
    instead of Relinquish. Fix it.
    
    Fixes: 888d867df441 ("tpm: cmd_ready command can be issued only after granting locality")
    Signed-off-by: Michael Kelley <mikelley@microsoft.com>
    Acked-by: Tomas Winkler <tomas.winkler@intel.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak [+ + +]
Author: Hanjun Guo <guohanjun@huawei.com>
Date:   Thu Nov 17 19:23:41 2022 +0800

    tpm: tpm_crb: Add the missed acpi_put_table() to fix memory leak
    
    commit 37e90c374dd11cf4919c51e847c6d6ced0abc555 upstream.
    
    In crb_acpi_add(), we get the TPM2 table to retrieve information
    like start method, and then assign them to the priv data, so the
    TPM2 table is not used after the init, should be freed, call
    acpi_put_table() to fix the memory leak.
    
    Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tpm: tpm_tis: Add the missed acpi_put_table() to fix memory leak [+ + +]
Author: Hanjun Guo <guohanjun@huawei.com>
Date:   Thu Nov 17 19:23:42 2022 +0800

    tpm: tpm_tis: Add the missed acpi_put_table() to fix memory leak
    
    commit db9622f762104459ff87ecdf885cc42c18053fd9 upstream.
    
    In check_acpi_tpm2(), we get the TPM2 table just to make
    sure the table is there, not used after the init, so the
    acpi_put_table() should be added to release the ACPI memory.
    
    Fixes: 4cb586a188d4 ("tpm_tis: Consolidate the platform and acpi probe flow")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hanjun Guo <guohanjun@huawei.com>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing/hist: Fix issue of losting command info in error_log [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Wed Dec 7 21:53:26 2022 +0800

    tracing/hist: Fix issue of losting command info in error_log
    
    [ Upstream commit 608c6ed3337850c767ab0dd6c583477922233e29 ]
    
    When input some constructed invalid 'trigger' command, command info
    in 'error_log' are lost [1].
    
    The root cause is that there is a path that event_hist_trigger_parse()
    is recursely called once and 'last_cmd' which save origin command is
    cleared, then later calling of hist_err() will no longer record origin
    command info:
    
      event_hist_trigger_parse() {
        last_cmd_set()  // <1> 'last_cmd' save origin command here at first
        create_actions() {
          onmatch_create() {
            action_create() {
              trace_action_create() {
                trace_action_create_field_var() {
                  create_field_var_hist() {
                    event_hist_trigger_parse() {  // <2> recursely called once
                      hist_err_clear()  // <3> 'last_cmd' is cleared here
                    }
                    hist_err()  // <4> No longer find origin command!!!
    
    Since 'glob' is empty string while running into the recurse call, we
    can trickly check it and bypass the call of hist_err_clear() to solve it.
    
    [1]
     # cd /sys/kernel/tracing
     # echo "my_synth_event int v1; int v2; int v3;" >> synthetic_events
     # echo 'hist:keys=pid' >> events/sched/sched_waking/trigger
     # echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\
    pid,pid1)" >> events/sched/sched_switch/trigger
     # cat error_log
    [  8.405018] hist:sched:sched_switch: error: Couldn't find synthetic event
      Command:
    hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(pid,pid1)
                                                              ^
    [  8.816902] hist:sched:sched_switch: error: Couldn't find field
      Command:
    hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(pid,pid1)
                              ^
    [  8.816902] hist:sched:sched_switch: error: Couldn't parse field variable
      Command:
    hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(pid,pid1)
                              ^
    [  8.999880] : error: Couldn't find field
      Command:
               ^
    [  8.999880] : error: Couldn't parse field variable
      Command:
               ^
    [  8.999880] : error: Couldn't find field
      Command:
               ^
    [  8.999880] : error: Couldn't create histogram for field
      Command:
               ^
    
    Link: https://lore.kernel.org/linux-trace-kernel/20221207135326.3483216-1-zhengyejian1@huawei.com
    
    Cc: <mhiramat@kernel.org>
    Cc: <zanussi@kernel.org>
    Fixes: f404da6e1d46 ("tracing: Add 'last error' error facility for hist triggers")
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx' [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Wed Dec 7 11:51:43 2022 +0800

    tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'
    
    commit 82470f7d9044842618c847a7166de2b7458157a7 upstream.
    
    When generate a synthetic event with many params and then create a trace
    action for it [1], kernel panic happened [2].
    
    It is because that in trace_action_create() 'data->n_params' is up to
    SYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx'
    keeps indices into array 'hist_data->var_refs' for each synthetic event
    param, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX
    (current value is 16), so out-of-bound write happened when 'data->n_params'
    more than 16. In this case, 'data->match_data.event' is overwritten and
    eventually cause the panic.
    
    To solve the issue, adjust the length of 'data->var_ref_idx' to be
    SYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write.
    
    [1]
     # cd /sys/kernel/tracing/
     # echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\
    int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\
    int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\
    int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\
    int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\
    int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\
    int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\
    int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\
    int v63" >> synthetic_events
     # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="bash"' >> \
    events/sched/sched_waking/trigger
     # echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\
    pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\
    pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\
    pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\
    pid,pid,pid,pid,pid,pid,pid,pid,pid)" >> events/sched/sched_switch/trigger
    
    [2]
    BUG: unable to handle page fault for address: ffff91c900000000
    PGD 61001067 P4D 61001067 PUD 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 2 PID: 322 Comm: bash Tainted: G        W          6.1.0-rc8+ #229
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
    RIP: 0010:strcmp+0xc/0x30
    Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee
    c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14
    07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3
    RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246
    RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000
    RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000
    RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000
    R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580
    R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538
    FS:  00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0
    Call Trace:
     <TASK>
     __find_event_file+0x55/0x90
     action_create+0x76c/0x1060
     event_hist_trigger_parse+0x146d/0x2060
     ? event_trigger_write+0x31/0xd0
     trigger_process_regex+0xbb/0x110
     event_trigger_write+0x6b/0xd0
     vfs_write+0xc8/0x3e0
     ? alloc_fd+0xc0/0x160
     ? preempt_count_add+0x4d/0xa0
     ? preempt_count_add+0x70/0xa0
     ksys_write+0x5f/0xe0
     do_syscall_64+0x3b/0x90
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7f1d1d0cf077
    Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e
    fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00
    f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74
    RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077
    RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001
    RBP: 00005639265aa7e0 R08: 000000000000000a R09: 0000000000000142
    R10: 000056392639c017 R11: 0000000000000246 R12: 0000000000000143
    R13: 00007f1d1d1ae6a0 R14: 00007f1d1d1aa4a0 R15: 00007f1d1d1a98a0
     </TASK>
    Modules linked in:
    CR2: ffff91c900000000
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:strcmp+0xc/0x30
    Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee
    c3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14
    07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3
    RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246
    RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000
    RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000
    RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000
    R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580
    R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538
    FS:  00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0
    
    Link: https://lore.kernel.org/linux-trace-kernel/20221207035143.2278781-1-zhengyejian1@huawei.com
    
    Cc: <mhiramat@kernel.org>
    Cc: <zanussi@kernel.org>
    Cc: stable@vger.kernel.org
    Fixes: d380dcde9a07 ("tracing: Fix now invalid var_ref_vals assumption in trace action")
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tracing/hist: Fix wrong return value in parse_action_params() [+ + +]
Author: Zheng Yejian <zhengyejian1@huawei.com>
Date:   Wed Dec 7 11:46:35 2022 +0800

    tracing/hist: Fix wrong return value in parse_action_params()
    
    commit 2cc6a528882d0e0ccbc1bca5f95b8c963cedac54 upstream.
    
    When number of synth fields is more than SYNTH_FIELDS_MAX,
    parse_action_params() should return -EINVAL.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20221207034635.2253990-1-zhengyejian1@huawei.com
    
    Cc: <mhiramat@kernel.org>
    Cc: <zanussi@kernel.org>
    Cc: stable@vger.kernel.org
    Fixes: c282a386a397 ("tracing: Add 'onmatch' hist trigger action support")
    Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tracing/ring-buffer: Only do full wait when cpu != RING_BUFFER_ALL_CPUS [+ + +]
Author: Pratyush Yadav <ptyadav@amazon.de>
Date:   Fri Dec 16 14:42:41 2022 +0100

    tracing/ring-buffer: Only do full wait when cpu != RING_BUFFER_ALL_CPUS
    
    full_hit() directly uses cpu as an array index. Since
    RING_BUFFER_ALL_CPUS == -1, calling full_hit() with cpu ==
    RING_BUFFER_ALL_CPUS will cause an invalid memory access.
    
    The upstream commit 42fb0a1e84ff ("tracing/ring-buffer: Have polling
    block on watermark") already does this. This was missed when backporting
    to v5.4.y.
    
    This bug was discovered and resolved using Coverity Static Analysis
    Security Testing (SAST) by Synopsys, Inc.
    
    Fixes: e65ac2bdda54 ("tracing/ring-buffer: Have polling block on watermark")
    Signed-off-by: Pratyush Yadav <ptyadav@amazon.de>
    Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line [+ + +]
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Tue Nov 29 19:30:09 2022 +0800

    tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line
    
    commit c1ac03af6ed45d05786c219d102f37eb44880f28 upstream.
    
    print_trace_line may overflow seq_file buffer. If the event is not
    consumed, the while loop keeps peeking this event, causing a infinite loop.
    
    Link: https://lkml.kernel.org/r/20221129113009.182425-1-yangjihong1@huawei.com
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: stable@vger.kernel.org
    Fixes: 088b1e427dbba ("ftrace: pipe fixes")
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tty: serial: altera_uart_{r,t}x_chars() need only uart_port [+ + +]
Author: Jiri Slaby <jirislaby@kernel.org>
Date:   Tue Sep 20 07:20:43 2022 +0200

    tty: serial: altera_uart_{r,t}x_chars() need only uart_port
    
    [ Upstream commit 3af44d9bb0539d5fa27d6159d696fda5f3747bff ]
    
    Both altera_uart_{r,t}x_chars() need only uart_port, not altera_uart. So
    pass the former from altera_uart_interrupt() directly.
    
    Apart it maybe saves a dereference, this makes the transition of
    altera_uart_tx_chars() easier to follow in the next patch.
    
    Cc: Tobias Klauser <tklauser@distanz.ch>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Acked-by: Tobias Klauser <tklauser@distanz.ch>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Link: https://lore.kernel.org/r/20220920052049.20507-4-jslaby@suse.cz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 1307c5d33cce ("serial: altera_uart: fix locking in polling mode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tty: serial: clean up stop-tx part in altera_uart_tx_chars() [+ + +]
Author: Jiri Slaby <jirislaby@kernel.org>
Date:   Tue Sep 20 07:20:42 2022 +0200

    tty: serial: clean up stop-tx part in altera_uart_tx_chars()
    
    [ Upstream commit d9c128117da41cf4cb0e80ae565b5d3ac79dffac ]
    
    The "stop TX" path in altera_uart_tx_chars() is open-coded, so:
    * use uart_circ_empty() to check if the buffer is empty, and
    * when true, call altera_uart_stop_tx().
    
    Cc: Tobias Klauser <tklauser@distanz.ch>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Acked-by: Tobias Klauser <tklauser@distanz.ch>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Link: https://lore.kernel.org/r/20220920052049.20507-3-jslaby@suse.cz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 1307c5d33cce ("serial: altera_uart: fix locking in polling mode")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tty: serial: tegra: Activate RX DMA transfer by request [+ + +]
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Sun Jan 12 21:09:18 2020 +0300

    tty: serial: tegra: Activate RX DMA transfer by request
    
    [ Upstream commit d5e3fadb70125c6c41f692cf1c0e626c12e11de1 ]
    
    This allows DMA engine to go into runtime-suspended mode whenever there is
    no data to receive, instead of keeping DMA active all the time while TTY
    is opened (i.e. permanently active in practice, like in the case of UART
    Bluetooth).
    
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Link: https://lore.kernel.org/r/20200112180919.5194-2-digetx@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 109a951a9f1f ("serial: tegra: Read DMA status before terminating")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tty: serial: tegra: Handle RX transfer in PIO mode if DMA wasn't started [+ + +]
Author: Dmitry Osipenko <digetx@gmail.com>
Date:   Sun Feb 9 19:44:15 2020 +0300

    tty: serial: tegra: Handle RX transfer in PIO mode if DMA wasn't started
    
    commit 1f69a1273b3f204a9c00dc3bbdcc4afcd0787428 upstream.
    
    It is possible to get an instant RX timeout or end-of-transfer interrupt
    before RX DMA was started, if transaction is less than 16 bytes. Transfer
    should be handled in PIO mode in this case because DMA can't handle it.
    This patch brings back the original behaviour of the driver that was
    changed by accident by a previous commit, it fixes occasional Bluetooth HW
    initialization failures which I started to notice recently.
    
    Fixes: d5e3fadb7012 ("tty: serial: tegra: Activate RX DMA transfer by request")
    Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
    Link: https://lore.kernel.org/r/20200209164415.9632-1-digetx@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
udf: Avoid double brelse() in udf_rename() [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Sun Oct 23 18:57:41 2022 +0900

    udf: Avoid double brelse() in udf_rename()
    
    [ Upstream commit c791730f2554a9ebb8f18df9368dc27d4ebc38c2 ]
    
    syzbot reported a warning like below [1]:
    
    VFS: brelse: Trying to free free buffer
    WARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0
    ...
    Call Trace:
     <TASK>
     invalidate_bh_lru+0x99/0x150
     smp_call_function_many_cond+0xe2a/0x10c0
     ? generic_remap_file_range_prep+0x50/0x50
     ? __brelse+0xa0/0xa0
     ? __mutex_lock+0x21c/0x12d0
     ? smp_call_on_cpu+0x250/0x250
     ? rcu_read_lock_sched_held+0xb/0x60
     ? lock_release+0x587/0x810
     ? __brelse+0xa0/0xa0
     ? generic_remap_file_range_prep+0x50/0x50
     on_each_cpu_cond_mask+0x3c/0x80
     blkdev_flush_mapping+0x13a/0x2f0
     blkdev_put_whole+0xd3/0xf0
     blkdev_put+0x222/0x760
     deactivate_locked_super+0x96/0x160
     deactivate_super+0xda/0x100
     cleanup_mnt+0x222/0x3d0
     task_work_run+0x149/0x240
     ? task_work_cancel+0x30/0x30
     do_exit+0xb29/0x2a40
     ? reacquire_held_locks+0x4a0/0x4a0
     ? do_raw_spin_lock+0x12a/0x2b0
     ? mm_update_next_owner+0x7c0/0x7c0
     ? rwlock_bug.part.0+0x90/0x90
     ? zap_other_threads+0x234/0x2d0
     do_group_exit+0xd0/0x2a0
     __x64_sys_exit_group+0x3a/0x50
     do_syscall_64+0x34/0xb0
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    The cause of the issue is that brelse() is called on both ofibh.sbh
    and ofibh.ebh by udf_find_entry() when it returns NULL.  However,
    brelse() is called by udf_rename(), too.  So, b_count on buffer_head
    becomes unbalanced.
    
    This patch fixes the issue by not calling brelse() by udf_rename()
    when udf_find_entry() returns NULL.
    
    Link: https://syzkaller.appspot.com/bug?id=8297f45698159c6bca8a1f87dc983667c1a1c851 [1]
    Reported-by: syzbot+7902cd7684bc35306224@syzkaller.appspotmail.com
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20221023095741.271430-1-syoshida@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udf: Discard preallocation before extending file with a hole [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Dec 7 18:17:34 2022 +0100

    udf: Discard preallocation before extending file with a hole
    
    commit 16d0556568148bdcaa45d077cac9f8f7077cf70a upstream.
    
    When extending file with a hole, we tried to preserve existing
    preallocation for the file. However that is not very useful and
    complicates code because the previous extent may need to be rounded to
    block boundary as well (which we forgot to do thus causing data
    corruption for sequence like:
    
    xfs_io -f -c "pwrite 0x75e63 11008" -c "truncate 0x7b24b" \
      -c "truncate 0xabaa3" -c "pwrite 0xac70b 22954" \
      -c "pwrite 0x93a43 11358" -c "pwrite 0xb8e65 52211" file
    
    with 512-byte block size. Just discard preallocation before extending
    file to simplify things and also fix this data corruption.
    
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Dec 7 17:34:33 2022 +0100

    udf: Do not bother looking for prealloc extents if i_lenExtents matches i_size
    
    commit 6ad53f0f71c52871202a7bf096feb2c59db33fc5 upstream.
    
    If rounded block-rounded i_lenExtents matches block rounded i_size,
    there are no preallocation extents. Do not bother walking extent linked
    list.
    
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

udf: Fix extending file within last block [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Thu Dec 8 13:03:30 2022 +0100

    udf: Fix extending file within last block
    
    commit 1f3868f06855c97a4954c99b36f3fc9eb8f60326 upstream.
    
    When extending file within last block it can happen that the extent is
    already rounded to the blocksize and thus contains the offset we want to
    grow up to. In such case we would mistakenly expand the last extent and
    make it one block longer than it should be, exposing unallocated block
    in a file and causing data corruption. Fix the problem by properly
    detecting this case and bailing out.
    
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

udf: Fix extension of the last extent in the file [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Dec 21 17:45:51 2022 +0100

    udf: Fix extension of the last extent in the file
    
    [ Upstream commit 83c7423d1eb6806d13c521d1002cc1a012111719 ]
    
    When extending the last extent in the file within the last block, we
    wrongly computed the length of the last extent. This is mostly a
    cosmetical problem since the extent does not contain any data and the
    length will be fixed up by following operations but still.
    
    Fixes: 1f3868f06855 ("udf: Fix extending file within last block")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udf: Fix preallocation discarding at indirect extent boundary [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Wed Dec 7 17:25:10 2022 +0100

    udf: Fix preallocation discarding at indirect extent boundary
    
    commit cfe4c1b25dd6d2f056afc00b7c98bcb3dd0b1fc3 upstream.
    
    When preallocation extent is the first one in the extent block, the
    code would corrupt extent tree header instead. Fix the problem and use
    udf_delete_aext() for deleting extent to avoid some code duplication.
    
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
uio: uio_dmem_genirq: Fix deadlock between irq config and handling [+ + +]
Author: Rafael Mendonca <rafaelmendsr@gmail.com>
Date:   Fri Sep 30 19:40:58 2022 -0300

    uio: uio_dmem_genirq: Fix deadlock between irq config and handling
    
    [ Upstream commit 118b918018175d9fcd8db667f905012e986cc2c9 ]
    
    This fixes a concurrency issue addressed in commit 34cb27528398 ("UIO: Fix
    concurrency issue"):
    
      "In a SMP case there was a race condition issue between
      Uio_pdrv_genirq_irqcontrol() running on one CPU and irq handler on
      another CPU. Fix it by spin_locking shared resources access inside irq
      handler."
    
    The implementation of "uio_dmem_genirq" was based on "uio_pdrv_genirq" and
    it is used in a similar manner to the "uio_pdrv_genirq" driver with respect
    to interrupt configuration and handling. At the time "uio_dmem_genirq" was
    merged, both had the same implementation of the 'uio_info' handlers
    irqcontrol() and handler(), thus, both had the same concurrency issue
    mentioned by the above commit. However, the above patch was only applied to
    the "uio_pdrv_genirq" driver.
    
    Split out from commit 34cb27528398 ("UIO: Fix concurrency issue").
    
    Fixes: 0a0c3b5a24bd ("Add new uio device for dynamic memory allocation")
    Signed-off-by: Rafael Mendonca <rafaelmendsr@gmail.com>
    Link: https://lore.kernel.org/r/20220930224100.816175-3-rafaelmendsr@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

uio: uio_dmem_genirq: Fix missing unlock in irq configuration [+ + +]
Author: Rafael Mendonca <rafaelmendsr@gmail.com>
Date:   Fri Sep 30 19:40:57 2022 -0300

    uio: uio_dmem_genirq: Fix missing unlock in irq configuration
    
    [ Upstream commit 9de255c461d1b3f0242b3ad1450c3323a3e00b34 ]
    
    Commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in
    uio_dmem_genirq_irqcontrol()") started calling disable_irq() without
    holding the spinlock because it can sleep. However, that fix introduced
    another bug: if interrupt is already disabled and a new disable request
    comes in, then the spinlock is not unlocked:
    
    root@localhost:~# printf '\x00\x00\x00\x00' > /dev/uio0
    root@localhost:~# printf '\x00\x00\x00\x00' > /dev/uio0
    root@localhost:~# [   14.851538] BUG: scheduling while atomic: bash/223/0x00000002
    [   14.851991] Modules linked in: uio_dmem_genirq uio myfpga(OE) bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper drm snd_pcm ppdev joydev psmouse snd_timer snd e1000fb_sys_fops syscopyarea parport sysfillrect soundcore sysimgblt input_leds pcspkr i2c_piix4 serio_raw floppy evbug qemu_fw_cfg mac_hid pata_acpi ip_tables x_tables autofs4 [last unloaded: parport_pc]
    [   14.854206] CPU: 0 PID: 223 Comm: bash Tainted: G           OE      6.0.0-rc7 #21
    [   14.854786] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    [   14.855664] Call Trace:
    [   14.855861]  <TASK>
    [   14.856025]  dump_stack_lvl+0x4d/0x67
    [   14.856325]  dump_stack+0x14/0x1a
    [   14.856583]  __schedule_bug.cold+0x4b/0x5c
    [   14.856915]  __schedule+0xe81/0x13d0
    [   14.857199]  ? idr_find+0x13/0x20
    [   14.857456]  ? get_work_pool+0x2d/0x50
    [   14.857756]  ? __flush_work+0x233/0x280
    [   14.858068]  ? __schedule+0xa95/0x13d0
    [   14.858307]  ? idr_find+0x13/0x20
    [   14.858519]  ? get_work_pool+0x2d/0x50
    [   14.858798]  schedule+0x6c/0x100
    [   14.859009]  schedule_hrtimeout_range_clock+0xff/0x110
    [   14.859335]  ? tty_write_room+0x1f/0x30
    [   14.859598]  ? n_tty_poll+0x1ec/0x220
    [   14.859830]  ? tty_ldisc_deref+0x1a/0x20
    [   14.860090]  schedule_hrtimeout_range+0x17/0x20
    [   14.860373]  do_select+0x596/0x840
    [   14.860627]  ? __kernel_text_address+0x16/0x50
    [   14.860954]  ? poll_freewait+0xb0/0xb0
    [   14.861235]  ? poll_freewait+0xb0/0xb0
    [   14.861517]  ? rpm_resume+0x49d/0x780
    [   14.861798]  ? common_interrupt+0x59/0xa0
    [   14.862127]  ? asm_common_interrupt+0x2b/0x40
    [   14.862511]  ? __uart_start.isra.0+0x61/0x70
    [   14.862902]  ? __check_object_size+0x61/0x280
    [   14.863255]  core_sys_select+0x1c6/0x400
    [   14.863575]  ? vfs_write+0x1c9/0x3d0
    [   14.863853]  ? vfs_write+0x1c9/0x3d0
    [   14.864121]  ? _copy_from_user+0x45/0x70
    [   14.864526]  do_pselect.constprop.0+0xb3/0xf0
    [   14.864893]  ? do_syscall_64+0x6d/0x90
    [   14.865228]  ? do_syscall_64+0x6d/0x90
    [   14.865556]  __x64_sys_pselect6+0x76/0xa0
    [   14.865906]  do_syscall_64+0x60/0x90
    [   14.866214]  ? syscall_exit_to_user_mode+0x2a/0x50
    [   14.866640]  ? do_syscall_64+0x6d/0x90
    [   14.866972]  ? do_syscall_64+0x6d/0x90
    [   14.867286]  ? do_syscall_64+0x6d/0x90
    [   14.867626]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
    [...] stripped
    [   14.872959]  </TASK>
    
    ('myfpga' is a simple 'uio_dmem_genirq' driver I wrote to test this)
    
    The implementation of "uio_dmem_genirq" was based on "uio_pdrv_genirq" and
    it is used in a similar manner to the "uio_pdrv_genirq" driver with respect
    to interrupt configuration and handling. At the time "uio_dmem_genirq" was
    introduced, both had the same implementation of the 'uio_info' handlers
    irqcontrol() and handler(). Then commit 34cb27528398 ("UIO: Fix concurrency
    issue"), which was only applied to "uio_pdrv_genirq", ended up making them
    a little different. That commit, among other things, changed disable_irq()
    to disable_irq_nosync() in the implementation of irqcontrol(). The
    motivation there was to avoid a deadlock between irqcontrol() and
    handler(), since it added a spinlock in the irq handler, and disable_irq()
    waits for the completion of the irq handler.
    
    By changing disable_irq() to disable_irq_nosync() in irqcontrol(), we also
    avoid the sleeping-while-atomic bug that commit b74351287d4b ("uio: fix a
    sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") was trying to
    fix. Thus, this fixes the missing unlock in irqcontrol() by importing the
    implementation of irqcontrol() handler from the "uio_pdrv_genirq" driver.
    In the end, it reverts commit b74351287d4b ("uio: fix a
    sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()") and change
    disable_irq() to disable_irq_nosync().
    
    It is worth noting that this still does not address the concurrency issue
    fixed by commit 34cb27528398 ("UIO: Fix concurrency issue"). It will be
    addressed separately in the next commits.
    
    Split out from commit 34cb27528398 ("UIO: Fix concurrency issue").
    
    Fixes: b74351287d4b ("uio: fix a sleep-in-atomic-context bug in uio_dmem_genirq_irqcontrol()")
    Signed-off-by: Rafael Mendonca <rafaelmendsr@gmail.com>
    Link: https://lore.kernel.org/r/20220930224100.816175-2-rafaelmendsr@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
uprobes/x86: Allow to probe a NOP instruction with 0x66 prefix [+ + +]
Author: Oleg Nesterov <oleg@redhat.com>
Date:   Sun Dec 4 18:39:33 2022 +0100

    uprobes/x86: Allow to probe a NOP instruction with 0x66 prefix
    
    [ Upstream commit cefa72129e45313655d53a065b8055aaeb01a0c9 ]
    
    Intel ICC -hotpatch inserts 2-byte "0x66 0x90" NOP at the start of each
    function to reserve extra space for hot-patching, and currently it is not
    possible to probe these functions because branch_setup_xol_ops() wrongly
    rejects NOP with REP prefix as it treats them like word-sized branch
    instructions.
    
    Fixes: 250bbd12c2fe ("uprobes/x86: Refuse to attach uprobe to "word-sized" branch insns")
    Reported-by: Seiji Nishikawa <snishika@redhat.com>
    Suggested-by: Denys Vlasenko <dvlasenk@redhat.com>
    Signed-off-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Link: https://lore.kernel.org/r/20221204173933.GA31544@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: dwc3: core: defer probe on ulpi_read_id timeout [+ + +]
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Mon Dec 5 21:15:27 2022 +0100

    usb: dwc3: core: defer probe on ulpi_read_id timeout
    
    commit 63130462c919ece0ad0d9bb5a1f795ef8d79687e upstream.
    
    Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral
    if extcon is present"), Dual Role support on Intel Merrifield platform
    broke due to rearranging the call to dwc3_get_extcon().
    
    It appears to be caused by ulpi_read_id() masking the timeout on the first
    test write. In the past dwc3 probe continued by calling dwc3_core_soft_reset()
    followed by dwc3_get_extcon() which happend to return -EPROBE_DEFER.
    On deferred probe ulpi_read_id() finally succeeded. Due to above mentioned
    rearranging -EPROBE_DEFER is not returned and probe completes without phy.
    
    On Intel Merrifield the timeout on the first test write issue is reproducible
    but it is difficult to find the root cause. Using a mainline kernel and
    rootfs with buildroot ulpi_read_id() succeeds. As soon as adding
    ftrace / bootconfig to find out why, ulpi_read_id() fails and we can't
    analyze the flow. Using another rootfs ulpi_read_id() fails even without
    adding ftrace. We suspect the issue is some kind of timing / race, but
    merely retrying ulpi_read_id() does not resolve the issue.
    
    As we now changed ulpi_read_id() to return -ETIMEDOUT in this case, we
    need to handle the error by calling dwc3_core_soft_reset() and request
    -EPROBE_DEFER. On deferred probe ulpi_read_id() is retried and succeeds.
    
    Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
    Cc: stable@vger.kernel.org
    Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
    Link: https://lore.kernel.org/r/20221205201527.13525-3-ftoth@exalondelft.nl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: fotg210-udc: Fix ages old endianness issues [+ + +]
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri Nov 11 10:03:17 2022 +0100

    usb: fotg210-udc: Fix ages old endianness issues
    
    [ Upstream commit 46ed6026ca2181c917c8334a82e3eaf40a6234dd ]
    
    The code in the FOTG210 driver isn't entirely endianness-agnostic
    as reported by the kernel robot sparse testing. This came to
    the surface while moving the files around.
    
    The driver is only used on little-endian systems, so this causes
    no real-world regression, but it is nice to be strict and have
    some compile coverage also on big endian machines, so fix it
    up with the right LE accessors.
    
    Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver")
    Reported-by: kernel test robot <lkp@intel.com>
    Link: https://lore.kernel.org/linux-usb/202211110910.0dJ7nZCn-lkp@intel.com/
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20221111090317.94228-1-linus.walleij@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: gadget: f_hid: fix f_hidg lifetime vs cdev [+ + +]
Author: John Keeping <john@metanate.com>
Date:   Tue Nov 22 12:35:21 2022 +0000

    usb: gadget: f_hid: fix f_hidg lifetime vs cdev
    
    [ Upstream commit 89ff3dfac604614287ad5aad9370c3f984ea3f4b ]
    
    The embedded struct cdev does not have its lifetime correctly tied to
    the enclosing struct f_hidg, so there is a use-after-free if /dev/hidgN
    is held open while the gadget is deleted.
    
    This can readily be replicated with libusbgx's example programs (for
    conciseness - operating directly via configfs is equivalent):
    
            gadget-hid
            exec 3<> /dev/hidg0
            gadget-vid-pid-remove
            exec 3<&-
    
    Pull the existing device up in to struct f_hidg and make use of the
    cdev_device_{add,del}() helpers.  This changes the lifetime of the
    device object to match struct f_hidg, but note that it is still added
    and deleted at the same time.
    
    Fixes: 71adf1189469 ("USB: gadget: add HID gadget driver")
    Tested-by: Lee Jones <lee@kernel.org>
    Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
    Reviewed-by: Lee Jones <lee@kernel.org>
    Signed-off-by: John Keeping <john@metanate.com>
    Link: https://lore.kernel.org/r/20221122123523.3068034-2-john@metanate.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: gadget: f_hid: fix refcount leak on error path [+ + +]
Author: John Keeping <john@metanate.com>
Date:   Tue Nov 22 12:35:22 2022 +0000

    usb: gadget: f_hid: fix refcount leak on error path
    
    [ Upstream commit 70a3288a7586526315105c699b687d78cd32559a ]
    
    When failing to allocate report_desc, opts->refcnt has already been
    incremented so it needs to be decremented to avoid leaving the options
    structure permanently locked.
    
    Fixes: 21a9476a7ba8 ("usb: gadget: hid: add configfs support")
    Tested-by: Lee Jones <lee@kernel.org>
    Reviewed-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
    Reviewed-by: Lee Jones <lee@kernel.org>
    Signed-off-by: John Keeping <john@metanate.com>
    Link: https://lore.kernel.org/r/20221122123523.3068034-3-john@metanate.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: gadget: f_hid: optional SETUP/SET_REPORT mode [+ + +]
Author: Maxim Devaev <mdevaev@gmail.com>
Date:   Sat Aug 21 16:40:04 2021 +0300

    usb: gadget: f_hid: optional SETUP/SET_REPORT mode
    
    [ Upstream commit d7428bc26fc767942c38d74b80299bcd4f01e7cb ]
    
    f_hid provides the OUT Endpoint as only way for receiving reports
    from the host. SETUP/SET_REPORT method is not supported, and this causes
    a number of compatibility problems with various host drivers, especially
    in the case of keyboard emulation using f_hid.
    
      - Some hosts do not support the OUT Endpoint and ignore it,
        so it becomes impossible for the gadget to receive a report
        from the host. In the case of a keyboard, the gadget loses
        the ability to receive the status of the LEDs.
    
      - Some BIOSes/UEFIs can't work with HID devices with the OUT Endpoint
        at all. This may be due to their bugs or incomplete implementation
        of the HID standard.
        For example, absolutely all Apple UEFIs can't handle the OUT Endpoint
        if it goes after IN Endpoint in the descriptor and require the reverse
        order (OUT, IN) which is a violation of the standard.
        Other hosts either do not initialize gadgets with a descriptor
        containing the OUT Endpoint completely (like some HP and DELL BIOSes
        and embedded firmwares like on KVM switches), or initialize them,
        but will not poll the IN Endpoint.
    
    This patch adds configfs option no_out_endpoint=1 to disable
    the OUT Endpoint and allows f_hid to receive reports from the host
    via SETUP/SET_REPORT.
    
    Previously, there was such a feature in f_hid, but it was replaced
    by the OUT Endpoint [1] in the commit 99c515005857 ("usb: gadget: hidg:
    register OUT INT endpoint for SET_REPORT"). So this patch actually
    returns the removed functionality while making it optional.
    For backward compatibility reasons, the OUT Endpoint mode remains
    the default behaviour.
    
      - The OUT Endpoint mode provides the report queue and reduces
        USB overhead (eliminating SETUP routine) on transmitting a report
        from the host.
    
      - If the SETUP/SET_REPORT mode is used, there is no report queue,
        so the userspace will only read last report. For classic HID devices
        like keyboards this is not a problem, since it's intended to transmit
        the status of the LEDs and only the last report is important.
        This mode provides better compatibility with strange and buggy
        host drivers.
    
    Both modes passed USBCV tests. Checking with the USB protocol analyzer
    also confirmed that everything is working as it should and the new mode
    ensures operability in all of the described cases.
    
    Link: https://www.spinics.net/lists/linux-usb/msg65494.html [1]
    Reviewed-by: Maciej Żenczykowski <zenczykowski@gmail.com>
    Acked-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Maxim Devaev <mdevaev@gmail.com>
    Link: https://lore.kernel.org/r/20210821134004.363217-1-mdevaev@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 89ff3dfac604 ("usb: gadget: f_hid: fix f_hidg lifetime vs cdev")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: gadget: uvc: Prevent buffer overflow in setup handler [+ + +]
Author: Szymon Heidrich <szymon.heidrich@gmail.com>
Date:   Tue Dec 6 15:13:01 2022 +0100

    usb: gadget: uvc: Prevent buffer overflow in setup handler
    
    commit 4c92670b16727365699fe4b19ed32013bab2c107 upstream.
    
    Setup function uvc_function_setup permits control transfer
    requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE),
    data stage handler for OUT transfer uses memcpy to copy req->actual
    bytes to uvc_event->data.data array of size 60. This may result
    in an overflow of 4 bytes.
    
    Fixes: cdda479f15cd ("USB gadget: video class function driver")
    Cc: stable <stable@kernel.org>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
    Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com>
    Link: https://lore.kernel.org/r/20221206141301.51305-1-szymon.heidrich@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: musb: remove extra check in musb_gadget_vbus_draw [+ + +]
Author: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Date:   Fri Nov 25 20:21:15 2022 +0200

    usb: musb: remove extra check in musb_gadget_vbus_draw
    
    [ Upstream commit ecec4b20d29c3d6922dafe7d2555254a454272d2 ]
    
    The checks for musb->xceiv and musb->xceiv->set_power duplicate those in
    usb_phy_set_power(), so there is no need of them. Moreover, not calling
    usb_phy_set_power() results in usb_phy_set_charger_current() not being
    called, so current USB config max current is not propagated through USB
    charger framework and charger drivers may try to draw more current than
    allowed or possible.
    
    Fix that by removing those extra checks and calling usb_phy_set_power()
    directly.
    
    Tested on Motorola Droid4 and Nokia N900
    
    Fixes: a9081a008f84 ("usb: phy: Add USB charger support")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
    Link: https://lore.kernel.org/r/1669400475-4762-1-git-send-email-ivo.g.dimitrov.75@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: rndis_host: Secure rndis_query check against int overflow [+ + +]
Author: Szymon Heidrich <szymon.heidrich@gmail.com>
Date:   Tue Jan 3 10:17:09 2023 +0100

    usb: rndis_host: Secure rndis_query check against int overflow
    
    [ Upstream commit c7dd13805f8b8fc1ce3b6d40f6aff47e66b72ad2 ]
    
    Variables off and len typed as uint32 in rndis_query function
    are controlled by incoming RNDIS response message thus their
    value may be manipulated. Setting off to a unexpectetly large
    value will cause the sum with len and 8 to overflow and pass
    the implemented validation step. Consequently the response
    pointer will be referring to a location past the expected
    buffer boundaries allowing information leakage e.g. via
    RNDIS_OID_802_3_PERMANENT_ADDRESS OID.
    
    Fixes: ddda08624013 ("USB: rndis_host, various cleanups")
    Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: roles: fix of node refcount leak in usb_role_switch_is_parent() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Tue Nov 22 19:12:26 2022 +0800

    usb: roles: fix of node refcount leak in usb_role_switch_is_parent()
    
    [ Upstream commit 1ab30c610630da5391a373cddb8a065bf4c4bc01 ]
    
    I got the following report while doing device(mt6370-tcpc) load
    test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:
    
      OF: ERROR: memory leak, expected refcount 1 instead of 2,
      of_node_get()/of_node_put() unbalanced - destroy cset entry:
      attach overlay node /i2c/pmic@34
    
    The 'parent' returned by fwnode_get_parent() with refcount incremented.
    it needs be put after using.
    
    Fixes: 6fadd72943b8 ("usb: roles: get usb-role-switch from parent")
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Link: https://lore.kernel.org/r/20221122111226.251588-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
USB: serial: cp210x: add Kamstrup RF sniffer PIDs [+ + +]
Author: Bruno Thomsen <bruno.thomsen@gmail.com>
Date:   Sun Nov 27 18:08:11 2022 +0100

    USB: serial: cp210x: add Kamstrup RF sniffer PIDs
    
    commit e88906b169ebcb8046e8f0ad76edd09ab41cfdfe upstream.
    
    The RF sniffers are based on cp210x where the RF frontends
    are based on a different USB stack.
    
    RF sniffers can analyze packets meta data including power level
    and perform packet injection.
    
    Can be used to perform RF frontend self-test when connected to
    a concentrator, ex. arch/arm/boot/dts/imx7d-flex-concentrator.dts
    
    Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: f81232: fix division by zero on line-speed change [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 29 15:17:49 2022 +0100

    USB: serial: f81232: fix division by zero on line-speed change
    
    commit a08ca6ebafe615c9028c53fc4c9e6c9b2b1f2888 upstream.
    
    The driver leaves the line speed unchanged in case a requested speed is
    not supported. Make sure to handle the case where the current speed is
    B0 (hangup) without dividing by zero when determining the clock source.
    
    Fixes: 268ddb5e9b62 ("USB: serial: f81232: add high baud rate support")
    Cc: stable@vger.kernel.org      # 5.2
    Cc: Ji-Ze Hong (Peter Hong) <hpeter@gmail.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: f81534: fix division by zero on line-speed change [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Nov 29 15:18:19 2022 +0100

    USB: serial: f81534: fix division by zero on line-speed change
    
    commit 188c9c2e0c7f4ae864113f80c40bafb394062271 upstream.
    
    The driver leaves the line speed unchanged in case a requested speed is
    not supported. Make sure to handle the case where the current speed is
    B0 (hangup) without dividing by zero when determining the clock source.
    
    Fixes: 3aacac02f385 ("USB: serial: f81534: add high baud rate support")
    Cc: stable@vger.kernel.org      # 4.16
    Cc: Ji-Ze Hong (Peter Hong) <hpeter@gmail.com>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Quectel EM05-G modem [+ + +]
Author: Duke Xin <duke_xinanwen@163.com>
Date:   Sat Nov 19 17:44:47 2022 +0800

    USB: serial: option: add Quectel EM05-G modem
    
    commit f0052d7a1edb3d8921b4e154aa8c46c4845b3714 upstream.
    
    The EM05-G modem has 2 USB configurations that are configurable via the AT
    command AT+QCFG="usbnet",[ 0 | 2 ] which make the modem enumerate with
    the following interfaces, respectively:
    
    "RMNET" : AT + DIAG + NMEA + Modem + QMI
    "MBIM"  : MBIM + AT + DIAG + NMEA + Modem
    
    The detailed description of the USB configuration for each mode as follows:
    
    RMNET Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 21 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0311 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
    I:* If#= 3 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=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    MBIM Mode
    --------------
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=0311 Rev= 3.18
    S:  Manufacturer=Quectel
    S:  Product=Quectel EM05-G
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
    A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
    I:* If#= 3 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=0ms
    I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=89(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Duke Xin <duke_xinanwen@163.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: storage: Add check for kcalloc [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Thu Dec 8 19:00:58 2022 +0800

    usb: storage: Add check for kcalloc
    
    [ Upstream commit c35ca10f53c51eeb610d3f8fbc6dd6d511b58a58 ]
    
    As kcalloc may return NULL pointer, the return value should
    be checked and return error if fails as same as the ones in
    alauda_read_map.
    
    Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support")
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20221208110058.12983-1-jiasheng@iscas.ac.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: typec: Check for ops->exit instead of ops->enter in altmode_exit [+ + +]
Author: Sven Peter <sven@svenpeter.dev>
Date:   Mon Nov 14 17:59:24 2022 +0100

    usb: typec: Check for ops->exit instead of ops->enter in altmode_exit
    
    [ Upstream commit b6ddd180e3d9f92c1e482b3cdeec7dda086b1341 ]
    
    typec_altmode_exit checks if ops->enter is not NULL but then calls
    ops->exit a few lines below. Fix that and check for the function
    pointer it's about to call instead.
    
    Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes")
    Signed-off-by: Sven Peter <sven@svenpeter.dev>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20221114165924.33487-1-sven@svenpeter.dev
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: typec: tcpci: fix of node refcount leak in tcpci_register_port() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Mon Nov 21 14:24:16 2022 +0800

    usb: typec: tcpci: fix of node refcount leak in tcpci_register_port()
    
    [ Upstream commit 0384e87e3fec735e47f1c133c796f32ef7a72a9b ]
    
    I got the following report while doing device(mt6370-tcpc) load
    test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:
    
      OF: ERROR: memory leak, expected refcount 1 instead of 2,
      of_node_get()/of_node_put() unbalanced - destroy cset entry:
      attach overlay node /i2c/pmic@34/tcpc/connector
    
    The 'fwnode' set in tcpci_parse_config() which is called
    in tcpci_register_port(), its node refcount is increased
    in device_get_named_child_node(). It needs be put while
    exiting, so call fwnode_handle_put() in the error path of
    tcpci_register_port() and in tcpci_unregister_port() to
    avoid leak.
    
    Fixes: 5e85a04c8c0d ("usb: typec: add fwnode to tcpc")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20221121062416.1026192-1-yangyingliang@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: ulpi: defer ulpi_register on ulpi_read_id timeout [+ + +]
Author: Ferry Toth <ftoth@exalondelft.nl>
Date:   Mon Dec 5 21:15:26 2022 +0100

    usb: ulpi: defer ulpi_register on ulpi_read_id timeout
    
    [ Upstream commit 8a7b31d545d3a15f0e6f5984ae16f0ca4fd76aac ]
    
    Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral
    if extcon is present") Dual Role support on Intel Merrifield platform
    broke due to rearranging the call to dwc3_get_extcon().
    
    It appears to be caused by ulpi_read_id() on the first test write failing
    with -ETIMEDOUT. Currently ulpi_read_id() expects to discover the phy via
    DT when the test write fails and returns 0 in that case, even if DT does not
    provide the phy. As a result usb probe completes without phy.
    
    Make ulpi_read_id() return -ETIMEDOUT to its user if the first test write
    fails. The user should then handle it appropriately. A follow up patch
    will make dwc3_core_init() set -EPROBE_DEFER in this case and bail out.
    
    Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
    Cc: stable@vger.kernel.org
    Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
    Link: https://lore.kernel.org/r/20221205201527.13525-2-ftoth@exalondelft.nl
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vfio: platform: Do not pass return buffer to ACPI _RST method [+ + +]
Author: Rafael Mendonca <rafaelmendsr@gmail.com>
Date:   Tue Oct 18 12:28:25 2022 -0300

    vfio: platform: Do not pass return buffer to ACPI _RST method
    
    [ Upstream commit e67e070632a665c932d534b8b800477bb3111449 ]
    
    The ACPI _RST method has no return value, there's no need to pass a return
    buffer to acpi_evaluate_object().
    
    Fixes: d30daa33ec1d ("vfio: platform: call _RST method when using ACPI")
    Signed-off-by: Rafael Mendonca <rafaelmendsr@gmail.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Link: https://lore.kernel.org/r/20221018152825.891032-1-rafaelmendsr@gmail.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vhost: fix range used in translate_desc() [+ + +]
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Wed Nov 9 11:25:03 2022 +0100

    vhost: fix range used in translate_desc()
    
    [ Upstream commit 98047313cdb46828093894d0ac8b1183b8b317f9 ]
    
    vhost_iotlb_itree_first() requires `start` and `last` parameters
    to search for a mapping that overlaps the range.
    
    In translate_desc() we cyclically call vhost_iotlb_itree_first(),
    incrementing `addr` by the amount already translated, so rightly
    we move the `start` parameter passed to vhost_iotlb_itree_first(),
    but we should hold the `last` parameter constant.
    
    Let's fix it by saving the `last` parameter value before incrementing
    `addr` in the loop.
    
    Fixes: a9709d6874d5 ("vhost: convert pre sorted vhost memory array to interval tree")
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Message-Id: <20221109102503.18816-3-sgarzare@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vme: Fix error not catched in fake_init() [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Mon Dec 5 16:48:05 2022 +0800

    vme: Fix error not catched in fake_init()
    
    [ Upstream commit 7bef797d707f1744f71156b21d41e3b8c946631f ]
    
    In fake_init(), __root_device_register() is possible to fail but it's
    ignored, which can cause unregistering vme_root fail when exit.
    
     general protection fault,
     probably for non-canonical address 0xdffffc000000008c
     KASAN: null-ptr-deref in range [0x0000000000000460-0x0000000000000467]
     RIP: 0010:root_device_unregister+0x26/0x60
     Call Trace:
      <TASK>
      __x64_sys_delete_module+0x34f/0x540
      do_syscall_64+0x38/0x90
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Return error when __root_device_register() fails.
    
    Fixes: 658bcdae9c67 ("vme: Adding Fake VME driver")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Link: https://lore.kernel.org/r/20221205084805.147436-1-chenzhongjin@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: ar5523: Fix use-after-free on ar5523_cmd() timed out [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Mon Oct 10 03:32:23 2022 +0900

    wifi: ar5523: Fix use-after-free on ar5523_cmd() timed out
    
    [ Upstream commit b6702a942a069c2a975478d719e98d83cdae1797 ]
    
    syzkaller reported use-after-free with the stack trace like below [1]:
    
    [   38.960489][    C3] ==================================================================
    [   38.963216][    C3] BUG: KASAN: use-after-free in ar5523_cmd_tx_cb+0x220/0x240
    [   38.964950][    C3] Read of size 8 at addr ffff888048e03450 by task swapper/3/0
    [   38.966363][    C3]
    [   38.967053][    C3] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.0.0-09039-ga6afa4199d3d-dirty #18
    [   38.968464][    C3] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014
    [   38.969959][    C3] Call Trace:
    [   38.970841][    C3]  <IRQ>
    [   38.971663][    C3]  dump_stack_lvl+0xfc/0x174
    [   38.972620][    C3]  print_report.cold+0x2c3/0x752
    [   38.973626][    C3]  ? ar5523_cmd_tx_cb+0x220/0x240
    [   38.974644][    C3]  kasan_report+0xb1/0x1d0
    [   38.975720][    C3]  ? ar5523_cmd_tx_cb+0x220/0x240
    [   38.976831][    C3]  ar5523_cmd_tx_cb+0x220/0x240
    [   38.978412][    C3]  __usb_hcd_giveback_urb+0x353/0x5b0
    [   38.979755][    C3]  usb_hcd_giveback_urb+0x385/0x430
    [   38.981266][    C3]  dummy_timer+0x140c/0x34e0
    [   38.982925][    C3]  ? notifier_call_chain+0xb5/0x1e0
    [   38.984761][    C3]  ? rcu_read_lock_sched_held+0xb/0x60
    [   38.986242][    C3]  ? lock_release+0x51c/0x790
    [   38.987323][    C3]  ? _raw_read_unlock_irqrestore+0x37/0x70
    [   38.988483][    C3]  ? __wake_up_common_lock+0xde/0x130
    [   38.989621][    C3]  ? reacquire_held_locks+0x4a0/0x4a0
    [   38.990777][    C3]  ? lock_acquire+0x472/0x550
    [   38.991919][    C3]  ? rcu_read_lock_sched_held+0xb/0x60
    [   38.993138][    C3]  ? lock_acquire+0x472/0x550
    [   38.994890][    C3]  ? dummy_urb_enqueue+0x860/0x860
    [   38.996266][    C3]  ? do_raw_spin_unlock+0x16f/0x230
    [   38.997670][    C3]  ? dummy_urb_enqueue+0x860/0x860
    [   38.999116][    C3]  call_timer_fn+0x1a0/0x6a0
    [   39.000668][    C3]  ? add_timer_on+0x4a0/0x4a0
    [   39.002137][    C3]  ? reacquire_held_locks+0x4a0/0x4a0
    [   39.003809][    C3]  ? __next_timer_interrupt+0x226/0x2a0
    [   39.005509][    C3]  __run_timers.part.0+0x69a/0xac0
    [   39.007025][    C3]  ? dummy_urb_enqueue+0x860/0x860
    [   39.008716][    C3]  ? call_timer_fn+0x6a0/0x6a0
    [   39.010254][    C3]  ? cpuacct_percpu_seq_show+0x10/0x10
    [   39.011795][    C3]  ? kvm_sched_clock_read+0x14/0x40
    [   39.013277][    C3]  ? sched_clock_cpu+0x69/0x2b0
    [   39.014724][    C3]  run_timer_softirq+0xb6/0x1d0
    [   39.016196][    C3]  __do_softirq+0x1d2/0x9be
    [   39.017616][    C3]  __irq_exit_rcu+0xeb/0x190
    [   39.019004][    C3]  irq_exit_rcu+0x5/0x20
    [   39.020361][    C3]  sysvec_apic_timer_interrupt+0x8f/0xb0
    [   39.021965][    C3]  </IRQ>
    [   39.023237][    C3]  <TASK>
    
    In ar5523_probe(), ar5523_host_available() calls ar5523_cmd() as below
    (there are other functions which finally call ar5523_cmd()):
    
    ar5523_probe()
    -> ar5523_host_available()
       -> ar5523_cmd_read()
          -> ar5523_cmd()
    
    If ar5523_cmd() timed out, then ar5523_host_available() failed and
    ar5523_probe() freed the device structure.  So, ar5523_cmd_tx_cb()
    might touch the freed structure.
    
    This patch fixes this issue by canceling in-flight tx cmd if submitted
    urb timed out.
    
    Link: https://syzkaller.appspot.com/bug?id=9e12b2d54300842b71bdd18b54971385ff0d0d3a [1]
    Reported-by: syzbot+95001b1fd6dfcc716c29@syzkaller.appspotmail.com
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20221009183223.420015-1-syoshida@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: ath10k: Fix return value in ath10k_pci_init() [+ + +]
Author: Xiu Jianfeng <xiujianfeng@huawei.com>
Date:   Thu Nov 10 14:19:26 2022 +0800

    wifi: ath10k: Fix return value in ath10k_pci_init()
    
    [ Upstream commit 2af7749047d8d6ad43feff69f555a13a6a6c2831 ]
    
    This driver is attempting to register to support two different buses.
    if either of these is successful then ath10k_pci_init() should return 0
    so that hardware attached to the successful bus can be probed and
    supported. only if both of these are unsuccessful should ath10k_pci_init()
    return an errno.
    
    Fixes: 0b523ced9a3c ("ath10k: add basic skeleton to support ahb")
    Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
    Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20221110061926.18163-1-xiujianfeng@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: ath9k: hif_usb: fix memory leak of urbs in ath9k_hif_usb_dealloc_tx_urbs() [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Mon Jul 25 18:13:59 2022 +0300

    wifi: ath9k: hif_usb: fix memory leak of urbs in ath9k_hif_usb_dealloc_tx_urbs()
    
    [ Upstream commit c2a94de38c74e86f49124ac14f093d6a5c377a90 ]
    
    Syzkaller reports a long-known leak of urbs in
    ath9k_hif_usb_dealloc_tx_urbs().
    
    The cause of the leak is that usb_get_urb() is called but usb_free_urb()
    (or usb_put_urb()) is not called inside usb_kill_urb() as urb->dev or
    urb->ep fields have not been initialized and usb_kill_urb() returns
    immediately.
    
    The patch removes trying to kill urbs located in hif_dev->tx.tx_buf
    because hif_dev->tx.tx_buf is not supposed to contain urbs which are in
    pending state (the pending urbs are stored in hif_dev->tx.tx_pending).
    The tx.tx_lock is acquired so there should not be any changes in the list.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: 03fb92a432ea ("ath9k: hif_usb: fix race condition between usb_get_urb() and usb_kill_anchored_urbs()")
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20220725151359.283704-1-pchelkin@ispras.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: ath9k: hif_usb: Fix use-after-free in ath9k_hif_usb_reg_in_cb() [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Sat Oct 8 14:49:17 2022 +0300

    wifi: ath9k: hif_usb: Fix use-after-free in ath9k_hif_usb_reg_in_cb()
    
    [ Upstream commit dd95f2239fc846795fc926787c3ae0ca701c9840 ]
    
    It is possible that skb is freed in ath9k_htc_rx_msg(), then
    usb_submit_urb() fails and we try to free skb again. It causes
    use-after-free bug. Moreover, if alloc_skb() fails, urb->context becomes
    NULL but rx_buf is not freed and there can be a memory leak.
    
    The patch removes unnecessary nskb and makes skb processing more clear: it
    is supposed that ath9k_htc_rx_msg() either frees old skb or passes its
    managing to another callback function.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: 3deff76095c4 ("ath9k_htc: Increase URB count for REG_IN pipe")
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20221008114917.21404-1-pchelkin@ispras.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: ath9k: verify the expected usb_endpoints are present [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Sun Oct 9 00:15:32 2022 +0300

    wifi: ath9k: verify the expected usb_endpoints are present
    
    [ Upstream commit 16ef02bad239f11f322df8425d302be62f0443ce ]
    
    The bug arises when a USB device claims to be an ATH9K but doesn't
    have the expected endpoints. (In this case there was an interrupt
    endpoint where the driver expected a bulk endpoint.) The kernel
    needs to be able to handle such devices without getting an internal error.
    
    usb 1-1: BOGUS urb xfer, pipe 3 != type 1
    WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493
    Modules linked in:
    CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
    Workqueue: events request_firmware_work_func
    RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493
    Call Trace:
     ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline]
     ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019
     ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline]
     ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242
     request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097
     process_one_work+0x9af/0x1600 kernel/workqueue.c:2279
     worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425
     kthread+0x3b4/0x4a0 kernel/kthread.c:313
     ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Suggested-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
    Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://lore.kernel.org/r/20221008211532.74583-1-pchelkin@ispras.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: brcmfmac: Fix error return code in brcmf_sdio_download_firmware() [+ + +]
Author: Wang Yufen <wangyufen@huawei.com>
Date:   Fri Dec 2 13:35:42 2022 +0800

    wifi: brcmfmac: Fix error return code in brcmf_sdio_download_firmware()
    
    [ Upstream commit c2f2924bc7f9ea75ef8d95863e710168f8196256 ]
    
    Fix to return a negative error code instead of 0 when
    brcmf_chip_set_active() fails. In addition, change the return
    value for brcmf_pcie_exit_download_state() to keep consistent.
    
    Fixes: d380ebc9b6fb ("brcmfmac: rename chip download functions")
    Signed-off-by: Wang Yufen <wangyufen@huawei.com>
    Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/1669959342-27144-1-git-send-email-wangyufen@huawei.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request() [+ + +]
Author: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Date:   Mon Oct 24 16:13:29 2022 +0900

    wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()
    
    [ Upstream commit 81d17f6f3331f03c8eafdacea68ab773426c1e3c ]
    
    This patch fixes a shift-out-of-bounds in brcmfmac that occurs in
    BIT(chiprev) when a 'chiprev' provided by the device is too large.
    It should also not be equal to or greater than BITS_PER_TYPE(u32)
    as we do bitwise AND with a u32 variable and BIT(chiprev). The patch
    adds a check that makes the function return NULL if that is the case.
    Note that the NULL case is later handled by the bus-specific caller,
    brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.
    
    Found by a modified version of syzkaller.
    
    UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
    shift exponent 151055786 is too large for 64-bit type 'long unsigned int'
    CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G           O      5.14.0+ #132
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
    Workqueue: usb_hub_wq hub_event
    Call Trace:
     dump_stack_lvl+0x57/0x7d
     ubsan_epilogue+0x5/0x40
     __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb
     ? lock_chain_count+0x20/0x20
     brcmf_fw_alloc_request.cold+0x19/0x3ea
     ? brcmf_fw_get_firmwares+0x250/0x250
     ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0
     brcmf_usb_get_fwname+0x114/0x1a0
     ? brcmf_usb_reset_resume+0x120/0x120
     ? number+0x6c4/0x9a0
     brcmf_c_process_clm_blob+0x168/0x590
     ? put_dec+0x90/0x90
     ? enable_ptr_key_workfn+0x20/0x20
     ? brcmf_common_pd_remove+0x50/0x50
     ? rcu_read_lock_sched_held+0xa1/0xd0
     brcmf_c_preinit_dcmds+0x673/0xc40
     ? brcmf_c_set_joinpref_default+0x100/0x100
     ? rcu_read_lock_sched_held+0xa1/0xd0
     ? rcu_read_lock_bh_held+0xb0/0xb0
     ? lock_acquire+0x19d/0x4e0
     ? find_held_lock+0x2d/0x110
     ? brcmf_usb_deq+0x1cc/0x260
     ? mark_held_locks+0x9f/0xe0
     ? lockdep_hardirqs_on_prepare+0x273/0x3e0
     ? _raw_spin_unlock_irqrestore+0x47/0x50
     ? trace_hardirqs_on+0x1c/0x120
     ? brcmf_usb_deq+0x1a7/0x260
     ? brcmf_usb_rx_fill_all+0x5a/0xf0
     brcmf_attach+0x246/0xd40
     ? wiphy_new_nm+0x1476/0x1d50
     ? kmemdup+0x30/0x40
     brcmf_usb_probe+0x12de/0x1690
     ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
     usb_probe_interface+0x25f/0x710
     really_probe+0x1be/0xa90
     __driver_probe_device+0x2ab/0x460
     ? usb_match_id.part.0+0x88/0xc0
     driver_probe_device+0x49/0x120
     __device_attach_driver+0x18a/0x250
     ? driver_allows_async_probing+0x120/0x120
     bus_for_each_drv+0x123/0x1a0
     ? bus_rescan_devices+0x20/0x20
     ? lockdep_hardirqs_on_prepare+0x273/0x3e0
     ? trace_hardirqs_on+0x1c/0x120
     __device_attach+0x207/0x330
     ? device_bind_driver+0xb0/0xb0
     ? kobject_uevent_env+0x230/0x12c0
     bus_probe_device+0x1a2/0x260
     device_add+0xa61/0x1ce0
     ? __mutex_unlock_slowpath+0xe7/0x660
     ? __fw_devlink_link_to_suppliers+0x550/0x550
     usb_set_configuration+0x984/0x1770
     ? kernfs_create_link+0x175/0x230
     usb_generic_driver_probe+0x69/0x90
     usb_probe_device+0x9c/0x220
     really_probe+0x1be/0xa90
     __driver_probe_device+0x2ab/0x460
     driver_probe_device+0x49/0x120
     __device_attach_driver+0x18a/0x250
     ? driver_allows_async_probing+0x120/0x120
     bus_for_each_drv+0x123/0x1a0
     ? bus_rescan_devices+0x20/0x20
     ? lockdep_hardirqs_on_prepare+0x273/0x3e0
     ? trace_hardirqs_on+0x1c/0x120
     __device_attach+0x207/0x330
     ? device_bind_driver+0xb0/0xb0
     ? kobject_uevent_env+0x230/0x12c0
     bus_probe_device+0x1a2/0x260
     device_add+0xa61/0x1ce0
     ? __fw_devlink_link_to_suppliers+0x550/0x550
     usb_new_device.cold+0x463/0xf66
     ? hub_disconnect+0x400/0x400
     ? _raw_spin_unlock_irq+0x24/0x30
     hub_event+0x10d5/0x3330
     ? hub_port_debounce+0x280/0x280
     ? __lock_acquire+0x1671/0x5790
     ? wq_calc_node_cpumask+0x170/0x2a0
     ? lock_release+0x640/0x640
     ? rcu_read_lock_sched_held+0xa1/0xd0
     ? rcu_read_lock_bh_held+0xb0/0xb0
     ? lockdep_hardirqs_on_prepare+0x273/0x3e0
     process_one_work+0x873/0x13e0
     ? lock_release+0x640/0x640
     ? pwq_dec_nr_in_flight+0x320/0x320
     ? rwlock_bug.part.0+0x90/0x90
     worker_thread+0x8b/0xd10
     ? __kthread_parkme+0xd9/0x1d0
     ? process_one_work+0x13e0/0x13e0
     kthread+0x379/0x450
     ? _raw_spin_unlock_irq+0x24/0x30
     ? set_kthread_struct+0x100/0x100
     ret_from_fork+0x1f/0x30
    
    Reported-by: Dokyung Song <dokyungs@yonsei.ac.kr>
    Reported-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
    Reported-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
    Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20221024071329.504277-1-linuxlovemin@yonsei.ac.kr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: cfg80211: Fix not unregister reg_pdev when load_builtin_regdb_keys() fails [+ + +]
Author: Chen Zhongjin <chenzhongjin@huawei.com>
Date:   Wed Nov 9 17:02:37 2022 +0800

    wifi: cfg80211: Fix not unregister reg_pdev when load_builtin_regdb_keys() fails
    
    [ Upstream commit 833a9fd28c9b7ccb39a334721379e992dc1c0c89 ]
    
    In regulatory_init_db(), when it's going to return a error, reg_pdev
    should be unregistered. When load_builtin_regdb_keys() fails it doesn't
    do it and makes cfg80211 can't be reload with report:
    
    sysfs: cannot create duplicate filename '/devices/platform/regulatory.0'
     ...
     <TASK>
     dump_stack_lvl+0x79/0x9b
     sysfs_warn_dup.cold+0x1c/0x29
     sysfs_create_dir_ns+0x22d/0x290
     kobject_add_internal+0x247/0x800
     kobject_add+0x135/0x1b0
     device_add+0x389/0x1be0
     platform_device_add+0x28f/0x790
     platform_device_register_full+0x376/0x4b0
     regulatory_init+0x9a/0x4b2 [cfg80211]
     cfg80211_init+0x84/0x113 [cfg80211]
     ...
    
    Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking")
    Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
    Link: https://lore.kernel.org/r/20221109090237.214127-1-chenzhongjin@huawei.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: iwlwifi: mvm: fix double free on tx path. [+ + +]
Author: Ben Greear <greearb@candelatech.com>
Date:   Wed Nov 23 23:02:06 2022 +0200

    wifi: iwlwifi: mvm: fix double free on tx path.
    
    [ Upstream commit 0473cbae2137b963bd0eaa74336131cb1d3bc6c3 ]
    
    We see kernel crashes and lockups and KASAN errors related to ax210
    firmware crashes.  One of the KASAN dumps pointed at the tx path,
    and it appears there is indeed a way to double-free an skb.
    
    If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the
    method will be freed.  But, in case where we build TSO skb buffer,
    the skb may also be freed in error case.  So, return 0 in that particular
    error case and do cleanup manually.
    
    BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90
    iwlwifi 0000:06:00.0: 0x00000000 | tsf hi
    Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650
    
    CPU: 4 PID: 9650 Comm: btserver Tainted: G        W         5.19.8+ #5
    iwlwifi 0000:06:00.0: 0x00000000 | time gp1
    Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019
    Call Trace:
     <TASK>
     dump_stack_lvl+0x55/0x6d
     print_report.cold.12+0xf2/0x684
    iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2
     ? __list_del_entry_valid+0x12/0x90
     kasan_report+0x8b/0x180
    iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type
     ? __list_del_entry_valid+0x12/0x90
     __list_del_entry_valid+0x12/0x90
    iwlwifi 0000:06:00.0: 0x00000048 | uCode version major
     tcp_update_skb_after_send+0x5d/0x170
     __tcp_transmit_skb+0xb61/0x15c0
    iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor
     ? __tcp_select_window+0x490/0x490
    iwlwifi 0000:06:00.0: 0x00000420 | hw version
     ? trace_kmalloc_node+0x29/0xd0
     ? __kmalloc_node_track_caller+0x12a/0x260
     ? memset+0x1f/0x40
     ? __build_skb_around+0x125/0x150
     ? __alloc_skb+0x1d4/0x220
     ? skb_zerocopy_clone+0x55/0x230
    iwlwifi 0000:06:00.0: 0x00489002 | board version
     ? kmalloc_reserve+0x80/0x80
     ? rcu_read_lock_bh_held+0x60/0xb0
     tcp_write_xmit+0x3f1/0x24d0
    iwlwifi 0000:06:00.0: 0x034E001C | hcmd
     ? __check_object_size+0x180/0x350
    iwlwifi 0000:06:00.0: 0x24020000 | isr0
     tcp_sendmsg_locked+0x8a9/0x1520
    iwlwifi 0000:06:00.0: 0x01400000 | isr1
     ? tcp_sendpage+0x50/0x50
    iwlwifi 0000:06:00.0: 0x48F0000A | isr2
     ? lock_release+0xb9/0x400
     ? tcp_sendmsg+0x14/0x40
    iwlwifi 0000:06:00.0: 0x00C3080C | isr3
     ? lock_downgrade+0x390/0x390
     ? do_raw_spin_lock+0x114/0x1d0
    iwlwifi 0000:06:00.0: 0x00200000 | isr4
     ? rwlock_bug.part.2+0x50/0x50
    iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id
     ? rwlock_bug.part.2+0x50/0x50
     ? lockdep_hardirqs_on_prepare+0xe/0x200
    iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event
     ? __local_bh_enable_ip+0x87/0xe0
     ? inet_send_prepare+0x220/0x220
    iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control
     tcp_sendmsg+0x22/0x40
     sock_sendmsg+0x5f/0x70
    iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration
     __sys_sendto+0x19d/0x250
    iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid
     ? __ia32_sys_getpeername+0x40/0x40
    iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match
     ? rcu_read_lock_held_common+0x12/0x50
     ? rcu_read_lock_sched_held+0x5a/0xd0
     ? rcu_read_lock_bh_held+0xb0/0xb0
     ? rcu_read_lock_sched_held+0x5a/0xd0
     ? rcu_read_lock_sched_held+0x5a/0xd0
     ? lock_release+0xb9/0x400
     ? lock_downgrade+0x390/0x390
     ? ktime_get+0x64/0x130
     ? ktime_get+0x8d/0x130
     ? rcu_read_lock_held_common+0x12/0x50
     ? rcu_read_lock_sched_held+0x5a/0xd0
     ? rcu_read_lock_held_common+0x12/0x50
     ? rcu_read_lock_sched_held+0x5a/0xd0
     ? rcu_read_lock_bh_held+0xb0/0xb0
     ? rcu_read_lock_bh_held+0xb0/0xb0
     __x64_sys_sendto+0x6f/0x80
     do_syscall_64+0x34/0xb0
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    RIP: 0033:0x7f1d126e4531
    Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89
    RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 000000000000ffdc RCX: 00007f1d126e4531
    RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014
    RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000010
    R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000
     </TASK>
    
    Allocated by task 9650:
     kasan_save_stack+0x1c/0x40
     __kasan_slab_alloc+0x6d/0x90
     kmem_cache_alloc_node+0xf3/0x2b0
     __alloc_skb+0x191/0x220
     tcp_stream_alloc_skb+0x3f/0x330
     tcp_sendmsg_locked+0x67c/0x1520
     tcp_sendmsg+0x22/0x40
     sock_sendmsg+0x5f/0x70
     __sys_sendto+0x19d/0x250
     __x64_sys_sendto+0x6f/0x80
     do_syscall_64+0x34/0xb0
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Freed by task 9650:
     kasan_save_stack+0x1c/0x40
     kasan_set_track+0x21/0x30
     kasan_set_free_info+0x20/0x30
     __kasan_slab_free+0x102/0x170
     kmem_cache_free+0xc8/0x3e0
     iwl_mvm_mac_itxq_xmit+0x124/0x270 [iwlmvm]
     ieee80211_queue_skb+0x874/0xd10 [mac80211]
     ieee80211_xmit_fast+0xf80/0x1180 [mac80211]
     __ieee80211_subif_start_xmit+0x287/0x680 [mac80211]
     ieee80211_subif_start_xmit+0xcd/0x730 [mac80211]
     dev_hard_start_xmit+0xf6/0x420
     __dev_queue_xmit+0x165b/0x1b50
     ip_finish_output2+0x66e/0xfb0
     __ip_finish_output+0x487/0x6d0
     ip_output+0x11c/0x350
     __ip_queue_xmit+0x36b/0x9d0
     __tcp_transmit_skb+0xb35/0x15c0
     tcp_write_xmit+0x3f1/0x24d0
     tcp_sendmsg_locked+0x8a9/0x1520
     tcp_sendmsg+0x22/0x40
     sock_sendmsg+0x5f/0x70
     __sys_sendto+0x19d/0x250
     __x64_sys_sendto+0x6f/0x80
     do_syscall_64+0x34/0xb0
     entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    The buggy address belongs to the object at ffff88813cfa4b40
     which belongs to the cache skbuff_fclone_cache of size 472
    The buggy address is located 96 bytes inside of
     472-byte region [ffff88813cfa4b40, ffff88813cfa4d18)
    
    The buggy address belongs to the physical page:
    page:ffffea0004f3e900 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813cfa6c40 pfn:0x13cfa4
    head:ffffea0004f3e900 order:2 compound_mapcount:0 compound_pincount:0
    flags: 0x5fff8000010200(slab|head|node=0|zone=2|lastcpupid=0x3fff)
    raw: 005fff8000010200 ffffea0004656b08 ffffea0008e8cf08 ffff8881081a5240
    raw: ffff88813cfa6c40 0000000000170015 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff88813cfa4a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff88813cfa4b00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
    >ffff88813cfa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                   ^
     ffff88813cfa4c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff88813cfa4c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    Fixes: 08f7d8b69aaf ("iwlwifi: mvm: bring back mvm GSO code")
    Link: https://lore.kernel.org/linux-wireless/20220928193057.16132-1-greearb@candelatech.com/
    Tested-by: Amol Jawale <amol.jawale@candelatech.com>
    Signed-off-by: Ben Greear <greearb@candelatech.com>
    Link: https://lore.kernel.org/r/20221123225313.21b1ee31d666.I3b3ba184433dd2a544d91eeeda29b467021824ae@changeid
    Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rsi: Fix handling of 802.3 EAPOL frames sent via control port [+ + +]
Author: Marek Vasut <marex@denx.de>
Date:   Fri Nov 4 17:33:39 2022 +0100

    wifi: rsi: Fix handling of 802.3 EAPOL frames sent via control port
    
    [ Upstream commit b8f6efccbb9dc0ff5dee7e20d69a4747298ee603 ]
    
    When using wpa_supplicant v2.10, this driver is no longer able to
    associate with any AP and fails in the EAPOL 4-way handshake while
    sending the 2/4 message to the AP. The problem is not present in
    wpa_supplicant v2.9 or older. The problem stems from HostAP commit
    144314eaa ("wpa_supplicant: Send EAPOL frames over nl80211 where available")
    which changes the way EAPOL frames are sent, from them being send
    at L2 frames to them being sent via nl80211 control port.
    
    An EAPOL frame sent as L2 frame is passed to the WiFi driver with
    skb->protocol ETH_P_PAE, while EAPOL frame sent via nl80211 control
    port has skb->protocol set to ETH_P_802_3 . The later happens in
    ieee80211_tx_control_port(), where the EAPOL frame is encapsulated
    into 802.3 frame.
    
    The rsi_91x driver handles ETH_P_PAE EAPOL frames as high-priority
    frames and sends them via highest-priority transmit queue, while
    the ETH_P_802_3 frames are sent as regular frames. The EAPOL 4-way
    handshake frames must be sent as highest-priority, otherwise the
    4-way handshake times out.
    
    Therefore, to fix this problem, inspect the skb control flags and
    if flag IEEE80211_TX_CTRL_PORT_CTRL_PROTO is set, assume this is
    an EAPOL frame and transmit the frame via high-priority queue just
    like other ETH_P_PAE frames.
    
    Fixes: 0eb42586cf87 ("rsi: data packet descriptor enhancements")
    Signed-off-by: Marek Vasut <marex@denx.de>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20221104163339.227432-1-marex@denx.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtl8xxxu: Add __packed to struct rtl8723bu_c2h [+ + +]
Author: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Date:   Thu Dec 1 16:13:57 2022 +0200

    wifi: rtl8xxxu: Add __packed to struct rtl8723bu_c2h
    
    [ Upstream commit dd469a754afdb782ba3033cee102147493dc39f4 ]
    
    This struct is used to access a sequence of bytes received from the
    wifi chip. It must not have any padding bytes between the members.
    
    This doesn't change anything on my system, possibly because currently
    none of the members need more than byte alignment.
    
    Fixes: b2b43b7837ba ("rtl8xxxu: Initial functionality to handle C2H events for 8723bu")
    Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
    Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/1a270918-da22-ff5f-29fc-7855f740c5ba@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: rtl8xxxu: Fix reading the vendor of combo chips [+ + +]
Author: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Date:   Sat Oct 8 13:56:09 2022 +0300

    wifi: rtl8xxxu: Fix reading the vendor of combo chips
    
    [ Upstream commit 6f103aeb5e985ac08f3a4a049a2c17294f40cff9 ]
    
    The wifi + bluetooth combo chips (RTL8723AU and RTL8723BU) read the
    chip vendor from the wrong register because the val32 variable gets
    overwritten. Add one more variable to avoid this.
    
    This had no real effect on RTL8723BU. It may have had an effect on
    RTL8723AU.
    
    Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
    Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/24af8024-2f07-552b-93d8-38823d8e3cb0@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: wilc1000: sdio: fix module autoloading [+ + +]
Author: Michael Walle <michael@walle.cc>
Date:   Thu Oct 27 19:12:21 2022 +0200

    wifi: wilc1000: sdio: fix module autoloading
    
    [ Upstream commit 57d545b5a3d6ce3a8fb6b093f02bfcbb908973f3 ]
    
    There are no SDIO module aliases included in the driver, therefore,
    module autoloading isn't working. Add the proper MODULE_DEVICE_TABLE().
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20221027171221.491937-1-michael@walle.cc
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/boot: Avoid using Intel mnemonics in AT&T syntax asm [+ + +]
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Tue Jan 10 12:15:40 2023 +0100

    x86/boot: Avoid using Intel mnemonics in AT&T syntax asm
    
    commit 7c6dd961d0c8e7e8f9fdc65071fb09ece702e18d upstream.
    
    With 'GNU assembler (GNU Binutils for Debian) 2.39.90.20221231' the
    build now reports:
    
      arch/x86/realmode/rm/../../boot/bioscall.S: Assembler messages:
      arch/x86/realmode/rm/../../boot/bioscall.S:35: Warning: found `movsd'; assuming `movsl' was meant
      arch/x86/realmode/rm/../../boot/bioscall.S:70: Warning: found `movsd'; assuming `movsl' was meant
    
      arch/x86/boot/bioscall.S: Assembler messages:
      arch/x86/boot/bioscall.S:35: Warning: found `movsd'; assuming `movsl' was meant
      arch/x86/boot/bioscall.S:70: Warning: found `movsd'; assuming `movsl' was meant
    
    Which is due to:
    
      PR gas/29525
    
      Note that with the dropped CMPSD and MOVSD Intel Syntax string insn
      templates taking operands, mixed IsString/non-IsString template groups
      (with memory operands) cannot occur anymore. With that
      maybe_adjust_templates() becomes unnecessary (and is hence being
      removed).
    
    More details: https://sourceware.org/bugzilla/show_bug.cgi?id=29525
    
    Borislav Petkov further explains:
    
      " the particular problem here is is that the 'd' suffix is
        "conflicting" in the sense that you can have SSE mnemonics like movsD %xmm...
        and the same thing also for string ops (which is the case here) so apparently
        the agreement in binutils land is to use the always accepted suffixes 'l' or 'q'
        and phase out 'd' slowly... "
    
    Fixes: 7a734e7dd93b ("x86, setup: "glove box" BIOS calls -- infrastructure")
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/r/Y71I3Ex2pvIxMpsP@hirez.programming.kicks-ass.net
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/bugs: Flush IBP in ib_prctl_set() [+ + +]
Author: Rodrigo Branco <bsdaemon@google.com>
Date:   Tue Jan 3 14:17:51 2023 -0600

    x86/bugs: Flush IBP in ib_prctl_set()
    
    commit a664ec9158eeddd75121d39c9a0758016097fa96 upstream.
    
    We missed the window between the TIF flag update and the next reschedule.
    
    Signed-off-by: Rodrigo Branco <bsdaemon@google.com>
    Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/microcode/intel: Do not retry microcode reloading on the APs [+ + +]
Author: Ashok Raj <ashok.raj@intel.com>
Date:   Tue Nov 29 13:08:27 2022 -0800

    x86/microcode/intel: Do not retry microcode reloading on the APs
    
    commit be1b670f61443aa5d0d01782e9b8ea0ee825d018 upstream.
    
    The retries in load_ucode_intel_ap() were in place to support systems
    with mixed steppings. Mixed steppings are no longer supported and there is
    only one microcode image at a time. Any retries will simply reattempt to
    apply the same image over and over without making progress.
    
      [ bp: Zap the circumstantial reasoning from the commit message. ]
    
    Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
    Signed-off-by: Ashok Raj <ashok.raj@intel.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20221129210832.107850-3-ashok.raj@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/resctrl: Fix task CLOSID/RMID update race [+ + +]
Author: Peter Newman <peternewman@google.com>
Date:   Tue Dec 20 17:11:23 2022 +0100

    x86/resctrl: Fix task CLOSID/RMID update race
    
    [ Upstream commit fe1f0714385fbcf76b0cbceb02b7277d842014fc ]
    
    When the user moves a running task to a new rdtgroup using the task's
    file interface or by deleting its rdtgroup, the resulting change in
    CLOSID/RMID must be immediately propagated to the PQR_ASSOC MSR on the
    task(s) CPUs.
    
    x86 allows reordering loads with prior stores, so if the task starts
    running between a task_curr() check that the CPU hoist