Linux 4.14.299

 
ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices [+ + +]
Author: John Veness <[email protected]>
Date:   Fri Jun 24 15:07:57 2022 +0100

    ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devices
    
    commit 6e2c9105e0b743c92a157389d40f00b81bdd09fe upstream.
    
    Treat the claimed 96kHz 1ch in the descriptors as 48kHz 2ch, so that
    the audio stream doesn't sound mono. Also fix initial stream
    alignment, so that left and right channels are in the correct order.
    
    Signed-off-by: John Veness <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ata: pata_legacy: fix pdc20230_set_piomode() [+ + +]
Author: Sergey Shtylyov <[email protected]>
Date:   Sat Oct 29 00:07:06 2022 +0300

    ata: pata_legacy: fix pdc20230_set_piomode()
    
    [ Upstream commit 171a93182eccd6e6835d2c86b40787f9f832efaa ]
    
    Clang gives a warning when compiling pata_legacy.c with 'make W=1' about
    the 'rt' local variable in pdc20230_set_piomode() being set but unused.
    Quite obviously, there is an outb() call missing to write back the updated
    variable. Moreover, checking the docs by Petr Soucek revealed that bitwise
    AND should have been done with a negated timing mask and the master/slave
    timing masks were swapped while updating...
    
    Fixes: 669a5db411d8 ("[libata] Add a bunch of PATA drivers.")
    Reported-by: Damien Le Moal <[email protected]>
    Signed-off-by: Sergey Shtylyov <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
block, bfq: protect 'bfqd->queued' by 'bfqd->lock' [+ + +]
Author: Yu Kuai <[email protected]>
Date:   Fri May 13 10:35:06 2022 +0800

    block, bfq: protect 'bfqd->queued' by 'bfqd->lock'
    
    commit 181490d5321806e537dc5386db5ea640b826bf78 upstream.
    
    If bfq_schedule_dispatch() is called from bfq_idle_slice_timer_body(),
    then 'bfqd->queued' is read without holding 'bfqd->lock'. This is
    wrong since it can be wrote concurrently.
    
    Fix the problem by holding 'bfqd->lock' in such case.
    
    Signed-off-by: Yu Kuai <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Reviewed-by: Chaitanya Kulkarni <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Cc: Khazhy Kumykov <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Bluetooth: L2CAP: Fix attempting to access uninitialized memory [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Mon Oct 31 16:10:52 2022 -0700

    Bluetooth: L2CAP: Fix attempting to access uninitialized memory
    
    commit b1a2cd50c0357f243b7435a732b4e62ba3157a2e upstream.
    
    On l2cap_parse_conf_req the variable efs is only initialized if
    remote_efs has been set.
    
    CVE: CVE-2022-42895
    CC: [email protected]
    Reported-by: Tamás Koczka <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Reviewed-by: Tedd Ho-Jeong An <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu [+ + +]
Author: Maxim Mikityanskiy <[email protected]>
Date:   Wed Oct 5 00:27:18 2022 +0300

    Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
    
    [ Upstream commit 3aff8aaca4e36dc8b17eaa011684881a80238966 ]
    
    Fix the race condition between the following two flows that run in
    parallel:
    
    1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
       __sock_queue_rcv_skb.
    
    2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
    
    An SKB can be queued by the first flow and immediately dequeued and
    freed by the second flow, therefore the callers of l2cap_reassemble_sdu
    can't use the SKB after that function returns. However, some places
    continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
    short time after l2cap_reassemble_sdu returns, leading to a
    use-after-free condition (the stack trace is below, line numbers for
    kernel 5.19.8).
    
    Fix it by keeping a local copy of struct l2cap_ctrl.
    
    BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
    Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
    
    Workqueue: hci0 hci_rx_work [bluetooth]
    Call Trace:
     <TASK>
     dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
     print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)
     ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
     kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)
     ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
     l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
     l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth
     ret_from_fork (arch/x86/entry/entry_64.S:306)
     </TASK>
    
    Allocated by task 43169:
     kasan_save_stack (mm/kasan/common.c:39)
     __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
     kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)
     __alloc_skb (net/core/skbuff.c:414)
     l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth
     l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth
     hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth
     process_one_work (kernel/workqueue.c:2289)
     worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)
     kthread (kernel/kthread.c:376)
     ret_from_fork (arch/x86/entry/entry_64.S:306)
    
    Freed by task 27920:
     kasan_save_stack (mm/kasan/common.c:39)
     kasan_set_track (mm/kasan/common.c:45)
     kasan_set_free_info (mm/kasan/generic.c:372)
     ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)
     slab_free_freelist_hook (mm/slub.c:1780)
     kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)
     skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)
     bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth
     l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth
     sock_read_iter (net/socket.c:1087)
     new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)
     vfs_read (fs/read_write.c:482)
     ksys_read (fs/read_write.c:620)
     do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
    
    Link: https://lore.kernel.org/linux-bluetooth/[email protected]om/T/#u
    Fixes: d2a7ac5d5d3a ("Bluetooth: Add the ERTM receive state machine")
    Fixes: 4b51dae96731 ("Bluetooth: Add streaming mode receive and incoming packet classifier")
    Signed-off-by: Maxim Mikityanskiy <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del() [+ + +]
Author: Zhengchao Shao <[email protected]>
Date:   Mon Oct 17 15:58:13 2022 +0800

    Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del()
    
    [ Upstream commit 0d0e2d032811280b927650ff3c15fe5020e82533 ]
    
    When l2cap_recv_frame() is invoked to receive data, and the cid is
    L2CAP_CID_A2MP, if the channel does not exist, it will create a channel.
    However, after a channel is created, the hold operation of the channel
    is not performed. In this case, the value of channel reference counting
    is 1. As a result, after hci_error_reset() is triggered, l2cap_conn_del()
    invokes the close hook function of A2MP to release the channel. Then
     l2cap_chan_unlock(chan) will trigger UAF issue.
    
    The process is as follows:
    Receive data:
    l2cap_data_channel()
        a2mp_channel_create()  --->channel ref is 2
        l2cap_chan_put()       --->channel ref is 1
    
    Triger event:
        hci_error_reset()
            hci_dev_do_close()
            ...
            l2cap_disconn_cfm()
                l2cap_conn_del()
                    l2cap_chan_hold()    --->channel ref is 2
                    l2cap_chan_del()     --->channel ref is 1
                    a2mp_chan_close_cb() --->channel ref is 0, release channel
                    l2cap_chan_unlock()  --->UAF of channel
    
    The detailed Call Trace is as follows:
    BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0xa6/0x5e0
    Read of size 8 at addr ffff8880160664b8 by task kworker/u11:1/7593
    Workqueue: hci0 hci_error_reset
    Call Trace:
     <TASK>
     dump_stack_lvl+0xcd/0x134
     print_report.cold+0x2ba/0x719
     kasan_report+0xb1/0x1e0
     kasan_check_range+0x140/0x190
     __mutex_unlock_slowpath+0xa6/0x5e0
     l2cap_conn_del+0x404/0x7b0
     l2cap_disconn_cfm+0x8c/0xc0
     hci_conn_hash_flush+0x11f/0x260
     hci_dev_close_sync+0x5f5/0x11f0
     hci_dev_do_close+0x2d/0x70
     hci_error_reset+0x9e/0x140
     process_one_work+0x98a/0x1620
     worker_thread+0x665/0x1080
     kthread+0x2e4/0x3a0
     ret_from_fork+0x1f/0x30
     </TASK>
    
    Allocated by task 7593:
     kasan_save_stack+0x1e/0x40
     __kasan_kmalloc+0xa9/0xd0
     l2cap_chan_create+0x40/0x930
     amp_mgr_create+0x96/0x990
     a2mp_channel_create+0x7d/0x150
     l2cap_recv_frame+0x51b8/0x9a70
     l2cap_recv_acldata+0xaa3/0xc00
     hci_rx_work+0x702/0x1220
     process_one_work+0x98a/0x1620
     worker_thread+0x665/0x1080
     kthread+0x2e4/0x3a0
     ret_from_fork+0x1f/0x30
    
    Freed by task 7593:
     kasan_save_stack+0x1e/0x40
     kasan_set_track+0x21/0x30
     kasan_set_free_info+0x20/0x30
     ____kasan_slab_free+0x167/0x1c0
     slab_free_freelist_hook+0x89/0x1c0
     kfree+0xe2/0x580
     l2cap_chan_put+0x22a/0x2d0
     l2cap_conn_del+0x3fc/0x7b0
     l2cap_disconn_cfm+0x8c/0xc0
     hci_conn_hash_flush+0x11f/0x260
     hci_dev_close_sync+0x5f5/0x11f0
     hci_dev_do_close+0x2d/0x70
     hci_error_reset+0x9e/0x140
     process_one_work+0x98a/0x1620
     worker_thread+0x665/0x1080
     kthread+0x2e4/0x3a0
     ret_from_fork+0x1f/0x30
    
    Last potentially related work creation:
     kasan_save_stack+0x1e/0x40
     __kasan_record_aux_stack+0xbe/0xd0
     call_rcu+0x99/0x740
     netlink_release+0xe6a/0x1cf0
     __sock_release+0xcd/0x280
     sock_close+0x18/0x20
     __fput+0x27c/0xa90
     task_work_run+0xdd/0x1a0
     exit_to_user_mode_prepare+0x23c/0x250
     syscall_exit_to_user_mode+0x19/0x50
     do_syscall_64+0x42/0x80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Second to last potentially related work creation:
     kasan_save_stack+0x1e/0x40
     __kasan_record_aux_stack+0xbe/0xd0
     call_rcu+0x99/0x740
     netlink_release+0xe6a/0x1cf0
     __sock_release+0xcd/0x280
     sock_close+0x18/0x20
     __fput+0x27c/0xa90
     task_work_run+0xdd/0x1a0
     exit_to_user_mode_prepare+0x23c/0x250
     syscall_exit_to_user_mode+0x19/0x50
     do_syscall_64+0x42/0x80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Fixes: d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put")
    Signed-off-by: Zhengchao Shao <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
btrfs: fix inode list leak during backref walking at resolve_indirect_refs() [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Tue Nov 1 16:15:37 2022 +0000

    btrfs: fix inode list leak during backref walking at resolve_indirect_refs()
    
    [ Upstream commit 5614dc3a47e3310fbc77ea3b67eaadd1c6417bf1 ]
    
    During backref walking, at resolve_indirect_refs(), if we get an error
    we jump to the 'out' label and call ulist_free() on the 'parents' ulist,
    which frees all the elements in the ulist - however that does not free
    any inode lists that may be attached to elements, through the 'aux' field
    of a ulist node, so we end up leaking lists if we have any attached to
    the unodes.
    
    Fix this by calling free_leaf_list() instead of ulist_free() when we exit
    from resolve_indirect_refs(). The static function free_leaf_list() is
    moved up for this to be possible and it's slightly simplified by removing
    unnecessary code.
    
    Fixes: 3301958b7c1d ("Btrfs: add inodes before dropping the extent lock in find_all_leafs")
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

btrfs: fix type of parameter generation in btrfs_get_dentry [+ + +]
Author: David Sterba <[email protected]>
Date:   Tue Oct 18 16:05:52 2022 +0200

    btrfs: fix type of parameter generation in btrfs_get_dentry
    
    commit 2398091f9c2c8e0040f4f9928666787a3e8108a7 upstream.
    
    The type of parameter generation has been u32 since the beginning,
    however all callers pass a u64 generation, so unify the types to prevent
    potential loss.
    
    CC: [email protected] # 4.9+
    Reviewed-by: Josef Bacik <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

btrfs: fix ulist leaks in error paths of qgroup self tests [+ + +]
Author: Filipe Manana <[email protected]>
Date:   Tue Nov 1 16:15:39 2022 +0000

    btrfs: fix ulist leaks in error paths of qgroup self tests
    
    [ Upstream commit d37de92b38932d40e4a251e876cc388f9aee5f42 ]
    
    In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests,
    if we fail to add the tree ref, remove the extent item or remove the
    extent ref, we are returning from the test function without freeing the
    "old_roots" ulist that was allocated by the previous calls to
    btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.
    
    Fixes: 442244c96332 ("btrfs: qgroup: Switch self test to extent-oriented qgroup mechanism.")
    Signed-off-by: Filipe Manana <[email protected]>
    Signed-off-by: David Sterba <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
capabilities: fix potential memleak on error path from vfs_getxattr_alloc() [+ + +]
Author: Gaosheng Cui <[email protected]>
Date:   Tue Oct 25 21:33:57 2022 +0800

    capabilities: fix potential memleak on error path from vfs_getxattr_alloc()
    
    commit 8cf0a1bc12870d148ae830a4ba88cfdf0e879cee upstream.
    
    In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to
    complete the memory allocation of tmpbuf, if we have completed
    the memory allocation of tmpbuf, but failed to call handler->get(...),
    there will be a memleak in below logic:
    
      |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...)
        |           /* ^^^ alloc for tmpbuf */
        |-- value = krealloc(*xattr_value, error + 1, flags)
        |           /* ^^^ alloc memory */
        |-- error = handler->get(handler, ...)
        |           /* error! */
        |-- *xattr_value = value
        |           /* xattr_value is &tmpbuf (memory leak!) */
    
    So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it.
    
    Cc: [email protected]
    Fixes: 8db6c34f1dbc ("Introduce v3 namespaced file capabilities")
    Signed-off-by: Gaosheng Cui <[email protected]>
    Acked-by: Serge Hallyn <[email protected]>
    [PM: subject line and backtrace tweaks]
    Signed-off-by: Paul Moore <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
efi: random: reduce seed size to 32 bytes [+ + +]
Author: Ard Biesheuvel <[email protected]>
Date:   Thu Oct 20 10:39:08 2022 +0200

    efi: random: reduce seed size to 32 bytes
    
    commit 161a438d730dade2ba2b1bf8785f0759aba4ca5f upstream.
    
    We no longer need at least 64 bytes of random seed to permit the early
    crng init to complete. The RNG is now based on Blake2s, so reduce the
    EFI seed size to the Blake2s hash size, which is sufficient for our
    purposes.
    
    While at it, drop the READ_ONCE(), which was supposed to prevent size
    from being evaluated after seed was unmapped. However, this cannot
    actually happen, so READ_ONCE() is unnecessary here.
    
    Cc: <[email protected]> # v4.14+
    Signed-off-by: Ard Biesheuvel <[email protected]>
    Reviewed-by: Jason A. Donenfeld <[email protected]>
    Acked-by: Ilias Apalodimas <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ext4: fix warning in 'ext4_da_release_space' [+ + +]
Author: Ye Bin <[email protected]>
Date:   Tue Oct 18 10:27:01 2022 +0800

    ext4: fix warning in 'ext4_da_release_space'
    
    commit 1b8f787ef547230a3249bcf897221ef0cc78481b upstream.
    
    Syzkaller report issue as follows:
    EXT4-fs (loop0): Free/Dirty block details
    EXT4-fs (loop0): free_blocks=0
    EXT4-fs (loop0): dirty_blocks=0
    EXT4-fs (loop0): Block reservation details
    EXT4-fs (loop0): i_reserved_data_blocks=0
    EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks
    ------------[ cut here ]------------
    WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524
    Modules linked in:
    CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
    Workqueue: writeback wb_workfn (flush-7:0)
    RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528
    RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296
    RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00
    RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000
    RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5
    R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000
    R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740
    FS:  0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     <TASK>
     ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461
     mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589
     ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852
     do_writepages+0x3c3/0x680 mm/page-writeback.c:2469
     __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587
     writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870
     wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044
     wb_do_writeback fs/fs-writeback.c:2187 [inline]
     wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227
     process_one_work+0x877/0xdb0 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>
    
    Above issue may happens as follows:
    ext4_da_write_begin
      ext4_create_inline_data
        ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);
        ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);
    __ext4_ioctl
      ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag
    ext4_da_write_begin
      ext4_da_convert_inline_data_to_extent
        ext4_da_write_inline_data_begin
          ext4_da_map_blocks
            ext4_insert_delayed_block
              if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk))
                if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk))
                  ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1
                   allocated = true;
              ext4_es_insert_delayed_block(inode, lblk, allocated);
    ext4_writepages
      mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC
      mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1
        ext4_es_remove_extent
          ext4_da_release_space(inode, reserved);
            if (unlikely(to_free > ei->i_reserved_data_blocks))
              -> to_free == 1  but ei->i_reserved_data_blocks == 0
              -> then trigger warning as above
    
    To solve above issue, forbid inode do migrate which has inline data.
    
    Cc: [email protected]
    Reported-by: [email protected]
    Signed-off-by: Ye Bin <[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: Greg Kroah-Hartman <[email protected]>

 
i2c: xiic: Add platform module alias [+ + +]
Author: Martin Tůma <[email protected]>
Date:   Tue Oct 18 16:03:37 2022 +0200

    i2c: xiic: Add platform module alias
    
    [ Upstream commit b8caf0a0e04583fb71e21495bef84509182227ea ]
    
    The missing "platform" alias is required for the mgb4 v4l2 driver to load
    the i2c controller driver when probing the HW.
    
    Signed-off-by: Martin Tůma <[email protected]>
    Acked-by: Michal Simek <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ipvs: use explicitly signed chars [+ + +]
Author: Jason A. Donenfeld <[email protected]>
Date:   Wed Oct 26 14:32:16 2022 +0200

    ipvs: use explicitly signed chars
    
    [ Upstream commit 5c26159c97b324dc5174a5713eafb8c855cf8106 ]
    
    The `char` type with no explicit sign is sometimes signed and sometimes
    unsigned. This code will break on platforms such as arm, where char is
    unsigned. So mark it here as explicitly signed, so that the
    todrop_counter decrement and subsequent comparison is correct.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Jason A. Donenfeld <[email protected]>
    Acked-by: Julian Anastasov <[email protected]>
    Signed-off-by: Pablo Neira Ayuso <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
isdn: mISDN: netjet: fix wrong check of device registration [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Mon Oct 31 20:13:41 2022 +0800

    isdn: mISDN: netjet: fix wrong check of device registration
    
    [ Upstream commit bf00f5426074249058a106a6edbb89e4b25a4d79 ]
    
    The class is set in mISDN_register_device(), but if device_add() returns
    error, it will lead to delete a device without added, fix this by using
    device_is_registered() to check if the device is registered.
    
    Fixes: a900845e5661 ("mISDN: Add support for Traverse Technologies NETJet PCI cards")
    Signed-off-by: Yang Yingliang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
KVM: x86: emulator: em_sysexit should update ctxt->mode [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Tue Oct 25 15:47:28 2022 +0300

    KVM: x86: emulator: em_sysexit should update ctxt->mode
    
    commit 5015bb89b58225f97df6ac44383e7e8c8662c8c9 upstream.
    
    SYSEXIT is one of the instructions that can change the
    processor mode, thus ctxt->mode should be updated after it.
    
    Note that this is likely a benign bug, because the only problematic
    mode change is from 32 bit to 64 bit which can lead to truncation of RIP,
    and it is not possible to do with sysexit,
    since sysexit running in 32 bit mode will be limited to 32 bit version.
    
    Signed-off-by: Maxim Levitsky <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: emulator: introduce emulator_recalc_and_set_mode [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Tue Oct 25 15:47:29 2022 +0300

    KVM: x86: emulator: introduce emulator_recalc_and_set_mode
    
    commit d087e0f79fa0dd336a9a6b2f79ec23120f5eff73 upstream.
    
    Some instructions update the cpu execution mode, which needs to update the
    emulation mode.
    
    Extract this code, and make assign_eip_far use it.
    
    assign_eip_far now reads CS, instead of getting it via a parameter,
    which is ok, because callers always assign CS to the same value
    before calling this function.
    
    No functional change is intended.
    
    Signed-off-by: Maxim Levitsky <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: emulator: update the emulation mode after CR0 write [+ + +]
Author: Maxim Levitsky <[email protected]>
Date:   Tue Oct 25 15:47:31 2022 +0300

    KVM: x86: emulator: update the emulation mode after CR0 write
    
    commit ad8f9e69942c7db90758d9d774157e53bce94840 upstream.
    
    Update the emulation mode when handling writes to CR0, because
    toggling CR0.PE switches between Real and Protected Mode, and toggling
    CR0.PG when EFER.LME=1 switches between Long and Protected Mode.
    
    This is likely a benign bug because there is no writeback of state,
    other than the RIP increment, and when toggling CR0.PE, the CPU has
    to execute code from a very low memory address.
    
    Signed-off-by: Maxim Levitsky <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: x86: Mask off reserved bits in CPUID.80000008H [+ + +]
Author: Jim Mattson <[email protected]>
Date:   Thu Sep 29 15:52:00 2022 -0700

    KVM: x86: Mask off reserved bits in CPUID.80000008H
    
    commit 7030d8530e533844e2f4b0e7476498afcd324634 upstream.
    
    KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM
    actually supports. The following ranges of CPUID.80000008H are reserved
    and should be masked off:
        ECX[31:18]
        ECX[11:8]
    
    In addition, the PerfTscSize field at ECX[17:16] should also be zero
    because KVM does not set the PERFTSC bit at CPUID.80000001H.ECX[27].
    
    Fixes: 24c82e576b78 ("KVM: Sanitize cpuid")
    Signed-off-by: Jim Mattson <[email protected]>
    Message-Id: <[email protected]>
    Cc: [email protected]
    Signed-off-by: Paolo Bonzini <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 4.14.299 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Nov 10 15:47:24 2022 +0100

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

 
linux/bits.h: make BIT(), GENMASK(), and friends available in assembly [+ + +]
Author: Masahiro Yamada <[email protected]>
Date:   Tue Jul 16 16:26:57 2019 -0700

    linux/bits.h: make BIT(), GENMASK(), and friends available in assembly
    
    commit 95b980d62d52c4c1768ee719e8db3efe27ef52b2 upstream.
    
    BIT(),  GENMASK(), etc. are useful to define register bits of hardware.
    However, low-level code is often written in assembly, where they are
    not available due to the hard-coded 1UL, 0UL.
    
    In fact, in-kernel headers such as arch/arm64/include/asm/sysreg.h
    use _BITUL() instead of BIT() so that the register bit macros are
    available in assembly.
    
    Using macros in include/uapi/linux/const.h have two reasons:
    
    [1] For use in uapi headers
      We should use underscore-prefixed variants for user-space.
    
    [2] For use in assembly code
      Since _BITUL() uses UL(1) instead of 1UL, it can be used as an
      alternative of BIT().
    
    For [2], it is pretty easy to change BIT() etc. for use in assembly.
    
    This allows to replace _BUTUL() in kernel-space headers with BIT().
    
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Masahiro Yamada <[email protected]>
    Cc: Catalin Marinas <[email protected]m.com>
    Cc: Christian Borntraeger <[email protected]>
    Cc: Heiko Carstens <[email protected]>
    Cc: Vasily Gorbik <[email protected]>
    Cc: Vineet Gupta <[email protected]>
    Cc: Will Deacon <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Nick Desaulniers <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
linux/const.h: move UL() macro to include/linux/const.h [+ + +]
Author: Masahiro Yamada <[email protected]>
Date:   Tue Apr 10 16:36:19 2018 -0700

    linux/const.h: move UL() macro to include/linux/const.h
    
    commit 2dd8a62c647691161a2346546834262597739872 upstream.
    
    ARM, ARM64 and UniCore32 duplicate the definition of UL():
    
      #define UL(x) _AC(x, UL)
    
    This is not actually arch-specific, so it will be useful to move it to a
    common header.  Currently, we only have the uapi variant for
    linux/const.h, so I am creating include/linux/const.h.
    
    I also added _UL(), _ULL() and ULL() because _AC() is mostly used in
    the form either _AC(..., UL) or _AC(..., ULL).  I expect they will be
    replaced in follow-up cleanups.  The underscore-prefixed ones should
    be used for exported headers.
    
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Masahiro Yamada <[email protected]>
    Acked-by: Guan Xuetao <[email protected]>
    Acked-by: Catalin Marinas <[email protected]>
    Acked-by: Russell King <[email protected]>
    Cc: David Howells <[email protected]>
    Cc: Geert Uytterhoeven <[email protected]>
    Cc: Will Deacon <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Nick Desaulniers <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

linux/const.h: prefix include guard of uapi/linux/const.h with _UAPI [+ + +]
Author: Masahiro Yamada <[email protected]>
Date:   Tue Apr 10 16:36:15 2018 -0700

    linux/const.h: prefix include guard of uapi/linux/const.h with _UAPI
    
    commit 2a6cc8a6c0cb44baf7df2f64e5090aaf726002c3 upstream.
    
    Patch series "linux/const.h: cleanups of macros such as UL(), _BITUL(),
    BIT() etc", v3.
    
    ARM, ARM64, UniCore32 define UL() as a shorthand of _AC(..., UL).  More
    architectures may introduce it in the future.
    
    UL() is arch-agnostic, and useful. So let's move it to
    include/linux/const.h
    
    Currently, <asm/memory.h> must be included to use UL().  It pulls in more
    bloats just for defining some bit macros.
    
    I posted V2 one year ago.
    
    The previous posts are:
    https://patchwork.kernel.org/patch/9498273/
    https://patchwork.kernel.org/patch/9498275/
    https://patchwork.kernel.org/patch/9498269/
    https://patchwork.kernel.org/patch/9498271/
    
    At that time, what blocked this series was a comment from
    David Howells:
      You need to be very careful doing this.  Some userspace stuff
      depends on the guard macro names on the kernel header files.
    
    (https://patchwork.kernel.org/patch/9498275/)
    
    Looking at the code closer, I noticed this is not a problem.
    
    See the following line.
    https://github.com/torvalds/linux/blob/v4.16-rc2/scripts/headers_install.sh#L40
    
    scripts/headers_install.sh rips off _UAPI prefix from guard macro names.
    
    I ran "make headers_install" and confirmed the result is what I expect.
    
    So, we can prefix the include guard of include/uapi/linux/const.h,
    and add a new include/linux/const.h.
    
    This patch (of 4):
    
    I am going to add include/linux/const.h for the kernel space.
    
    Add _UAPI to the include guard of include/uapi/linux/const.h to
    prepare for that.
    
    Please notice the guard name of the exported one will be kept as-is.
    So, this commit has no impact to the userspace even if some userspace
    stuff depends on the guard macro names.
    
    scripts/headers_install.sh processes exported headers by SED, and
    rips off "_UAPI" from guard macro names.
    
      #ifndef _UAPI_LINUX_CONST_H
      #define _UAPI_LINUX_CONST_H
    
    will be turned into
    
      #ifndef _LINUX_CONST_H
      #define _LINUX_CONST_H
    
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Masahiro Yamada <[email protected]>
    Cc: David Howells <[email protected]>
    Cc: Will Deacon <[email protected]>
    Cc: Guan Xuetao <[email protected]>
    Cc: Geert Uytterhoeven <[email protected]>
    Cc: Catalin Marinas <[email protected]>
    Cc: Russell King <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    [nd: resolve trivial conflict due to b732e14e6218b being backported before this]
    Signed-off-by: Nick Desaulniers <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
media: dvb-frontends/drxk: initialize err to 0 [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Tue Aug 30 07:59:24 2022 +0200

    media: dvb-frontends/drxk: initialize err to 0
    
    [ Upstream commit 20694e96ca089ce6693c2348f8f628ee621e4e74 ]
    
    Fix a compiler warning:
    
    drivers/media/dvb-frontends/drxk_hard.c: In function 'drxk_read_ucblocks':
    drivers/media/dvb-frontends/drxk_hard.c:6673:21: warning: 'err' may be used uninitialized [-Wmaybe-uninitialized]
     6673 |         *ucblocks = (u32) err;
          |                     ^~~~~~~~~
    drivers/media/dvb-frontends/drxk_hard.c:6663:13: note: 'err' was declared here
     6663 |         u16 err;
          |             ^~~
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE [+ + +]
Author: Hans Verkuil <[email protected]>
Date:   Wed Aug 24 09:02:42 2022 +0200

    media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE
    
    [ Upstream commit 93f65ce036863893c164ca410938e0968964b26c ]
    
    I expect that the hardware will have limited this to 16, but just in
    case it hasn't, check for this corner case.
    
    Signed-off-by: Hans Verkuil <[email protected]>
    Signed-off-by: Mauro Carvalho Chehab <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mISDN: fix possible memory leak in mISDN_register_device() [+ + +]
Author: Yang Yingliang <[email protected]>
Date:   Mon Oct 31 20:13:40 2022 +0800

    mISDN: fix possible memory leak in mISDN_register_device()
    
    [ Upstream commit e7d1d4d9ac0dfa40be4c2c8abd0731659869b297 ]
    
    Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
    bus_id string array"), the name of device is allocated dynamically,
    add put_device() to give up the reference, so that the name can be
    freed in kobject_cleanup() when the refcount is 0.
    
    Set device class before put_device() to avoid null release() function
    WARN message in device_release().
    
    Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
    Signed-off-by: Yang Yingliang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net, neigh: Fix null-ptr-deref in neigh_table_clear() [+ + +]
Author: Chen Zhongjin <[email protected]>
Date:   Tue Nov 1 20:15:52 2022 +0800

    net, neigh: Fix null-ptr-deref in neigh_table_clear()
    
    [ Upstream commit f8017317cb0b279b8ab98b0f3901a2e0ac880dad ]
    
    When IPv6 module gets initialized but hits an error in the middle,
    kenel panic with:
    
    KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]
    CPU: 1 PID: 361 Comm: insmod
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
    RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370
    RSP: 0018:ffff888012677908 EFLAGS: 00000202
    ...
    Call Trace:
     <TASK>
     neigh_table_clear+0x94/0x2d0
     ndisc_cleanup+0x27/0x40 [ipv6]
     inet6_init+0x21c/0x2cb [ipv6]
     do_one_initcall+0xd3/0x4d0
     do_init_module+0x1ae/0x670
    ...
    Kernel panic - not syncing: Fatal exception
    
    When ipv6 initialization fails, it will try to cleanup and calls:
    
    neigh_table_clear()
      neigh_ifdown(tbl, NULL)
        pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev == NULL))
        # dev_net(NULL) triggers null-ptr-deref.
    
    Fix it by passing NULL to pneigh_queue_purge() in neigh_ifdown() if dev
    is NULL, to make kernel not panic immediately.
    
    Fixes: 66ba215cb513 ("neigh: fix possible DoS due to net iface start/stop loop")
    Signed-off-by: Chen Zhongjin <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Reviewed-by: Denis V. Lunev <[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: dsa: Fix possible memory leaks in dsa_loop_init() [+ + +]
Author: Chen Zhongjin <[email protected]>
Date:   Wed Oct 26 10:03:21 2022 +0800

    net: dsa: Fix possible memory leaks in dsa_loop_init()
    
    [ Upstream commit 633efc8b3dc96f56f5a57f2a49764853a2fa3f50 ]
    
    kmemleak reported memory leaks in dsa_loop_init():
    
    kmemleak: 12 new suspected memory leaks
    
    unreferenced object 0xffff8880138ce000 (size 2048):
      comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s)
      backtrace:
        [<000000006a94f1d5>] kmalloc_trace+0x26/0x60
        [<00000000a9c44622>] phy_device_create+0x5d/0x970
        [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0
        [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0
        [<000000008a834798>] fixed_phy_register+0x84/0xb0
        [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop]
        ...
    
    There are two reasons for memleak in dsa_loop_init().
    
    First, fixed_phy_register() create and register phy_device:
    
    fixed_phy_register()
      get_phy_device()
        phy_device_create() # freed by phy_device_free()
      phy_device_register() # freed by phy_device_remove()
    
    But fixed_phy_unregister() only calls phy_device_remove().
    So the memory allocated in phy_device_create() is leaked.
    
    Second, when mdio_driver_register() fail in dsa_loop_init(),
    it just returns and there is no cleanup for phydevs.
    
    Fix the problems by catching the error of mdio_driver_register()
    in dsa_loop_init(), then calling both fixed_phy_unregister() and
    phy_device_free() to release phydevs.
    Also add a function for phydevs cleanup to avoid duplacate.
    
    Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")
    Signed-off-by: Chen Zhongjin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: fec: fix improper use of NETDEV_TX_BUSY [+ + +]
Author: Zhang Changzhong <[email protected]>
Date:   Fri Oct 28 10:09:11 2022 +0800

    net: fec: fix improper use of NETDEV_TX_BUSY
    
    [ Upstream commit 06a4df5863f73af193a4ff7abf7cb04058584f06 ]
    
    The ndo_start_xmit() method must not free skb when returning
    NETDEV_TX_BUSY, since caller is going to requeue freed skb.
    
    Fix it by returning NETDEV_TX_OK in case of dma_map_single() fails.
    
    Fixes: 79f339125ea3 ("net: fec: Add software TSO support")
    Signed-off-by: Zhang Changzhong <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: mdio: fix undefined behavior in bit shift for __mdiobus_register [+ + +]
Author: Gaosheng Cui <[email protected]>
Date:   Mon Oct 31 21:26:45 2022 +0800

    net: mdio: fix undefined behavior in bit shift for __mdiobus_register
    
    [ Upstream commit 40e4eb324c59e11fcb927aa46742d28aba6ecb8a ]
    
    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 drivers/net/phy/mdio_bus.c:586:27
    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
     __mdiobus_register+0x49d/0x4e0
     fixed_mdio_bus_init+0xd8/0x12d
     do_one_initcall+0x76/0x430
     kernel_init_freeable+0x3b3/0x422
     kernel_init+0x24/0x1e0
     ret_from_fork+0x1f/0x30
     </TASK>
    
    Fixes: 4fd5f812c23c ("phylib: allow incremental scanning of an mii bus")
    Signed-off-by: Gaosheng Cui <[email protected]>
    Reviewed-by: Andrew Lunn <[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: sched: Fix use after free in red_enqueue() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Fri Oct 28 18:05:00 2022 +0300

    net: sched: Fix use after free in red_enqueue()
    
    [ Upstream commit 8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9 ]
    
    We can't use "skb" again after passing it to qdisc_enqueue().  This is
    basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb
    len before calling child enqueue").
    
    Fixes: d7f4f332f082 ("sch_red: update backlog as well")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() [+ + +]
Author: Shang XiaoJing <[email protected]>
Date:   Thu Oct 27 22:03:32 2022 +0800

    nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()
    
    [ Upstream commit 93d904a734a74c54d945a9884b4962977f1176cd ]
    
    nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb
    should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()
    will only free skb when i2c_master_send() return >=0, which means skb
    will memleak when i2c_master_send() failed. Free skb no matter whether
    i2c_master_send() succeeds.
    
    Fixes: b5b3e23e4cac ("NFC: nfcmrvl: add i2c driver")
    Signed-off-by: Shang XiaoJing <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

nfc: s3fwrn5: Fix potential memory leak in s3fwrn5_nci_send() [+ + +]
Author: Shang XiaoJing <[email protected]>
Date:   Thu Oct 27 22:03:31 2022 +0800

    nfc: s3fwrn5: Fix potential memory leak in s3fwrn5_nci_send()
    
    [ Upstream commit 3a146b7e3099dc7cf3114f627d9b79291e2d2203 ]
    
    s3fwrn5_nci_send() will call s3fwrn5_i2c_write() or s3fwrn82_uart_write(),
    and free the skb if write() failed. However, even if the write() run
    succeeds, the skb will not be freed in write(). As the result, the skb
    will memleak. s3fwrn5_nci_send() should also free the skb when write()
    succeeds.
    
    Fixes: c04c674fadeb ("nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip")
    Signed-off-by: Shang XiaoJing <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nfs4: Fix kmemleak when allocate slot failed [+ + +]
Author: Zhang Xiaoxu <[email protected]>
Date:   Thu Oct 20 11:20:54 2022 +0800

    nfs4: Fix kmemleak when allocate slot failed
    
    [ Upstream commit 7e8436728e22181c3f12a5dbabd35ed3a8b8c593 ]
    
    If one of the slot allocate failed, should cleanup all the other
    allocated slots, otherwise, the allocated slots will leak:
    
      unreferenced object 0xffff8881115aa100 (size 64):
        comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s)
        hex dump (first 32 bytes):
          00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff  ...s......Z.....
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130
          [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270
          [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90
          [<00000000128486db>] nfs4_init_client+0xce/0x270
          [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0
          [<000000000e593b52>] nfs4_create_server+0x300/0x5f0
          [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110
          [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0
          [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0
          [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0
          [<000000005d56bdec>] do_syscall_64+0x35/0x80
          [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
    
    Fixes: abf79bb341bf ("NFS: Add a slot table to struct nfs_client for NFSv4.0 transport blocking")
    Signed-off-by: Zhang Xiaoxu <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
NFSv4.1: Handle RECLAIM_COMPLETE trunking errors [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Sun Oct 16 14:44:32 2022 -0400

    NFSv4.1: Handle RECLAIM_COMPLETE trunking errors
    
    [ Upstream commit 5d917cba3201e5c25059df96c29252fd99c4f6a7 ]
    
    If RECLAIM_COMPLETE sets the NFS4CLNT_BIND_CONN_TO_SESSION flag, then we
    need to loop back in order to handle it.
    
    Fixes: 0048fdd06614 ("NFSv4.1: RECLAIM_COMPLETE must handle NFS4ERR_CONN_NOT_BOUND_TO_SESSION")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
NFSv4.1: We must always send RECLAIM_COMPLETE after a reboot [+ + +]
Author: Trond Myklebust <[email protected]>
Date:   Sun Oct 16 14:44:33 2022 -0400

    NFSv4.1: We must always send RECLAIM_COMPLETE after a reboot
    
    [ Upstream commit e59679f2b7e522ecad99974e5636291ffd47c184 ]
    
    Currently, we are only guaranteed to send RECLAIM_COMPLETE if we have
    open state to recover. Fix the client to always send RECLAIM_COMPLETE
    after setting up the lease.
    
    Fixes: fce5c838e133 ("nfs41: RECLAIM_COMPLETE functionality")
    Signed-off-by: Trond Myklebust <[email protected]>
    Signed-off-by: Anna Schumaker <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
parisc: Export iosapic_serial_irq() symbol for serial port driver [+ + +]
Author: Helge Deller <[email protected]>
Date:   Thu Oct 27 09:12:05 2022 +0200

    parisc: Export iosapic_serial_irq() symbol for serial port driver
    
    commit a0c9f1f2e53b8eb2ae43987a30e547ba56b4fa18 upstream.
    
    The parisc serial port driver needs this symbol when it's compiled
    as module.
    
    Signed-off-by: Helge Deller <[email protected]>
    Reported-by: kernel test robot <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

parisc: Make 8250_gsc driver dependend on CONFIG_PARISC [+ + +]
Author: Helge Deller <[email protected]>
Date:   Fri Oct 21 07:44:49 2022 +0200

    parisc: Make 8250_gsc driver dependend on CONFIG_PARISC
    
    commit e8a18e3f00f3ee8d07c17ab1ea3ad4df4a3b6fe0 upstream.
    
    Although the name of the driver 8250_gsc.c suggests that it handles
    only serial ports on the GSC bus, it does handle serial ports listed
    in the parisc machine inventory as well, e.g. the serial ports in a
    C8000 PCI-only workstation.
    
    Change the dependency to CONFIG_PARISC, so that the driver gets included
    in the kernel even if CONFIG_GSC isn't set.
    
    Reported-by: Mikulas Patocka <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Helge Deller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
rose: Fix NULL pointer dereference in rose_send_frame() [+ + +]
Author: Zhang Qilong <[email protected]>
Date:   Sat Oct 29 00:10:49 2022 +0800

    rose: Fix NULL pointer dereference in rose_send_frame()
    
    [ Upstream commit e97c089d7a49f67027395ddf70bf327eeac2611e ]
    
    The syzkaller reported an issue:
    
    KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
    CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
    Workqueue: rcu_gp srcu_invoke_callbacks
    RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101
    Call Trace:
     <IRQ>
     rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255
     rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009
     rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111
     call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474
     expire_timers kernel/time/timer.c:1519 [inline]
     __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
     __run_timers kernel/time/timer.c:1768 [inline]
     run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
     __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571
     [...]
     </IRQ>
    
    It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is
    called in the rose_send_frame(). It's the first occurrence of the
    `neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and
    the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr.
    
    It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf
    ("rose: Fix Null pointer dereference in rose_send_frame()") ever.
    But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8
    ("rose: check NULL rose_loopback_neigh->loopback") again.
    
    We fix it by add NULL check in rose_transmit_clear_request(). When
    the 'dev' in 'neigh' is NULL, we don't reply the request and just
    clear it.
    
    syzkaller don't provide repro, and I provide a syz repro like:
    r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)
    ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201})
    r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0)
    bind$rose(r1, &(0x7f00000000c0)[email protected]={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40)
    connect$rose(r1, &(0x7f0000000240)[email protected]={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)
    
    Fixes: 3c53cd65dece ("rose: check NULL rose_loopback_neigh->loopback")
    Signed-off-by: Zhang Qilong <z[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tcp/udp: Make early_demux back namespacified. [+ + +]
Author: Kuniyuki Iwashima <[email protected]>
Date:   Wed Jul 13 10:52:07 2022 -0700

    tcp/udp: Make early_demux back namespacified.
    
    commit 11052589cf5c0bab3b4884d423d5f60c38fcf25d upstream.
    
    Commit e21145a9871a ("ipv4: namespacify ip_early_demux sysctl knob") made
    it possible to enable/disable early_demux on a per-netns basis.  Then, we
    introduced two knobs, tcp_early_demux and udp_early_demux, to switch it for
    TCP/UDP in commit dddb64bcb346 ("net: Add sysctl to toggle early demux for
    tcp and udp").  However, the .proc_handler() was wrong and actually
    disabled us from changing the behaviour in each netns.
    
    We can execute early_demux if net.ipv4.ip_early_demux is on and each proto
    .early_demux() handler is not NULL.  When we toggle (tcp|udp)_early_demux,
    the change itself is saved in each netns variable, but the .early_demux()
    handler is a global variable, so the handler is switched based on the
    init_net's sysctl variable.  Thus, netns (tcp|udp)_early_demux knobs have
    nothing to do with the logic.  Whether we CAN execute proto .early_demux()
    is always decided by init_net's sysctl knob, and whether we DO it or not is
    by each netns ip_early_demux knob.
    
    This patch namespacifies (tcp|udp)_early_demux again.  For now, the users
    of the .early_demux() handler are TCP and UDP only, and they are called
    directly to avoid retpoline.  So, we can remove the .early_demux() handler
    from inet6?_protos and need not dereference them in ip6?_rcv_finish_core().
    If another proto needs .early_demux(), we can restore it at that time.
    
    Fixes: dddb64bcb346 ("net: Add sysctl to toggle early demux for tcp and udp")
    Signed-off-by: Kuniyuki Iwashima <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
wifi: brcmfmac: Fix potential buffer overflow in brcmf_fweh_event_worker() [+ + +]
Author: Dokyung Song <[email protected]>
Date:   Fri Oct 21 15:13:59 2022 +0900

    wifi: brcmfmac: Fix potential buffer overflow in brcmf_fweh_event_worker()
    
    commit 6788ba8aed4e28e90f72d68a9d794e34eac17295 upstream.
    
    This patch fixes an intra-object buffer overflow in brcmfmac that occurs
    when the device provides a 'bsscfgidx' equal to or greater than the
    buffer size. The patch adds a check that leads to a safe failure if that
    is the case.
    
    This fixes CVE-2022-3628.
    
    UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
    index 52 is out of range for type 'brcmf_if *[16]'
    CPU: 0 PID: 1898 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: events brcmf_fweh_event_worker
    Call Trace:
     dump_stack_lvl+0x57/0x7d
     ubsan_epilogue+0x5/0x40
     __ubsan_handle_out_of_bounds+0x69/0x80
     ? memcpy+0x39/0x60
     brcmf_fweh_event_worker+0xae1/0xc00
     ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
     ? 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
    ================================================================================
    general protection fault, probably for non-canonical address 0xe5601c0020023fff: 0000 [#1] SMP KASAN
    KASAN: maybe wild-memory-access in range [0x2b0100010011fff8-0x2b0100010011ffff]
    CPU: 0 PID: 1898 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: events brcmf_fweh_event_worker
    RIP: 0010:brcmf_fweh_call_event_handler.isra.0+0x42/0x100
    Code: 89 f5 53 48 89 fb 48 83 ec 08 e8 79 0b 38 fe 48 85 ed 74 7e e8 6f 0b 38 fe 48 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 8b 00 00 00 4c 8b 7d 00 44 89 e0 48 ba 00 00 00
    RSP: 0018:ffffc9000259fbd8 EFLAGS: 00010207
    RAX: dffffc0000000000 RBX: ffff888115d8cd50 RCX: 0000000000000000
    RDX: 0560200020023fff RSI: ffffffff8304bc91 RDI: ffff888115d8cd50
    RBP: 2b0100010011ffff R08: ffff888112340050 R09: ffffed1023549809
    R10: ffff88811aa4c047 R11: ffffed1023549808 R12: 0000000000000045
    R13: ffffc9000259fca0 R14: ffff888112340050 R15: ffff888112340000
    FS:  0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000004053ccc0 CR3: 0000000112740000 CR4: 0000000000750ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     brcmf_fweh_event_worker+0x117/0xc00
     ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
     ? 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
    Modules linked in: 88XXau(O) 88x2bu(O)
    ---[ end trace 41d302138f3ff55a ]---
    RIP: 0010:brcmf_fweh_call_event_handler.isra.0+0x42/0x100
    Code: 89 f5 53 48 89 fb 48 83 ec 08 e8 79 0b 38 fe 48 85 ed 74 7e e8 6f 0b 38 fe 48 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 8b 00 00 00 4c 8b 7d 00 44 89 e0 48 ba 00 00 00
    RSP: 0018:ffffc9000259fbd8 EFLAGS: 00010207
    RAX: dffffc0000000000 RBX: ffff888115d8cd50 RCX: 0000000000000000
    RDX: 0560200020023fff RSI: ffffffff8304bc91 RDI: ffff888115d8cd50
    RBP: 2b0100010011ffff R08: ffff888112340050 R09: ffffed1023549809
    R10: ffff88811aa4c047 R11: ffffed1023549808 R12: 0000000000000045
    R13: ffffc9000259fca0 R14: ffff888112340050 R15: ffff888112340000
    FS:  0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000004053ccc0 CR3: 0000000112740000 CR4: 0000000000750ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Kernel panic - not syncing: Fatal exception
    
    Reported-by: Dokyung Song <[email protected]>
    Reported-by: Jisoo Jang <[email protected]>
    Reported-by: Minsuk Kang <[email protected]>
    Reviewed-by: Arend van Spriel <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Dokyung Song <[email protected]>
    Signed-off-by: Kalle Valo <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>