Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: Fix use-after-free Read in usb_udc_uevent()<br /> <br /> The syzbot fuzzer found a race between uevent callbacks and gadget<br /> driver unregistration that can cause a use-after-free bug:<br /> <br /> ---------------------------------------------------------------<br /> BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130<br /> drivers/usb/gadget/udc/core.c:1732<br /> Read of size 8 at addr ffff888078ce2050 by task udevd/2968<br /> <br /> CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google<br /> 06/29/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:317 [inline]<br /> print_report.cold+0x2ba/0x719 mm/kasan/report.c:433<br /> kasan_report+0xbe/0x1f0 mm/kasan/report.c:495<br /> usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732<br /> dev_uevent+0x290/0x770 drivers/base/core.c:2424<br /> ---------------------------------------------------------------<br /> <br /> The bug occurs because usb_udc_uevent() dereferences udc-&gt;driver but<br /> does so without acquiring the udc_lock mutex, which protects this<br /> field. If the gadget driver is unbound from the udc concurrently with<br /> uevent processing, the driver structure may be accessed after it has<br /> been deallocated.<br /> <br /> To prevent the race, we make sure that the routine holds the mutex<br /> around the racing accesses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: fb_pm2fb: Avoid potential divide by zero error<br /> <br /> In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be<br /> copied from user, then go through `fb_set_var()` and<br /> `info-&gt;fbops-&gt;fb_check_var()` which could may be `pm2fb_check_var()`.<br /> Along the path, `var-&gt;pixclock` won&amp;#39;t be modified. This function checks<br /> whether reciprocal of `var-&gt;pixclock` is too high. If `var-&gt;pixclock` is<br /> zero, there will be a divide by zero error. So, it is necessary to check<br /> whether denominator is zero to avoid crash. As this bug is found by<br /> Syzkaller, logs are listed below.<br /> <br /> divide error in pm2fb_check_var<br /> Call Trace:<br /> <br /> fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015<br /> do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110<br /> fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead<br /> <br /> ftrace_startup does not remove ops from ftrace_ops_list when<br /> ftrace_startup_enable fails:<br /> <br /> register_ftrace_function<br /> ftrace_startup<br /> __register_ftrace_function<br /> ...<br /> add_ftrace_ops(&amp;ftrace_ops_list, ops)<br /> ...<br /> ...<br /> ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1<br /> ...<br /> return 0 // ops is in the ftrace_ops_list.<br /> <br /> When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:<br /> unregister_ftrace_function<br /> ftrace_shutdown<br /> if (unlikely(ftrace_disabled))<br /> return -ENODEV; // return here, __unregister_ftrace_function is not executed,<br /> // as a result, ops is still in the ftrace_ops_list<br /> __unregister_ftrace_function<br /> ...<br /> <br /> If ops is dynamically allocated, it will be free later, in this case,<br /> is_ftrace_trampoline accesses NULL pointer:<br /> <br /> is_ftrace_trampoline<br /> ftrace_ops_trampoline<br /> do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!<br /> <br /> Syzkaller reports as follows:<br /> [ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b<br /> [ 1203.508039] #PF: supervisor read access in kernel mode<br /> [ 1203.508798] #PF: error_code(0x0000) - not-present page<br /> [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0<br /> [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI<br /> [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8<br /> [ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0<br /> [ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00<br /> [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246<br /> [ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866<br /> [ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b<br /> [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07<br /> [ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399<br /> [ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008<br /> [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000<br /> [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0<br /> [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> <br /> Therefore, when ftrace_startup_enable fails, we need to rollback registration<br /> process and remove ops from ftrace_ops_list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix refcount bug in sk_psock_get (2)<br /> <br /> Syzkaller reports refcount bug as follows:<br /> ------------[ cut here ]------------<br /> refcount_t: saturated; leaking memory.<br /> WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19<br /> Modules linked in:<br /> CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0<br /> <br /> __refcount_add_not_zero include/linux/refcount.h:163 [inline]<br /> __refcount_inc_not_zero include/linux/refcount.h:227 [inline]<br /> refcount_inc_not_zero include/linux/refcount.h:245 [inline]<br /> sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439<br /> tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091<br /> tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983<br /> tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057<br /> tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659<br /> tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682<br /> sk_backlog_rcv include/net/sock.h:1061 [inline]<br /> __release_sock+0x134/0x3b0 net/core/sock.c:2849<br /> release_sock+0x54/0x1b0 net/core/sock.c:3404<br /> inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909<br /> __sys_shutdown_sock net/socket.c:2331 [inline]<br /> __sys_shutdown_sock net/socket.c:2325 [inline]<br /> __sys_shutdown+0xf1/0x1b0 net/socket.c:2343<br /> __do_sys_shutdown net/socket.c:2351 [inline]<br /> __se_sys_shutdown net/socket.c:2349 [inline]<br /> __x64_sys_shutdown+0x50/0x70 net/socket.c:2349<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> <br /> During SMC fallback process in connect syscall, kernel will<br /> replaces TCP with SMC. In order to forward wakeup<br /> smc socket waitqueue after fallback, kernel will sets<br /> clcsk-&gt;sk_user_data to origin smc socket in<br /> smc_fback_replace_callbacks().<br /> <br /> Later, in shutdown syscall, kernel will calls<br /> sk_psock_get(), which treats the clcsk-&gt;sk_user_data<br /> as psock type, triggering the refcnt warning.<br /> <br /> So, the root cause is that smc and psock, both will use<br /> sk_user_data field. So they will mismatch this field<br /> easily.<br /> <br /> This patch solves it by using another bit(defined as<br /> SK_USER_DATA_PSOCK) in PTRMASK, to mark whether<br /> sk_user_data points to a psock object or not.<br /> This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e<br /> ("net, sk_msg: Clear sk_user_data pointer on clone if tagged").<br /> <br /> For there will possibly be more flags in the sk_user_data field,<br /> this patch also refactor sk_user_data flags code to be more generic<br /> to improve its maintainability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ieee802154/adf7242: defer destroy_workqueue call<br /> <br /> There is a possible race condition (use-after-free) like below<br /> <br /> (FREE) | (USE)<br /> adf7242_remove | adf7242_channel<br /> cancel_delayed_work_sync |<br /> destroy_workqueue (1) | adf7242_cmd_rx<br /> | mod_delayed_work (2)<br /> |<br /> <br /> The root cause for this race is that the upper layer (ieee802154) is<br /> unaware of this detaching event and the function adf7242_channel can<br /> be called without any checks.<br /> <br /> To fix this, we can add a flag write at the beginning of adf7242_remove<br /> and add flag check in adf7242_channel. Or we can just defer the<br /> destructive operation like other commit 3e0588c291d6 ("hamradio: defer<br /> ax25 kfree after unregister_netdev") which let the<br /> ieee802154_unregister_hw() to handle the synchronization. This patch<br /> takes the second option.<br /> <br /> runs")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: clear optc underflow before turn off odm clock<br /> <br /> [Why]<br /> After ODM clock off, optc underflow bit will be kept there always and clear not work.<br /> We need to clear that before clock off.<br /> <br /> [How]<br /> Clear that if have when clock off.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Fix a potential gpu_metrics_table memory leak<br /> <br /> Memory is allocated for gpu_metrics_table in<br /> smu_v13_0_4_init_smc_tables(), but not freed in<br /> smu_v13_0_4_fini_smc_tables(). This may cause memory leaks, fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Fix corrupted packets for XDP_SHARED_UMEM<br /> <br /> Fix an issue in XDP_SHARED_UMEM mode together with aligned mode where<br /> packets are corrupted for the second and any further sockets bound to<br /> the same umem. In other words, this does not affect the first socket<br /> bound to the umem. The culprit for this bug is that the initialization<br /> of the DMA addresses for the pre-populated xsk buffer pool entries was<br /> not performed for any socket but the first one bound to the umem. Only<br /> the linear array of DMA addresses was populated. Fix this by populating<br /> the DMA addresses in the xsk buffer pool for every socket bound to the<br /> same umem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skmsg: Fix wrong last sg check in sk_msg_recvmsg()<br /> <br /> Fix one kernel NULL pointer dereference as below:<br /> <br /> [ 224.462334] Call Trace:<br /> [ 224.462394] __tcp_bpf_recvmsg+0xd3/0x380<br /> [ 224.462441] ? sock_has_perm+0x78/0xa0<br /> [ 224.462463] tcp_bpf_recvmsg+0x12e/0x220<br /> [ 224.462494] inet_recvmsg+0x5b/0xd0<br /> [ 224.462534] __sys_recvfrom+0xc8/0x130<br /> [ 224.462574] ? syscall_trace_enter+0x1df/0x2e0<br /> [ 224.462606] ? __do_page_fault+0x2de/0x500<br /> [ 224.462635] __x64_sys_recvfrom+0x24/0x30<br /> [ 224.462660] do_syscall_64+0x5d/0x1d0<br /> [ 224.462709] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> In commit 9974d37ea75f ("skmsg: Fix invalid last sg check in<br /> sk_msg_recvmsg()"), we change last sg check to sg_is_last(),<br /> but in sockmap redirection case (without stream_parser/stream_verdict/<br /> skb_verdict), we did not mark the end of the scatterlist. Check the<br /> sk_msg_alloc, sk_msg_page_add, and bpf_msg_push_data functions, they all<br /> do not mark the end of sg. They are expected to use sg.end for end<br /> judgment. So the judgment of &amp;#39;(i != msg_rx-&gt;sg.end)&amp;#39; is added back here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: nintendo: fix rumble worker null pointer deref<br /> <br /> We can dereference a null pointer trying to queue work to a destroyed<br /> workqueue.<br /> <br /> If the device is disconnected, nintendo_hid_remove is called, in which<br /> the rumble_queue is destroyed. Avoid using that queue to defer rumble<br /> work once the controller state is set to JOYCON_CTLR_STATE_REMOVED.<br /> <br /> This eliminates the null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Don&amp;#39;t redirect packets with invalid pkt_len<br /> <br /> Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any<br /> skbs, that is, the flow-&gt;head is null.<br /> The root cause, as the [2] says, is because that bpf_prog_test_run_skb()<br /> run a bpf prog which redirects empty skbs.<br /> So we should determine whether the length of the packet modified by bpf<br /> prog or others like bpf_prog_test is valid before forwarding it directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a data-race around bpf_jit_limit.<br /> <br /> While reading bpf_jit_limit, it can be changed concurrently via sysctl,<br /> WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit<br /> is long, so we need to add a paired READ_ONCE() to avoid load-tearing.