óÐÉÓÏË ÉÚÍÅÎÅÎÉÊ × Linux 4.14.311

 
block: sunvdc: add check for mdesc_grab() returning NULL [+ + +]
Author: Liang He <[email protected]>
Date:   Wed Mar 15 14:20:32 2023 +0800

    block: sunvdc: add check for mdesc_grab() returning NULL
    
    [ Upstream commit 6030363199e3a6341afb467ddddbed56640cbf6a ]
    
    In vdc_port_probe(), we should check the return value of mdesc_grab() as
    it may return NULL, which can cause potential NPD bug.
    
    Fixes: 43fdf27470b2 ("[SPARC64]: Abstract out mdesc accesses for better MD update handling.")
    Signed-off-by: Liang He <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [axboe: style cleanup]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915: Don't use stolen memory for ring buffers with LLC [+ + +]
Author: John Harrison <[email protected]>
Date:   Wed Feb 15 17:11:00 2023 -0800

    drm/i915: Don't use stolen memory for ring buffers with LLC
    
    commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 upstream.
    
    Direction from hardware is that stolen memory should never be used for
    ring buffer allocations on platforms with LLC. There are too many
    caching pitfalls due to the way stolen memory accesses are routed. So
    it is safest to just not use it.
    
    Signed-off-by: John Harrison <[email protected]>
    Fixes: c58b735fc762 ("drm/i915: Allocate rings from stolen")
    Cc: Chris Wilson <[email protected]>
    Cc: Joonas Lahtinen <[email protected]>
    Cc: Jani Nikula <[email protected]>
    Cc: Rodrigo Vivi <[email protected]>
    Cc: Tvrtko Ursulin <[email protected]>
    Cc: [email protected]
    Cc: <[email protected]> # v4.9+
    Tested-by: Jouni Högander <[email protected]>
    Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    (cherry picked from commit f54c1f6c697c4297f7ed94283c184acc338a5cf8)
    Signed-off-by: Jani Nikula <[email protected]>
    Signed-off-by: John Harrison <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ethernet: sun: add check for the mdesc_grab() [+ + +]
Author: Liang He <[email protected]>
Date:   Wed Mar 15 14:00:21 2023 +0800

    ethernet: sun: add check for the mdesc_grab()
    
    [ Upstream commit 90de546d9a0b3c771667af18bb3f80567eabb89b ]
    
    In vnet_port_probe() and vsw_port_probe(), we should
    check the return value of mdesc_grab() as it may
    return NULL which can caused NPD bugs.
    
    Fixes: 5d01fa0c6bd8 ("ldmvsw: Add ldmvsw.c driver code")
    Fixes: 43fdf27470b2 ("[SPARC64]: Abstract out mdesc accesses for better MD update handling.")
    Signed-off-by: Liang He <[email protected]>
    Reviewed-by: Piotr Raczynski <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ext4: fail ext4_iget if special inode unallocated [+ + +]
Author: Baokun Li <[email protected]>
Date:   Sat Jan 7 11:21:25 2023 +0800

    ext4: fail ext4_iget if special inode unallocated
    
    [ Upstream commit 5cd740287ae5e3f9d1c46f5bfe8778972fd6d3fe ]
    
    In ext4_fill_super(), EXT4_ORPHAN_FS flag is cleared after
    ext4_orphan_cleanup() is executed. Therefore, when __ext4_iget() is
    called to get an inode whose i_nlink is 0 when the flag exists, no error
    is returned. If the inode is a special inode, a null pointer dereference
    may occur. If the value of i_nlink is 0 for any inodes (except boot loader
    inodes) got by using the EXT4_IGET_SPECIAL flag, the current file system
    is corrupted. Therefore, make the ext4_iget() function return an error if
    it gets such an abnormal special inode.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=199179
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216541
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=216539
    Reported-by: Luís Henriques <[email protected]>
    Suggested-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ext4: fix cgroup writeback accounting with fs-layer encryption [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Thu Feb 2 16:55:03 2023 -0800

    ext4: fix cgroup writeback accounting with fs-layer encryption
    
    commit ffec85d53d0f39ee4680a2cf0795255e000e1feb upstream.
    
    When writing a page from an encrypted file that is using
    filesystem-layer encryption (not inline encryption), ext4 encrypts the
    pagecache page into a bounce page, then writes the bounce page.
    
    It also passes the bounce page to wbc_account_cgroup_owner().  That's
    incorrect, because the bounce page is a newly allocated temporary page
    that doesn't have the memory cgroup of the original pagecache page.
    This makes wbc_account_cgroup_owner() not account the I/O to the owner
    of the pagecache page as it should.
    
    Fix this by always passing the pagecache page to
    wbc_account_cgroup_owner().
    
    Fixes: 001e4a8775f6 ("ext4: implement cgroup writeback support")
    Cc: [email protected]
    Reported-by: Matthew Wilcox (Oracle) <[email protected]>
    Signed-off-by: Eric Biggers <[email protected]>
    Acked-by: Tejun Heo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
ext4: fix task hung in ext4_xattr_delete_inode [+ + +]
Author: Baokun Li <[email protected]>
Date:   Tue Jan 10 21:34:36 2023 +0800

    ext4: fix task hung in ext4_xattr_delete_inode
    
    [ Upstream commit 0f7bfd6f8164be32dbbdf36aa1e5d00485c53cd7 ]
    
    Syzbot reported a hung task problem:
    ==================================================================
    INFO: task syz-executor232:5073 blocked for more than 143 seconds.
          Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    task:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004
    Call Trace:
     <TASK>
     context_switch kernel/sched/core.c:5244 [inline]
     __schedule+0x995/0xe20 kernel/sched/core.c:6555
     schedule+0xcb/0x190 kernel/sched/core.c:6631
     __wait_on_freeing_inode fs/inode.c:2196 [inline]
     find_inode_fast+0x35a/0x4c0 fs/inode.c:950
     iget_locked+0xb1/0x830 fs/inode.c:1273
     __ext4_iget+0x22e/0x3ed0 fs/ext4/inode.c:4861
     ext4_xattr_inode_iget+0x68/0x4e0 fs/ext4/xattr.c:389
     ext4_xattr_inode_dec_ref_all+0x1a7/0xe50 fs/ext4/xattr.c:1148
     ext4_xattr_delete_inode+0xb04/0xcd0 fs/ext4/xattr.c:2880
     ext4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296
     evict+0x2a4/0x620 fs/inode.c:664
     ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474
     __ext4_fill_super fs/ext4/super.c:5516 [inline]
     ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644
     get_tree_bdev+0x400/0x620 fs/super.c:1282
     vfs_get_tree+0x88/0x270 fs/super.c:1489
     do_new_mount+0x289/0xad0 fs/namespace.c:3145
     do_mount fs/namespace.c:3488 [inline]
     __do_sys_mount fs/namespace.c:3697 [inline]
     __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    RIP: 0033:0x7fa5406fd5ea
    RSP: 002b:00007ffc7232f968 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fa5406fd5ea
    RDX: 0000000020000440 RSI: 0000000020000000 RDI: 00007ffc7232f970
    RBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: 0000000000000432
    R10: 0000000000804a03 R11: 0000000000000202 R12: 0000000000000004
    R13: 0000555556a7a2c0 R14: 00007ffc7232f9b0 R15: 0000000000000000
     </TASK>
    ==================================================================
    
    The problem is that the inode contains an xattr entry with ea_inum of 15
    when cleaning up an orphan inode <15>. When evict inode <15>, the reference
    counting of the corresponding EA inode is decreased. When EA inode <15> is
    found by find_inode_fast() in __ext4_iget(), it is found that the EA inode
    holds the I_FREEING flag and waits for the EA inode to complete deletion.
    As a result, when inode <15> is being deleted, we wait for inode <15> to
    complete the deletion, resulting in an infinite loop and triggering Hung
    Task. To solve this problem, we only need to check whether the ino of EA
    inode and parent is the same before getting EA inode.
    
    Link: https://syzkaller.appspot.com/bug?extid=77d6fcc37bbb92f26048
    Reported-by: [email protected]
    Signed-off-by: Baokun Li <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Theodore Ts'o <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fbdev: stifb: Provide valid pixelclock and add fb_check_var() checks [+ + +]
Author: Helge Deller <[email protected]>
Date:   Thu Mar 16 11:38:19 2023 +0100

    fbdev: stifb: Provide valid pixelclock and add fb_check_var() checks
    
    commit 203873a535d627c668f293be0cb73e26c30f9cc7 upstream.
    
    Find a valid modeline depending on the machine graphic card
    configuration and add the fb_check_var() function to validate
    Xorg provided graphics settings.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fs: sysfs_emit_at: Remove PAGE_SIZE alignment check [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Thu Mar 16 23:27:43 2023 -0700

    fs: sysfs_emit_at: Remove PAGE_SIZE alignment check
    
    From: Eric Biggers <[email protected]>
    
    [No upstream commit because this fixes a bug in a backport.]
    
    Before upstream commit 59bb47985c1d ("mm, sl[aou]b: guarantee natural
    alignment for kmalloc(power-of-two)") which went into v5.4, kmalloc did
    *not* always guarantee that PAGE_SIZE allocations are PAGE_SIZE-aligned.
    
    Upstream commit 2efc459d06f1 ("sysfs: Add sysfs_emit and sysfs_emit_at
    to format sysfs output") added two WARN()s that trigger when PAGE_SIZE
    allocations are not PAGE_SIZE-aligned.  This was backported to old
    kernels that don't guarantee PAGE_SIZE alignment.
    
    Commit 10ddfb495232 ("fs: sysfs_emit: Remove PAGE_SIZE alignment check")
    in 4.19.y, and its equivalent in 4.14.y and 4.9.y, tried to fix this
    bug.  However, only it handled sysfs_emit(), not sysfs_emit_at().
    
    Fix it in sysfs_emit_at() too.
    
    A reproducer is to build the kernel with the following options:
    
            CONFIG_SLUB=y
            CONFIG_SLUB_DEBUG=y
            CONFIG_SLUB_DEBUG_ON=y
            CONFIG_PM=y
            CONFIG_SUSPEND=y
            CONFIG_PM_WAKELOCKS=y
    
    Then run:
    
            echo foo > /sys/power/wake_lock && cat /sys/power/wake_lock
    
    Fixes: cb1f69d53ac8 ("sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output")
    Reported-by: kernel test robot <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ftrace: Fix invalid address access in lookup_rec() when index is 0 [+ + +]
Author: Chen Zhongjin <[email protected]>
Date:   Thu Mar 9 16:02:30 2023 +0800

    ftrace: Fix invalid address access in lookup_rec() when index is 0
    
    commit ee92fa443358f4fc0017c1d0d325c27b37802504 upstream.
    
    KASAN reported follow problem:
    
     BUG: KASAN: use-after-free in lookup_rec
     Read of size 8 at addr ffff000199270ff0 by task modprobe
     CPU: 2 Comm: modprobe
     Call trace:
      kasan_report
      __asan_load8
      lookup_rec
      ftrace_location
      arch_check_ftrace_location
      check_kprobe_address_safe
      register_kprobe
    
    When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a
    pg which is newly added to ftrace_pages_start in ftrace_process_locs().
    Before the first pg->index++, index is 0 and accessing pg->records[-1].ip
    will cause this problem.
    
    Don't check the ip when pg->index is 0.
    
    Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
    
    Cc: [email protected]
    Fixes: 9644302e3315 ("ftrace: Speed up search by skipping pages by address")
    Suggested-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Chen Zhongjin <[email protected]>
    Signed-off-by: Steven Rostedt (Google) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
HID: core: Provide new max_buffer_size attribute to over-ride the default [+ + +]
Author: Lee Jones <[email protected]>
Date:   Mon Mar 20 13:09:22 2023 +0000

    HID: core: Provide new max_buffer_size attribute to over-ride the default
    
    commit b1a37ed00d7908a991c1d0f18a8cba3c2aa99bdc upstream.
    
    Presently, when a report is processed, its proposed size, provided by
    the user of the API (as Report Size * Report Count) is compared against
    the subsystem default HID_MAX_BUFFER_SIZE (16k).  However, some
    low-level HID drivers allocate a reduced amount of memory to their
    buffers (e.g. UHID only allocates UHID_DATA_MAX (4k) buffers), rending
    this check inadequate in some cases.
    
    In these circumstances, if the received report ends up being smaller
    than the proposed report size, the remainder of the buffer is zeroed.
    That is, the space between sizeof(csize) (size of the current report)
    and the rsize (size proposed i.e. Report Size * Report Count), which can
    be handled up to HID_MAX_BUFFER_SIZE (16k).  Meaning that memset()
    shoots straight past the end of the buffer boundary and starts zeroing
    out in-use values, often resulting in calamity.
    
    This patch introduces a new variable into 'struct hid_ll_driver' where
    individual low-level drivers can over-ride the default maximum value of
    HID_MAX_BUFFER_SIZE (16k) with something more sympathetic to the
    interface.
    
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    [Lee: Backported to v4.14.y]
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

HID: uhid: Over-ride the default maximum data buffer value with our own [+ + +]
Author: Lee Jones <[email protected]>
Date:   Mon Mar 20 13:09:23 2023 +0000

    HID: uhid: Over-ride the default maximum data buffer value with our own
    
    commit 1c5d4221240a233df2440fe75c881465cdf8da07 upstream.
    
    The default maximum data buffer size for this interface is UHID_DATA_MAX
    (4k).  When data buffers are being processed, ensure this value is used
    when ensuring the sanity, rather than a value between the user provided
    value and HID_MAX_BUFFER_SIZE (16k).
    
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Lee Jones <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
hwmon: (adt7475) Display smoothing attributes in correct order [+ + +]
Author: Tony O'Brien <[email protected]>
Date:   Wed Feb 22 13:52:27 2023 +1300

    hwmon: (adt7475) Display smoothing attributes in correct order
    
    [ Upstream commit 5f8d1e3b6f9b5971f9c06d5846ce00c49e3a8d94 ]
    
    Throughout the ADT7475 driver, attributes relating to the temperature
    sensors are displayed in the order Remote 1, Local, Remote 2.  Make
    temp_st_show() conform to this expectation so that values set by
    temp_st_store() can be displayed using the correct attribute.
    
    Fixes: 8f05bcc33e74 ("hwmon: (adt7475) temperature smoothing")
    Signed-off-by: Tony O'Brien <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hwmon: (adt7475) Fix masking of hysteresis registers [+ + +]
Author: Tony O'Brien <[email protected]>
Date:   Wed Feb 22 13:52:28 2023 +1300

    hwmon: (adt7475) Fix masking of hysteresis registers
    
    [ Upstream commit 48e8186870d9d0902e712d601ccb7098cb220688 ]
    
    The wrong bits are masked in the hysteresis register; indices 0 and 2
    should zero bits [7:4] and preserve bits [3:0], and index 1 should zero
    bits [3:0] and preserve bits [7:4].
    
    Fixes: 1c301fc5394f ("hwmon: Add a driver for the ADT7475 hardware monitoring chip")
    Signed-off-by: Tony O'Brien <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

hwmon: (xgene) Fix use after free bug in xgene_hwmon_remove due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Fri Mar 10 16:40:07 2023 +0800

    hwmon: (xgene) Fix use after free bug in xgene_hwmon_remove due to race condition
    
    [ Upstream commit cb090e64cf25602b9adaf32d5dfc9c8bec493cd1 ]
    
    In xgene_hwmon_probe, &ctx->workq is bound with xgene_hwmon_evt_work.
    Then it will be started.
    
    If we remove the driver which will call xgene_hwmon_remove to clean up,
    there may be unfinished work.
    
    The possible sequence is as follows:
    
    Fix it by finishing the work before cleanup in xgene_hwmon_remove.
    
    CPU0                  CPU1
    
                        |xgene_hwmon_evt_work
    xgene_hwmon_remove   |
    kfifo_free(&ctx->async_msg_fifo);|
                        |
                        |kfifo_out_spinlocked
                        |//use &ctx->async_msg_fifo
    Fixes: 2ca492e22cb7 ("hwmon: (xgene) Fix crash when alarm occurs before driver probe")
    Signed-off-by: Zheng Wang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Guenter Roeck <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipv4: Fix incorrect table ID in IOCTL path [+ + +]
Author: Ido Schimmel <[email protected]>
Date:   Wed Mar 15 14:40:09 2023 +0200

    ipv4: Fix incorrect table ID in IOCTL path
    
    [ Upstream commit 8a2618e14f81604a9b6ad305d57e0c8da939cd65 ]
    
    Commit f96a3d74554d ("ipv4: Fix incorrect route flushing when source
    address is deleted") started to take the table ID field in the FIB info
    structure into account when determining if two structures are identical
    or not. This field is initialized using the 'fc_table' field in the
    route configuration structure, which is not set when adding a route via
    IOCTL.
    
    The above can result in user space being able to install two identical
    routes that only differ in the table ID field of their associated FIB
    info.
    
    Fix by initializing the table ID field in the route configuration
    structure in the IOCTL path.
    
    Before the fix:
    
     # ip route add default via 192.0.2.2
     # route add default gw 192.0.2.2
     # ip -4 r show default
     # default via 192.0.2.2 dev dummy10
     # default via 192.0.2.2 dev dummy10
    
    After the fix:
    
     # ip route add default via 192.0.2.2
     # route add default gw 192.0.2.2
     SIOCADDRT: File exists
     # ip -4 r show default
     default via 192.0.2.2 dev dummy10
    
    Audited the code paths to ensure there are no other paths that do not
    properly initialize the route configuration structure when installing a
    route.
    
    Fixes: 5a56a0b3a45d ("net: Don't delete routes in different VRFs")
    Fixes: f96a3d74554d ("ipv4: Fix incorrect route flushing when source address is deleted")
    Reported-by: gaoxingwang <[email protected]>
    Link: https://lore.kernel.org/netdev/[email protected]/
    Tested-by: gaoxingwang <[email protected]>
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
Linux: Linux 4.14.311 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Mar 22 13:26:16 2023 +0100

    Linux 4.14.311
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Chris Paterson (CIP) <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
media: m5mols: fix off-by-one loop termination error [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Fri Mar 17 13:51:17 2023 -0700

    media: m5mols: fix off-by-one loop termination error
    
    [ Upstream commit efbcbb12ee99f750c9f25c873b55ad774871de2a ]
    
    The __find_restype() function loops over the m5mols_default_ffmt[]
    array, and the termination condition ends up being wrong: instead of
    stopping when the iterator becomes the size of the array it traverses,
    it stops after it has already overshot the array.
    
    Now, in practice this doesn't likely matter, because the code will
    always find the entry it looks for, and will thus return early and never
    hit that last extra iteration.
    
    But it turns out that clang will unroll the loop fully, because it has
    only two iterations (well, three due to the off-by-one bug), and then
    clang will end up just giving up in the middle of the loop unrolling
    when it notices that the code walks past the end of the array.
    
    And that made 'objtool' very unhappy indeed, because the generated code
    just falls off the edge of the universe, and ends up falling through to
    the next function, causing this warning:
    
       drivers/media/i2c/m5mols/m5mols.o: warning: objtool: m5mols_set_fmt() falls through to next function m5mols_get_frame_desc()
    
    Fix the loop ending condition.
    
    Reported-by: Jens Axboe <[email protected]>
    Analyzed-by: Miguel Ojeda <[email protected]>
    Analyzed-by: Nick Desaulniers <[email protected]>
    Link: https://lore.kernel.org/linux-block/CAHk-=wgTSdKYbmB1JYM5vmHMcD9J9UZr0mn7BOYM_LudrP+Xvw@mail.gmail.com/
    Fixes: bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP")
    Cc: HeungJun, Kim <[email protected]>
    Cc: Sylwester Nawrocki <[email protected]>
    Cc: Kyungmin Park <[email protected]>
    Cc: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mmc: atmel-mci: fix race between stop command and start of next command [+ + +]
Author: Tobias Schramm <[email protected]>
Date:   Fri Dec 30 20:43:15 2022 +0100

    mmc: atmel-mci: fix race between stop command and start of next command
    
    [ Upstream commit eca5bd666b0aa7dc0bca63292e4778968241134e ]
    
    This commit fixes a race between completion of stop command and start of a
    new command.
    Previously the command ready interrupt was enabled before stop command
    was written to the command register. This caused the command ready
    interrupt to fire immediately since the CMDRDY flag is asserted constantly
    while there is no command in progress.
    Consequently the command state machine will immediately advance to the
    next state when the tasklet function is executed again, no matter
    actual completion state of the stop command.
    Thus a new command can then be dispatched immediately, interrupting and
    corrupting the stop command on the CMD line.
    Fix that by dropping the command ready interrupt enable before calling
    atmci_send_stop_cmd. atmci_send_stop_cmd does already enable the
    command ready interrupt, no further writes to ATMCI_IER are necessary.
    
    Signed-off-by: Tobias Schramm <[email protected]>
    Acked-by: Ludovic Desroches <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net/iucv: Fix size of interrupt data [+ + +]
Author: Alexandra Winter <[email protected]>
Date:   Wed Mar 15 14:14:35 2023 +0100

    net/iucv: Fix size of interrupt data
    
    [ Upstream commit 3d87debb8ed2649608ff432699e7c961c0c6f03b ]
    
    iucv_irq_data needs to be 4 bytes larger.
    These bytes are not used by the iucv module, but written by
    the z/VM hypervisor in case a CPU is deconfigured.
    
    Reported as:
    BUG dma-kmalloc-64 (Not tainted): kmalloc Redzone overwritten
    -----------------------------------------------------------------------------
    0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xcc
    Allocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1
    __kmem_cache_alloc_node+0x166/0x450
    kmalloc_node_trace+0x3a/0x70
    iucv_cpu_prepare+0x44/0xd0
    cpuhp_invoke_callback+0x156/0x2f0
    cpuhp_issue_call+0xf0/0x298
    __cpuhp_setup_state_cpuslocked+0x136/0x338
    __cpuhp_setup_state+0xf4/0x288
    iucv_init+0xf4/0x280
    do_one_initcall+0x78/0x390
    do_initcalls+0x11a/0x140
    kernel_init_freeable+0x25e/0x2a0
    kernel_init+0x2e/0x170
    __ret_from_fork+0x3c/0x58
    ret_from_fork+0xa/0x40
    Freed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1
    __kmem_cache_free+0x308/0x358
    iucv_init+0x92/0x280
    do_one_initcall+0x78/0x390
    do_initcalls+0x11a/0x140
    kernel_init_freeable+0x25e/0x2a0
    kernel_init+0x2e/0x170
    __ret_from_fork+0x3c/0x58
    ret_from_fork+0xa/0x40
    Slab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0|
    Object 0x0000000000400540 @offset=1344 fp=0x0000000000000000
    Redzone  0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Object   0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00  ................
    Object   0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2  ................
    Object   0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc  ................
    Object   0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................
    Redzone  0000000000400580: cc cc cc cc cc cc cc cc                          ........
    Padding  00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
    Padding  00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
    Padding  00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ
    CPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1
    Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)
    Call Trace:
    [<000000032aa034ec>] dump_stack_lvl+0xac/0x100
    [<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140
    [<0000000329f5aa78>] check_object+0x370/0x3c0
    [<0000000329f5ede6>] free_debug_processing+0x15e/0x348
    [<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0
    [<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8
    [<0000000329f61768>] __kmem_cache_free+0x308/0x358
    [<000000032a91465c>] iucv_cpu_dead+0x6c/0x88
    [<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0
    [<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0
    [<0000000329c3243e>] cpu_device_down+0x4e/0x78
    [<000000032a61dee0>] device_offline+0xc8/0x118
    [<000000032a61e048>] online_store+0x60/0xe0
    [<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8
    [<0000000329fab65c>] vfs_write+0x174/0x360
    [<0000000329fab9fc>] ksys_write+0x74/0x100
    [<000000032aa03a5a>] __do_syscall+0x1da/0x208
    [<000000032aa177b2>] system_call+0x82/0xb0
    INFO: lockdep is turned off.
    FIX dma-kmalloc-64: Restoring kmalloc Redzone 0x0000000000400564-0x0000000000400567=0xcc
    FIX dma-kmalloc-64: Object at 0x0000000000400540 not freed
    
    Fixes: 2356f4cb1911 ("[S390]: Rewrite of the IUCV base code, part 2")
    Signed-off-by: Alexandra Winter <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: phy: smsc: bail out in lan87xx_read_status if genphy_read_status fails [+ + +]
Author: Heiner Kallweit <[email protected]>
Date:   Sat Mar 11 19:34:45 2023 +0100

    net: phy: smsc: bail out in lan87xx_read_status if genphy_read_status fails
    
    [ Upstream commit c22c3bbf351e4ce905f082649cffa1ff893ea8c1 ]
    
    If genphy_read_status fails then further access to the PHY may result
    in unpredictable behavior. To prevent this bail out immediately if
    genphy_read_status fails.
    
    Fixes: 4223dbffed9f ("net: phy: smsc: Re-enable EDPD mode for LAN87xx")
    Signed-off-by: Heiner Kallweit <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: tunnels: annotate lockless accesses to dev->needed_headroom [+ + +]
Author: Eric Dumazet <[email protected]>
Date:   Fri Mar 10 19:11:09 2023 +0000

    net: tunnels: annotate lockless accesses to dev->needed_headroom
    
    [ Upstream commit 4b397c06cb987935b1b097336532aa6b4210e091 ]
    
    IP tunnels can apparently update dev->needed_headroom
    in their xmit path.
    
    This patch takes care of three tunnels xmit, and also the
    core LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA()
    helpers.
    
    More changes might be needed for completeness.
    
    BUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmit
    
    read to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1:
    ip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228
    ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430
    dst_output include/net/dst.h:444 [inline]
    ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126
    iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82
    ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    
    write to 0xffff88815b9da0ec of 2 bytes by task 2379 on cpu 0:
    ip_tunnel_xmit+0x1294/0x1730 net/ipv4/ip_tunnel.c:804
    __gre_xmit net/ipv4/ip_gre.c:469 [inline]
    ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661
    __netdev_start_xmit include/linux/netdevice.h:4881 [inline]
    netdev_start_xmit include/linux/netdevice.h:4895 [inline]
    xmit_one net/core/dev.c:3580 [inline]
    dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596
    __dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246
    dev_queue_xmit include/linux/netdevice.h:3051 [inline]
    neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623
    neigh_output include/net/neighbour.h:546 [inline]
    ip6_finish_output2+0x9bc/0xc50 net/ipv6/ip6_output.c:134
    __ip6_finish_output net/ipv6/ip6_output.c:195 [inline]
    ip6_finish_output+0x39a/0x4e0 net/ipv6/ip6_output.c:206
    NF_HOOK_COND include/linux/netfilter.h:291 [inline]
    ip6_output+0xeb/0x220 net/ipv6/ip6_output.c:227
    dst_output include/net/dst.h:444 [inline]
    NF_HOOK include/linux/netfilter.h:302 [inline]
    mld_sendpack+0x438/0x6a0 net/ipv6/mcast.c:1820
    mld_send_cr net/ipv6/mcast.c:2121 [inline]
    mld_ifc_work+0x519/0x7b0 net/ipv6/mcast.c:2653
    process_one_work+0x3e6/0x750 kernel/workqueue.c:2390
    worker_thread+0x5f2/0xa10 kernel/workqueue.c:2537
    kthread+0x1ac/0x1e0 kernel/kthread.c:376
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
    
    value changed: 0x0dd4 -> 0x0e14
    
    Reported by Kernel Concurrency Sanitizer on:
    CPU: 0 PID: 2379 Comm: kworker/0:0 Not tainted 6.3.0-rc1-syzkaller-00002-g8ca09d5fa354-dirty #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
    Workqueue: mld mld_ifc_work
    
    Fixes: 8eb30be0352d ("ipv6: Create ip6_tnl_xmit")
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: smsc75xx: Limit packet length to skb->len [+ + +]
Author: Szymon Heidrich <[email protected]>
Date:   Mon Mar 13 23:00:45 2023 +0100

    net: usb: smsc75xx: Limit packet length to skb->len
    
    [ Upstream commit d8b228318935044dafe3a5bc07ee71a1f1424b8d ]
    
    Packet length retrieved from skb data may be larger than
    the actual socket buffer length (up to 9026 bytes). In such
    case the cloned skb passed up the network stack will leak
    kernel memory contents.
    
    Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver")
    Signed-off-by: Szymon Heidrich <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: usb: smsc75xx: Move packet length check to prevent kernel panic in skb_pull [+ + +]
Author: Szymon Heidrich <[email protected]>
Date:   Thu Mar 16 12:05:40 2023 +0100

    net: usb: smsc75xx: Move packet length check to prevent kernel panic in skb_pull
    
    [ Upstream commit 43ffe6caccc7a1bb9d7442fbab521efbf6c1378c ]
    
    Packet length check needs to be located after size and align_count
    calculation to prevent kernel panic in skb_pull() in case
    rx_cmd_a & RX_CMD_A_RED evaluates to true.
    
    Fixes: d8b228318935 ("net: usb: smsc75xx: Limit packet length to skb->len")
    Signed-off-by: Szymon Heidrich <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfc: pn533: initialize struct pn533_out_arg properly [+ + +]
Author: Fedor Pchelkin <[email protected]>
Date:   Thu Mar 9 19:50:50 2023 +0300

    nfc: pn533: initialize struct pn533_out_arg properly
    
    [ Upstream commit 484b7059796e3bc1cb527caa61dfc60da649b4f6 ]
    
    struct pn533_out_arg used as a temporary context for out_urb is not
    initialized properly. Its uninitialized 'phy' field can be dereferenced in
    error cases inside pn533_out_complete() callback function. It causes the
    following failure:
    
    general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc3-next-20230110-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
    RIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441
    Call Trace:
     <IRQ>
     __usb_hcd_giveback_urb+0x2b6/0x5c0 drivers/usb/core/hcd.c:1671
     usb_hcd_giveback_urb+0x384/0x430 drivers/usb/core/hcd.c:1754
     dummy_timer+0x1203/0x32d0 drivers/usb/gadget/udc/dummy_hcd.c:1988
     call_timer_fn+0x1da/0x800 kernel/time/timer.c:1700
     expire_timers+0x234/0x330 kernel/time/timer.c:1751
     __run_timers kernel/time/timer.c:2022 [inline]
     __run_timers kernel/time/timer.c:1995 [inline]
     run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035
     __do_softirq+0x1fb/0xaf6 kernel/softirq.c:571
     invoke_softirq kernel/softirq.c:445 [inline]
     __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650
     irq_exit_rcu+0x9/0x20 kernel/softirq.c:662
     sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1107
    
    Initialize the field with the pn533_usb_phy currently used.
    
    Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
    
    Fixes: 9dab880d675b ("nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()")
    Reported-by: [email protected]
    Signed-off-by: Fedor Pchelkin <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nfc: st-nci: Fix use after free bug in ndlc_remove due to race condition [+ + +]
Author: Zheng Wang <[email protected]>
Date:   Mon Mar 13 00:08:37 2023 +0800

    nfc: st-nci: Fix use after free bug in ndlc_remove due to race condition
    
    [ Upstream commit 5000fe6c27827a61d8250a7e4a1d26c3298ef4f6 ]
    
    This bug influences both st_nci_i2c_remove and st_nci_spi_remove.
    Take st_nci_i2c_remove as an example.
    
    In st_nci_i2c_probe, it called ndlc_probe and bound &ndlc->sm_work
    with llt_ndlc_sm_work.
    
    When it calls ndlc_recv or timeout handler, it will finally call
    schedule_work to start the work.
    
    When we call st_nci_i2c_remove to remove the driver, there
    may be a sequence as follows:
    
    Fix it by finishing the work before cleanup in ndlc_remove
    
    CPU0                  CPU1
    
                        |llt_ndlc_sm_work
    st_nci_i2c_remove   |
      ndlc_remove       |
         st_nci_remove  |
         nci_free_device|
         kfree(ndev)    |
    //free ndlc->ndev   |
                        |llt_ndlc_rcv_queue
                        |nci_recv_frame
                        |//use ndlc->ndev
    
    Fixes: 35630df68d60 ("NFC: st21nfcb: Add driver for STMicroelectronics ST21NFCB NFC chip")
    Signed-off-by: Zheng Wang <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nvmet: avoid potential UAF in nvmet_req_complete() [+ + +]
Author: Damien Le Moal <[email protected]>
Date:   Mon Mar 6 10:13:13 2023 +0900

    nvmet: avoid potential UAF in nvmet_req_complete()
    
    [ Upstream commit 6173a77b7e9d3e202bdb9897b23f2a8afe7bf286 ]
    
    An nvme target ->queue_response() operation implementation may free the
    request passed as argument. Such implementation potentially could result
    in a use after free of the request pointer when percpu_ref_put() is
    called in nvmet_req_complete().
    
    Avoid such problem by using a local variable to save the sq pointer
    before calling __nvmet_req_complete(), thus avoiding dereferencing the
    req pointer after that function call.
    
    Fixes: a07b4970f464 ("nvmet: add a generic NVMe target")
    Signed-off-by: Damien Le Moal <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
qed/qed_dev: guard against a possible division by zero [+ + +]
Author: Daniil Tatianin <[email protected]>
Date:   Thu Mar 9 23:15:56 2023 +0300

    qed/qed_dev: guard against a possible division by zero
    
    [ Upstream commit 1a9dc5610ef89d807acdcfbff93a558f341a44da ]
    
    Previously we would divide total_left_rate by zero if num_vports
    happened to be 1 because non_requested_count is calculated as
    num_vports - req_count. Guard against this by validating num_vports at
    the beginning and returning an error otherwise.
    
    Found by Linux Verification Center (linuxtesting.org) with the SVACE
    static analysis tool.
    
    Fixes: bcd197c81f63 ("qed: Add vport WFQ configuration APIs")
    Signed-off-by: Daniil Tatianin <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
serial: 8250_em: Fix UART port type [+ + +]
Author: Biju Das <[email protected]>
Date:   Mon Feb 27 11:41:46 2023 +0000

    serial: 8250_em: Fix UART port type
    
    commit 32e293be736b853f168cd065d9cbc1b0c69f545d upstream.
    
    As per HW manual for  EMEV2 "R19UH0040EJ0400 Rev.4.00", the UART
    IP found on EMMA mobile SoC is Register-compatible with the
    general-purpose 16750 UART chip. Fix UART port type as 16750 and
    enable 64-bytes fifo support.
    
    Fixes: 22886ee96895 ("serial8250-em: Emma Mobile UART driver V2")
    Cc: [email protected]
    Signed-off-by: Biju Das <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [biju: manually fixed the conflicts]
    Signed-off-by: Biju Das <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
sh: intc: Avoid spurious sizeof-pointer-div warning [+ + +]
Author: Michael Karcher <[email protected]>
Date:   Tue Jan 24 22:48:16 2023 +0100

    sh: intc: Avoid spurious sizeof-pointer-div warning
    
    [ Upstream commit 250870824c1cf199b032b1ef889c8e8d69d9123a ]
    
    GCC warns about the pattern sizeof(void*)/sizeof(void), as it looks like
    the abuse of a pattern to calculate the array size. This pattern appears
    in the unevaluated part of the ternary operator in _INTC_ARRAY if the
    parameter is NULL.
    
    The replacement uses an alternate approach to return 0 in case of NULL
    which does not generate the pattern sizeof(void*)/sizeof(void), but still
    emits the warning if _INTC_ARRAY is called with a nonarray parameter.
    
    This patch is required for successful compilation with -Werror enabled.
    
    The idea to use _Generic for type distinction is taken from Comment #7
    in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483 by Jakub Jelinek
    
    Signed-off-by: Michael Karcher <[email protected]>
    Acked-by: Randy Dunlap <[email protected]> # build-tested
    Link: https://lore.kernel.org/r/619fa552-c988-35e5-b1d7-fe256c46a272@mkarcher.dialup.fu-berlin.de
    Signed-off-by: John Paul Adrian Glaubitz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tcp: tcp_make_synack() can be called from process context [+ + +]
Author: Breno Leitao <[email protected]>
Date:   Wed Mar 8 11:07:45 2023 -0800

    tcp: tcp_make_synack() can be called from process context
    
    [ Upstream commit bced3f7db95ff2e6ca29dc4d1c9751ab5e736a09 ]
    
    tcp_rtx_synack() now could be called in process context as explained in
    0a375c822497 ("tcp: tcp_rtx_synack() can be called from process
    context").
    
    tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPU
    variables with preemption enabled. This causes the following BUG:
    
        BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464
        caller is tcp_make_synack+0x841/0xac0
        Call Trace:
         <TASK>
         dump_stack_lvl+0x10d/0x1a0
         check_preemption_disabled+0x104/0x110
         tcp_make_synack+0x841/0xac0
         tcp_v6_send_synack+0x5c/0x450
         tcp_rtx_synack+0xeb/0x1f0
         inet_rtx_syn_ack+0x34/0x60
         tcp_check_req+0x3af/0x9e0
         tcp_rcv_state_process+0x59b/0x2030
         tcp_v6_do_rcv+0x5f5/0x700
         release_sock+0x3a/0xf0
         tcp_sendmsg+0x33/0x40
         ____sys_sendmsg+0x2f2/0x490
         __sys_sendmsg+0x184/0x230
         do_syscall_64+0x3d/0x90
    
    Avoid calling __TCP_INC_STATS() with will touch per-cpu variables. Use
    TCP_INC_STATS() which is safe to be called from context switch.
    
    Fixes: 8336886f786f ("tcp: TCP Fast Open Server - support TFO listeners")
    Signed-off-by: Breno Leitao <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>