~canonical-kernel/ubuntu/+source/linux-oem/+git/jammy:oem-5.17-next

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

97f054a... by Lin Ma <email address hidden> on 2023-08-09

net: nfc: Fix use-after-free caused by nfc_llcp_find_local

This commit fixes several use-after-free that caused by function
nfc_llcp_find_local(). For example, one UAF can happen when below buggy
time window occurs.

// nfc_genl_llc_get_params | // nfc_unregister_device
                             |
dev = nfc_get_device(idx); | device_lock(...)
if (!dev) | dev->shutting_down = true;
    return -ENODEV; | device_unlock(...);
                             |
device_lock(...); | // nfc_llcp_unregister_device
                             | nfc_llcp_find_local()
nfc_llcp_find_local(...); |
                             | local_cleanup()
if (!local) { |
    rc = -ENODEV; | // nfc_llcp_local_put
    goto exit; | kref_put(.., local_release)
} |
                             | // local_release
                             | list_del(&local->list)
  // nfc_genl_send_params | kfree()
  local->dev->idx !!!UAF!!! |
                             |

and the crash trace for the one of the discussed UAF like:

BUG: KASAN: slab-use-after-free in nfc_genl_llc_get_params+0x72f/0x780 net/nfc/netlink.c:1045
Read of size 8 at addr ffff888105b0e410 by task 20114

Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:319 [inline]
 print_report+0xcc/0x620 mm/kasan/report.c:430
 kasan_report+0xb2/0xe0 mm/kasan/report.c:536
 nfc_genl_send_params net/nfc/netlink.c:999 [inline]
 nfc_genl_llc_get_params+0x72f/0x780 net/nfc/netlink.c:1045
 genl_family_rcv_msg_doit.isra.0+0x1ee/0x2e0 net/netlink/genetlink.c:968
 genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]
 genl_rcv_msg+0x503/0x7d0 net/netlink/genetlink.c:1065
 netlink_rcv_skb+0x161/0x430 net/netlink/af_netlink.c:2548
 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
 netlink_unicast+0x644/0x900 net/netlink/af_netlink.c:1365
 netlink_sendmsg+0x934/0xe70 net/netlink/af_netlink.c:1913
 sock_sendmsg_nosec net/socket.c:724 [inline]
 sock_sendmsg+0x1b6/0x200 net/socket.c:747
 ____sys_sendmsg+0x6e9/0x890 net/socket.c:2501
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
 __sys_sendmsg+0xf7/0x1d0 net/socket.c:2584
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f34640a2389
RSP: 002b:00007f3463415168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f34641c1f80 RCX: 00007f34640a2389
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000006
RBP: 00007f34640ed493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffe38449ecf R14: 00007f3463415300 R15: 0000000000022000
 </TASK>

Allocated by task 20116:
 kasan_save_stack+0x22/0x50 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 ____kasan_kmalloc mm/kasan/common.c:374 [inline]
 __kasan_kmalloc+0x7f/0x90 mm/kasan/common.c:383
 kmalloc include/linux/slab.h:580 [inline]
 kzalloc include/linux/slab.h:720 [inline]
 nfc_llcp_register_device+0x49/0xa40 net/nfc/llcp_core.c:1567
 nfc_register_device+0x61/0x260 net/nfc/core.c:1124
 nci_register_device+0x776/0xb20 net/nfc/nci/core.c:1257
 virtual_ncidev_open+0x147/0x230 drivers/nfc/virtual_ncidev.c:148
 misc_open+0x379/0x4a0 drivers/char/misc.c:165
 chrdev_open+0x26c/0x780 fs/char_dev.c:414
 do_dentry_open+0x6c4/0x12a0 fs/open.c:920
 do_open fs/namei.c:3560 [inline]
 path_openat+0x24fe/0x37e0 fs/namei.c:3715
 do_filp_open+0x1ba/0x410 fs/namei.c:3742
 do_sys_openat2+0x171/0x4c0 fs/open.c:1356
 do_sys_open fs/open.c:1372 [inline]
 __do_sys_openat fs/open.c:1388 [inline]
 __se_sys_openat fs/open.c:1383 [inline]
 __x64_sys_openat+0x143/0x200 fs/open.c:1383
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Freed by task 20115:
 kasan_save_stack+0x22/0x50 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 kasan_save_free_info+0x2e/0x50 mm/kasan/generic.c:521
 ____kasan_slab_free mm/kasan/common.c:236 [inline]
 ____kasan_slab_free mm/kasan/common.c:200 [inline]
 __kasan_slab_free+0x10a/0x190 mm/kasan/common.c:244
 kasan_slab_free include/linux/kasan.h:162 [inline]
 slab_free_hook mm/slub.c:1781 [inline]
 slab_free_freelist_hook mm/slub.c:1807 [inline]
 slab_free mm/slub.c:3787 [inline]
 __kmem_cache_free+0x7a/0x190 mm/slub.c:3800
 local_release net/nfc/llcp_core.c:174 [inline]
 kref_put include/linux/kref.h:65 [inline]
 nfc_llcp_local_put net/nfc/llcp_core.c:182 [inline]
 nfc_llcp_local_put net/nfc/llcp_core.c:177 [inline]
 nfc_llcp_unregister_device+0x206/0x290 net/nfc/llcp_core.c:1620
 nfc_unregister_device+0x160/0x1d0 net/nfc/core.c:1179
 virtual_ncidev_close+0x52/0xa0 drivers/nfc/virtual_ncidev.c:163
 __fput+0x252/0xa20 fs/file_table.c:321
 task_work_run+0x174/0x270 kernel/task_work.c:179
 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
 exit_to_user_mode_prepare+0x108/0x110 kernel/entry/common.c:204
 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]
 syscall_exit_to_user_mode+0x21/0x50 kernel/entry/common.c:297
 do_syscall_64+0x4c/0x90 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Last potentially related work creation:
 kasan_save_stack+0x22/0x50 mm/kasan/common.c:45
 __kasan_record_aux_stack+0x95/0xb0 mm/kasan/generic.c:491
 kvfree_call_rcu+0x29/0xa80 kernel/rcu/tree.c:3328
 drop_sysctl_table+0x3be/0x4e0 fs/proc/proc_sysctl.c:1735
 unregister_sysctl_table.part.0+0x9c/0x190 fs/proc/proc_sysctl.c:1773
 unregister_sysctl_table+0x24/0x30 fs/proc/proc_sysctl.c:1753
 neigh_sysctl_unregister+0x5f/0x80 net/core/neighbour.c:3895
 addrconf_notify+0x140/0x17b0 net/ipv6/addrconf.c:3684
 notifier_call_chain+0xbe/0x210 kernel/notifier.c:87
 call_netdevice_notifiers_info+0xb5/0x150 net/core/dev.c:1937
 call_netdevice_notifiers_extack net/core/dev.c:1975 [inline]
 call_netdevice_notifiers net/core/dev.c:1989 [inline]
 dev_change_name+0x3c3/0x870 net/core/dev.c:1211
 dev_ifsioc+0x800/0xf70 net/core/dev_ioctl.c:376
 dev_ioctl+0x3d9/0xf80 net/core/dev_ioctl.c:542
 sock_do_ioctl+0x160/0x260 net/socket.c:1213
 sock_ioctl+0x3f9/0x670 net/socket.c:1316
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x19e/0x210 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

The buggy address belongs to the object at ffff888105b0e400
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 16 bytes inside of
 freed 1024-byte region [ffff888105b0e400, ffff888105b0e800)

The buggy address belongs to the physical page:
head:ffffea000416c200 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x200000000010200(slab|head|node=0|zone=2)
raw: 0200000000010200 ffff8881000430c0 ffffea00044c7010 ffffea0004510e10
raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff888105b0e300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888105b0e380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888105b0e400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                         ^
 ffff888105b0e480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888105b0e500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

In summary, this patch solves those use-after-free by

1. Re-implement the nfc_llcp_find_local(). The current version does not
grab the reference when getting the local from the linked list. For
example, the llcp_sock_bind() gets the reference like below:

// llcp_sock_bind()

    local = nfc_llcp_find_local(dev); // A
    ..... \
           | raceable
    ..... /
    llcp_sock->local = nfc_llcp_local_get(local); // B

There is an apparent race window that one can drop the reference
and free the local object fetched in (A) before (B) gets the reference.

2. Some callers of the nfc_llcp_find_local() do not grab the reference
at all. For example, the nfc_genl_llc_{{get/set}_params/sdreq} functions.
We add the nfc_llcp_local_put() for them. Moreover, we add the necessary
error handling function to put the reference.

3. Add the nfc_llcp_remove_local() helper. The local object is removed
from the linked list in local_release() when all reference is gone. This
patch removes it when nfc_llcp_unregister_device() is called.

Therefore, every caller of nfc_llcp_find_local() will get a reference
even when the nfc_llcp_unregister_device() is called. This promises no
use-after-free for the local object is ever possible.

Fixes: 52feb444a903 ("NFC: Extend netlink interface for LTO, RW, and MIUX parameters support")
Fixes: c7aa12252f51 ("NFC: Take a reference on the LLCP local pointer when creating a socket")
Signed-off-by: Lin Ma <email address hidden>
Reviewed-by: Simon Horman <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 6709d4b7bc2e079241fdef15d1160581c5261c10)
CVE-2023-3863
Signed-off-by: Yuxuan Luo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

ef7f14f... by Krzysztof Kozlowski on 2023-08-09

nfc: llcp: simplify llcp_sock_connect() error paths

The llcp_sock_connect() error paths were using a mixed way of central
exit (goto) and cleanup

Signed-off-by: Krzysztof Kozlowski <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit ec10fd154d934cc4195da3cbd017a12817b41d51)
CVE-2023-3863
Signed-off-by: Yuxuan Luo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

64a282c... by Zheng Wang <zyytlz.wz@163.com> on 2023-08-08

memstick: r592: Fix UAF bug in r592_remove due to race condition

In r592_probe, dev->detect_timer was bound with r592_detect_timer.
In r592_irq function, the timer function will be invoked by mod_timer.

If we remove the module which will call hantro_release to make cleanup,
there may be a unfinished work. The possible sequence is as follows,
which will cause a typical UAF bug.

Fix it by canceling the work before cleanup in r592_remove.

CPU0 CPU1

                    |r592_detect_timer
r592_remove |
  memstick_free_host|
  put_device; |
  kfree(host); |
                    |
                    | queue_work
                    | &host->media_checker //use

Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
Link: https://lore.kernel.org/r/20230307164338.1246287-1-zyytlz.wz@163.com
Signed-off-by: Ulf Hansson <email address hidden>
(cherry picked from commit 63264422785021704c39b38f65a78ab9e4a186d7)
CVE-2023-3141
Signed-off-by: Yuxuan Luo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

7e7b9eb... by Jiasheng Jiang <email address hidden> on 2023-08-08

drm/msm/dpu: Add check for pstates

As kzalloc may fail and return NULL pointer,
it should be better to check pstates
in order to avoid the NULL pointer dereference.

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Jiasheng Jiang <email address hidden>
Reviewed-by: Abhinav Kumar <email address hidden>
Patchwork: https://patchwork.freedesktop.org/patch/514160/
Link: https://<email address hidden>
Signed-off-by: Dmitry Baryshkov <email address hidden>
(cherry picked from commit 93340e10b9c5fc86730d149636e0aa8b47bb5a34)
CVE-2023-3220
Signed-off-by: Yuxuan Luo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

d7b0e49... by Baokun Li <email address hidden> on 2023-08-07

ext4: fix use-after-free in ext4_xattr_set_entry

Hulk Robot reported a issue:
==================================================================
BUG: KASAN: use-after-free in ext4_xattr_set_entry+0x18ab/0x3500
Write of size 4105 at addr ffff8881675ef5f4 by task syz-executor.0/7092

CPU: 1 PID: 7092 Comm: syz-executor.0 Not tainted 4.19.90-dirty #17
Call Trace:
[...]
 memcpy+0x34/0x50 mm/kasan/kasan.c:303
 ext4_xattr_set_entry+0x18ab/0x3500 fs/ext4/xattr.c:1747
 ext4_xattr_ibody_inline_set+0x86/0x2a0 fs/ext4/xattr.c:2205
 ext4_xattr_set_handle+0x940/0x1300 fs/ext4/xattr.c:2386
 ext4_xattr_set+0x1da/0x300 fs/ext4/xattr.c:2498
 __vfs_setxattr+0x112/0x170 fs/xattr.c:149
 __vfs_setxattr_noperm+0x11b/0x2a0 fs/xattr.c:180
 __vfs_setxattr_locked+0x17b/0x250 fs/xattr.c:238
 vfs_setxattr+0xed/0x270 fs/xattr.c:255
 setxattr+0x235/0x330 fs/xattr.c:520
 path_setxattr+0x176/0x190 fs/xattr.c:539
 __do_sys_lsetxattr fs/xattr.c:561 [inline]
 __se_sys_lsetxattr fs/xattr.c:557 [inline]
 __x64_sys_lsetxattr+0xc2/0x160 fs/xattr.c:557
 do_syscall_64+0xdf/0x530 arch/x86/entry/common.c:298
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x459fe9
RSP: 002b:00007fa5e54b4c08 EFLAGS: 00000246 ORIG_RAX: 00000000000000bd
RAX: ffffffffffffffda RBX: 000000000051bf60 RCX: 0000000000459fe9
RDX: 00000000200003c0 RSI: 0000000020000180 RDI: 0000000020000140
RBP: 000000000051bf60 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000001009 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffc73c93fc0 R14: 000000000051bf60 R15: 00007fa5e54b4d80
[...]
==================================================================

Above issue may happen as follows:
-------------------------------------
ext4_xattr_set
  ext4_xattr_set_handle
    ext4_xattr_ibody_find
      >> s->end < s->base
      >> no EXT4_STATE_XATTR
      >> xattr_check_inode is not executed
    ext4_xattr_ibody_set
      ext4_xattr_set_entry
       >> size_t min_offs = s->end - s->base
       >> UAF in memcpy

we can easily reproduce this problem with the following commands:
    mkfs.ext4 -F /dev/sda
    mount -o debug_want_extra_isize=128 /dev/sda /mnt
    touch /mnt/file
    setfattr -n user.cat -v `seq -s z 4096|tr -d '[:digit:]'` /mnt/file

In ext4_xattr_ibody_find, we have the following assignment logic:
  header = IHDR(inode, raw_inode)
         = raw_inode + EXT4_GOOD_OLD_INODE_SIZE + i_extra_isize
  is->s.base = IFIRST(header)
             = header + sizeof(struct ext4_xattr_ibody_header)
  is->s.end = raw_inode + s_inode_size

In ext4_xattr_set_entry
  min_offs = s->end - s->base
           = s_inode_size - EXT4_GOOD_OLD_INODE_SIZE - i_extra_isize -
      sizeof(struct ext4_xattr_ibody_header)
  last = s->first
  free = min_offs - ((void *)last - s->base) - sizeof(__u32)
       = s_inode_size - EXT4_GOOD_OLD_INODE_SIZE - i_extra_isize -
         sizeof(struct ext4_xattr_ibody_header) - sizeof(__u32)

In the calculation formula, all values except s_inode_size and
i_extra_size are fixed values. When i_extra_size is the maximum value
s_inode_size - EXT4_GOOD_OLD_INODE_SIZE, min_offs is -4 and free is -8.
The value overflows. As a result, the preceding issue is triggered when
memcpy is executed.

Therefore, when finding xattr or setting xattr, check whether
there is space for storing xattr in the inode to resolve this issue.

Cc: <email address hidden>
Reported-by: Hulk Robot <email address hidden>
Signed-off-by: Baokun Li <email address hidden>
Reviewed-by: Ritesh Harjani (IBM) <email address hidden>
Reviewed-by: Jan Kara <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Theodore Ts'o <email address hidden>
(cherry picked from commit 67d7d8ad99beccd9fe92d585b87f1760dc9018e3)
CVE-2023-2513
Signed-off-by: Yuxuan Luo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

1438d8c... by Baokun Li <email address hidden> on 2023-08-07

ext4: add EXT4_INODE_HAS_XATTR_SPACE macro in xattr.h

When adding an xattr to an inode, we must ensure that the inode_size is
not less than EXT4_GOOD_OLD_INODE_SIZE + extra_isize + pad. Otherwise,
the end position may be greater than the start position, resulting in UAF.

Signed-off-by: Baokun Li <email address hidden>
Reviewed-by: Jan Kara <email address hidden>
Reviewed-by: Ritesh Harjani (IBM) <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Theodore Ts'o <email address hidden>
(cherry picked from commit 179b14152dcb6a24c3415200603aebca70ff13af)
CVE-2023-2513
Signed-off-by: Yuxuan Luo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

c95de2c... by Davide Caratti <email address hidden> on 2023-08-04

act_mirred: use the backlog for nested calls to mirred ingress

William reports kernel soft-lockups on some OVS topologies when TC mirred
egress->ingress action is hit by local TCP traffic [1].
The same can also be reproduced with SCTP (thanks Xin for verifying), when
client and server reach themselves through mirred egress to ingress, and
one of the two peers sends a "heartbeat" packet (from within a timer).

Enqueueing to backlog proved to fix this soft lockup; however, as Cong
noticed [2], we should preserve - when possible - the current mirred
behavior that counts as "overlimits" any eventual packet drop subsequent to
the mirred forwarding action [3]. A compromise solution might use the
backlog only when tcf_mirred_act() has a nest level greater than one:
change tcf_mirred_forward() accordingly.

Also, add a kselftest that can reproduce the lockup and verifies TC mirred
ability to account for further packet drops after TC mirred egress->ingress
(when the nest level is 1).

 [1] https://lore.kernel.org/netdev/<email address hidden>/
 [2] https://lore.kernel.org/netdev/Y0w%<email address hidden>/
 [3] such behavior is not guaranteed: for example, if RPS or skb RX
     timestamping is enabled on the mirred target device, the kernel
     can defer receiving the skb and return NET_RX_SUCCESS inside
     tcf_mirred_forward().

Reported-by: William Zhao <email address hidden>
CC: Xin Long <email address hidden>
Signed-off-by: Davide Caratti <email address hidden>
Reviewed-by: Marcelo Ricardo Leitner <email address hidden>
Acked-by: Jamal Hadi Salim <email address hidden>
Signed-off-by: Paolo Abeni <email address hidden>
(cherry picked from commit ca22da2fbd693b54dc8e3b7b54ccc9f7e9ba3640)
CVE-2022-4269
Signed-off-by: Yuxuan Luo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

825b0cf... by Davide Caratti <email address hidden> on 2023-08-04

net/sched: act_mirred: better wording on protection against excessive stack growth

with commit e2ca070f89ec ("net: sched: protect against stack overflow in
TC act_mirred"), act_mirred protected itself against excessive stack growth
using per_cpu counter of nested calls to tcf_mirred_act(), and capping it
to MIRRED_RECURSION_LIMIT. However, such protection does not detect
recursion/loops in case the packet is enqueued to the backlog (for example,
when the mirred target device has RPS or skb timestamping enabled). Change
the wording from "recursion" to "nesting" to make it more clear to readers.

CC: Jamal Hadi Salim <email address hidden>
Signed-off-by: Davide Caratti <email address hidden>
Reviewed-by: Marcelo Ricardo Leitner <email address hidden>
Acked-by: Jamal Hadi Salim <email address hidden>
Signed-off-by: Paolo Abeni <email address hidden>
(cherry picked from commit 78dcdffe0418ac8f3f057f26fe71ccf4d8ed851f)
CVE-2022-4269
Signed-off-by: Yuxuan Luo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

7a54218... by Hangyu Hua on 2023-08-04

net: tls: fix possible race condition between do_tls_getsockopt_conf() and do_tls_setsockopt_conf()

ctx->crypto_send.info is not protected by lock_sock in
do_tls_getsockopt_conf(). A race condition between do_tls_getsockopt_conf()
and error paths of do_tls_setsockopt_conf() may lead to a use-after-free
or null-deref.

More discussion: https://lore.kernel.org/all/Y/ht6gQL+u6fj3dG@hog/

Fixes: 3c4d7559159b ("tls: kernel TLS support")
Signed-off-by: Hangyu Hua <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Jakub Kicinski <email address hidden>
(backported from commit 49c47cc21b5b7a3d8deb18fc57b0aa2ab1286962)
[cascardo: removed hunks not present]
CVE-2023-28466
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>

5958375... by Ziyang Xuan <email address hidden> on 2023-08-04

net: tun: fix bugs for oversize packet when napi frags enabled

Recently, we got two syzkaller problems because of oversize packet
when napi frags enabled.

One of the problems is because the first seg size of the iov_iter
from user space is very big, it is 2147479538 which is bigger than
the threshold value for bail out early in __alloc_pages(). And
skb->pfmemalloc is true, __kmalloc_reserve() would use pfmemalloc
reserves without __GFP_NOWARN flag. Thus we got a warning as following:

========================================================
WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
...
Call trace:
 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
 __alloc_pages_node include/linux/gfp.h:550 [inline]
 alloc_pages_node include/linux/gfp.h:564 [inline]
 kmalloc_large_node+0x94/0x350 mm/slub.c:4038
 __kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545
 __kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151
 pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654
 __skb_grow include/linux/skbuff.h:2779 [inline]
 tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477
 tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835
 tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036

The other problem is because odd IPv6 packets without NEXTHDR_NONE
extension header and have big packet length, it is 2127925 which is
bigger than ETH_MAX_MTU(65535). After ipv6_gso_pull_exthdrs() in
ipv6_gro_receive(), network_header offset and transport_header offset
are all bigger than U16_MAX. That would trigger skb->network_header
and skb->transport_header overflow error, because they are all '__u16'
type. Eventually, it would affect the value for __skb_push(skb, value),
and make it be a big value. After __skb_push() in ipv6_gro_receive(),
skb->data would less than skb->head, an out of bounds memory bug occurred.
That would trigger the problem as following:

==================================================================
BUG: KASAN: use-after-free in eth_type_trans+0x100/0x260
...
Call trace:
 dump_backtrace+0xd8/0x130
 show_stack+0x1c/0x50
 dump_stack_lvl+0x64/0x7c
 print_address_description.constprop.0+0xbc/0x2e8
 print_report+0x100/0x1e4
 kasan_report+0x80/0x120
 __asan_load8+0x78/0xa0
 eth_type_trans+0x100/0x260
 napi_gro_frags+0x164/0x550
 tun_get_user+0xda4/0x1270
 tun_chr_write_iter+0x74/0x130
 do_iter_readv_writev+0x130/0x1ec
 do_iter_write+0xbc/0x1e0
 vfs_writev+0x13c/0x26c

To fix the problems, restrict the packet size less than
(ETH_MAX_MTU - NET_SKB_PAD - NET_IP_ALIGN) which has considered reserved
skb space in napi_alloc_skb() because transport_header is an offset from
skb->head. Add len check in tun_napi_alloc_frags() simply.

Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
Signed-off-by: Ziyang Xuan <email address hidden>
Reviewed-by: Eric Dumazet <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Jakub Kicinski <email address hidden>
(cherry picked from commit 363a5328f4b0517e59572118ccfb7c626d81dca9)
CVE-2023-3812
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Timo Aaltonen <email address hidden>