Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: dln2: Fix memory leak in dln2_probe()<br /> <br /> When dln2_setup_rx_urbs() in dln2_probe() fails, error out_free forgets<br /> to call usb_put_dev() to decrease the refcount of dln2-&gt;usb_dev.<br /> <br /> Fix this by adding usb_put_dev() in the error handling code of<br /> dln2_probe().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix FCLK pstate change underflow<br /> <br /> [Why]<br /> Currently we set FCLK p-state change<br /> watermark calculated based on dummy<br /> p-state latency when UCLK p-state is<br /> not supported<br /> <br /> [How]<br /> Calculate FCLK p-state change watermark<br /> based on on FCLK pstate change latency<br /> in case UCLK p-state is not supported

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smc: Fix use-after-free in tcp_write_timer_handler().<br /> <br /> With Eric&amp;#39;s ref tracker, syzbot finally found a repro for<br /> use-after-free in tcp_write_timer_handler() by kernel TCP<br /> sockets. [0]<br /> <br /> If SMC creates a kernel socket in __smc_create(), the kernel<br /> socket is supposed to be freed in smc_clcsock_release() by<br /> calling sock_release() when we close() the parent SMC socket.<br /> <br /> However, at the end of smc_clcsock_release(), the kernel<br /> socket&amp;#39;s sk_state might not be TCP_CLOSE. This means that<br /> we have not called inet_csk_destroy_sock() in __tcp_close()<br /> and have not stopped the TCP timers.<br /> <br /> The kernel socket&amp;#39;s TCP timers can be fired later, so we<br /> need to hold a refcnt for net as we do for MPTCP subflows<br /> in mptcp_subflow_create_socket().<br /> <br /> [0]:<br /> leaked reference.<br /> sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108)<br /> inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244)<br /> __sock_create (net/socket.c:1546)<br /> smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284)<br /> __sock_create (net/socket.c:1546)<br /> __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661)<br /> __x64_sys_socket (net/socket.c:1672)<br /> do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)<br /> Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091<br /> <br /> CPU: 0 PID: 18091 Comm: syzrepro Tainted: G W 6.3.0-rc4-01174-gb5d54eb5899a #7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:107)<br /> print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)<br /> kasan_report (mm/kasan/report.c:538)<br /> tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)<br /> tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643)<br /> call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)<br /> __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022)<br /> run_timer_softirq (kernel/time/timer.c:2037)<br /> __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572)<br /> __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650)<br /> irq_exit_rcu (kernel/softirq.c:664)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dccp: Fix out of bounds access in DCCP error handler<br /> <br /> There was a previous attempt to fix an out-of-bounds access in the DCCP<br /> error handlers, but that fix assumed that the error handlers only want<br /> to access the first 8 bytes of the DCCP header. Actually, they also look<br /> at the DCCP sequence number, which is stored beyond 8 bytes, so an<br /> explicit pskb_may_pull() is required.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-iocost: fix divide by 0 error in calc_lcoefs()<br /> <br /> echo max of u64 to cost.model can cause divide by 0 error.<br /> <br /> # echo 8:0 rbps=18446744073709551615 &gt; /sys/fs/cgroup/io.cost.model<br /> <br /> divide error: 0000 [#1] PREEMPT SMP<br /> RIP: 0010:calc_lcoefs+0x4c/0xc0<br /> Call Trace:<br /> <br /> ioc_refresh_params+0x2b3/0x4f0<br /> ioc_cost_model_write+0x3cb/0x4c0<br /> ? _copy_from_iter+0x6d/0x6c0<br /> ? kernfs_fop_write_iter+0xfc/0x270<br /> cgroup_file_write+0xa0/0x200<br /> kernfs_fop_write_iter+0x17d/0x270<br /> vfs_write+0x414/0x620<br /> ksys_write+0x73/0x160<br /> __x64_sys_write+0x1e/0x30<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> calc_lcoefs() uses the input value of cost.model in DIV_ROUND_UP_ULL,<br /> overflow would happen if bps plus IOC_PAGE_SIZE is greater than<br /> ULLONG_MAX, it can cause divide by 0 error.<br /> <br /> Fix the problem by setting basecost

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: bridge: dw_hdmi: fix connector access for scdc<br /> <br /> Commit 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs") changed the scdc<br /> interface to pick up an i2c adapter from a connector instead. However, in<br /> the case of dw-hdmi, the wrong connector was being used to pass i2c adapter<br /> information, since dw-hdmi&amp;#39;s embedded connector structure is only populated<br /> when the bridge attachment callback explicitly asks for it.<br /> <br /> drm-meson is handling connector creation, so this won&amp;#39;t happen, leading to<br /> a NULL pointer dereference.<br /> <br /> Fix it by having scdc functions access dw-hdmi&amp;#39;s current connector pointer<br /> instead, which is assigned during the bridge enablement stage.<br /> <br /> [narmstrong: moved Fixes tag before first S-o-b and added Reported-by tag]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7921: don&amp;#39;t assume adequate headroom for SDIO headers<br /> <br /> mt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() and<br /> mt7921_skb_add_usb_sdio_hdr(), both of which blindly assume that<br /> adequate headroom will be available in the passed skb. This assumption<br /> typically is satisfied when the skb was allocated in the net core for<br /> transmission via the mt7921 netdev (although even that is only an<br /> optimization and is not strictly guaranteed), but the assumption is<br /> sometimes not satisfied when the skb originated in the receive path of<br /> another netdev and was passed through to the mt7921, such as by the<br /> bridge layer. Blindly prepending bytes to an skb is always wrong.<br /> <br /> This commit introduces a call to skb_cow_head() before the call to<br /> mt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() to<br /> ensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can be<br /> pushed onto the skb.<br /> <br /> Without this fix, I can trivially cause kernel panics by bridging an<br /> MT7921AU-based USB 802.11ax interface with an Ethernet interface on an<br /> Intel Atom-based x86 system using its onboard RTL8169 PCI Ethernet<br /> adapter and also on an ARM-based Raspberry Pi 1 using its onboard<br /> SMSC9512 USB Ethernet adapter. Note that the panics do not occur in<br /> every system configuration, as they occur only if the receiving netdev<br /> leaves less headroom in its received skbs than the mt7921 needs for its<br /> SDIO headers.<br /> <br /> Here is an example stack trace of this panic on Raspberry Pi OS Lite<br /> 2023-02-21 running kernel 6.1.24+ [1]:<br /> <br /> skb_panic from skb_push+0x44/0x48<br /> skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common]<br /> mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb]<br /> mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76]<br /> __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76]<br /> mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76]<br /> mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common]<br /> mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76]<br /> __mt76_worker_fn [mt76] from kthread+0xbc/0xe0<br /> kthread from ret_from_fork+0x14/0x34<br /> <br /> After this fix, bridging the mt7921 interface works fine on both of my<br /> previously problematic systems.<br /> <br /> [1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm flakey: fix a crash with invalid table line<br /> <br /> This command will crash with NULL pointer dereference:<br /> dmsetup create flakey --table \<br /> "0 `blockdev --getsize /dev/ram0` flakey /dev/ram0 0 0 1 2 corrupt_bio_byte 512"<br /> <br /> Fix the crash by checking if arg_name is non-NULL before comparing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uio: uio_dmem_genirq: Fix missing unlock in irq configuration<br /> <br /> Commit b74351287d4b ("uio: fix a sleep-in-atomic-context bug in<br /> uio_dmem_genirq_irqcontrol()") started calling disable_irq() without<br /> holding the spinlock because it can sleep. However, that fix introduced<br /> another bug: if interrupt is already disabled and a new disable request<br /> comes in, then the spinlock is not unlocked:<br /> <br /> root@localhost:~# printf &amp;#39;\x00\x00\x00\x00&amp;#39; &gt; /dev/uio0<br /> root@localhost:~# printf &amp;#39;\x00\x00\x00\x00&amp;#39; &gt; /dev/uio0<br /> root@localhost:~# [ 14.851538] BUG: scheduling while atomic: bash/223/0x00000002<br /> [ 14.851991] Modules linked in: uio_dmem_genirq uio myfpga(OE) bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper drm snd_pcm ppdev joydev psmouse snd_timer snd e1000fb_sys_fops syscopyarea parport sysfillrect soundcore sysimgblt input_leds pcspkr i2c_piix4 serio_raw floppy evbug qemu_fw_cfg mac_hid pata_acpi ip_tables x_tables autofs4 [last unloaded: parport_pc]<br /> [ 14.854206] CPU: 0 PID: 223 Comm: bash Tainted: G OE 6.0.0-rc7 #21<br /> [ 14.854786] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> [ 14.855664] Call Trace:<br /> [ 14.855861] <br /> [ 14.856025] dump_stack_lvl+0x4d/0x67<br /> [ 14.856325] dump_stack+0x14/0x1a<br /> [ 14.856583] __schedule_bug.cold+0x4b/0x5c<br /> [ 14.856915] __schedule+0xe81/0x13d0<br /> [ 14.857199] ? idr_find+0x13/0x20<br /> [ 14.857456] ? get_work_pool+0x2d/0x50<br /> [ 14.857756] ? __flush_work+0x233/0x280<br /> [ 14.858068] ? __schedule+0xa95/0x13d0<br /> [ 14.858307] ? idr_find+0x13/0x20<br /> [ 14.858519] ? get_work_pool+0x2d/0x50<br /> [ 14.858798] schedule+0x6c/0x100<br /> [ 14.859009] schedule_hrtimeout_range_clock+0xff/0x110<br /> [ 14.859335] ? tty_write_room+0x1f/0x30<br /> [ 14.859598] ? n_tty_poll+0x1ec/0x220<br /> [ 14.859830] ? tty_ldisc_deref+0x1a/0x20<br /> [ 14.860090] schedule_hrtimeout_range+0x17/0x20<br /> [ 14.860373] do_select+0x596/0x840<br /> [ 14.860627] ? __kernel_text_address+0x16/0x50<br /> [ 14.860954] ? poll_freewait+0xb0/0xb0<br /> [ 14.861235] ? poll_freewait+0xb0/0xb0<br /> [ 14.861517] ? rpm_resume+0x49d/0x780<br /> [ 14.861798] ? common_interrupt+0x59/0xa0<br /> [ 14.862127] ? asm_common_interrupt+0x2b/0x40<br /> [ 14.862511] ? __uart_start.isra.0+0x61/0x70<br /> [ 14.862902] ? __check_object_size+0x61/0x280<br /> [ 14.863255] core_sys_select+0x1c6/0x400<br /> [ 14.863575] ? vfs_write+0x1c9/0x3d0<br /> [ 14.863853] ? vfs_write+0x1c9/0x3d0<br /> [ 14.864121] ? _copy_from_user+0x45/0x70<br /> [ 14.864526] do_pselect.constprop.0+0xb3/0xf0<br /> [ 14.864893] ? do_syscall_64+0x6d/0x90<br /> [ 14.865228] ? do_syscall_64+0x6d/0x90<br /> [ 14.865556] __x64_sys_pselect6+0x76/0xa0<br /> [ 14.865906] do_syscall_64+0x60/0x90<br /> [ 14.866214] ? syscall_exit_to_user_mode+0x2a/0x50<br /> [ 14.866640] ? do_syscall_64+0x6d/0x90<br /> [ 14.866972] ? do_syscall_64+0x6d/0x90<br /> [ 14.867286] ? do_syscall_64+0x6d/0x90<br /> [ 14.867626] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...] stripped<br /> [ 14.872959] <br /> <br /> (&amp;#39;myfpga&amp;#39; is a simple &amp;#39;uio_dmem_genirq&amp;#39; driver I wrote to test this)<br /> <br /> The implementation of "uio_dmem_genirq" was based on "uio_pdrv_genirq" and<br /> it is used in a similar manner to the "uio_pdrv_genirq" driver with respect<br /> to interrupt configuration and handling. At the time "uio_dmem_genirq" was<br /> introduced, both had the same implementation of the &amp;#39;uio_info&amp;#39; handlers<br /> irqcontrol() and handler(). Then commit 34cb27528398 ("UIO: Fix concurrency<br /> issue"), which was only applied to "uio_pdrv_genirq", ended up making them<br /> a little different. That commit, among other things, changed disable_irq()<br /> to disable_irq_nosync() in the implementation of irqcontrol(). The<br /> motivation there was to avoid a deadlock between irqcontrol() and<br /> handler(), since it added a spinlock in the irq handler, and disable_irq()<br /> waits for the completion of the irq handler.<br /> <br /> By changing disable_irq() to disable_irq_nosync() in irqcontrol(), we also<br /> avoid the sleeping-whil<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: atmel-mci: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value,<br /> it will lead two issues:<br /> 1. The memory that allocated in mmc_alloc_host() is leaked.<br /> 2. In the remove() path, mmc_remove_host() will be called to<br /> delete device, but it&amp;#39;s not added yet, it will lead a kernel<br /> crash because of null-ptr-deref in device_del().<br /> <br /> So fix this by checking the return value and calling mmc_free_host()<br /> in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix panic due to wrong pageattr of im-&gt;image<br /> <br /> In the scenario where livepatch and kretfunc coexist, the pageattr of<br /> im-&gt;image is rox after arch_prepare_bpf_trampoline in<br /> bpf_trampoline_update, and then modify_fentry or register_fentry returns<br /> -EAGAIN from bpf_tramp_ftrace_ops_func, the BPF_TRAMP_F_ORIG_STACK flag<br /> will be configured, and arch_prepare_bpf_trampoline will be re-executed.<br /> <br /> At this time, because the pageattr of im-&gt;image is rox,<br /> arch_prepare_bpf_trampoline will read and write im-&gt;image, which causes<br /> a fault. as follows:<br /> <br /> insmod livepatch-sample.ko # samples/livepatch/livepatch-sample.c<br /> bpftrace -e &amp;#39;kretfunc:cmdline_proc_show {}&amp;#39;<br /> <br /> BUG: unable to handle page fault for address: ffffffffa0206000<br /> PGD 322d067 P4D 322d067 PUD 322e063 PMD 1297e067 PTE d428061<br /> Oops: 0003 [#1] PREEMPT SMP PTI<br /> CPU: 2 PID: 270 Comm: bpftrace Tainted: G E K 6.1.0 #5<br /> RIP: 0010:arch_prepare_bpf_trampoline+0xed/0x8c0<br /> RSP: 0018:ffffc90001083ad8 EFLAGS: 00010202<br /> RAX: ffffffffa0206000 RBX: 0000000000000020 RCX: 0000000000000000<br /> RDX: ffffffffa0206001 RSI: ffffffffa0206000 RDI: 0000000000000030<br /> RBP: ffffc90001083b70 R08: 0000000000000066 R09: ffff88800f51b400<br /> R10: 000000002e72c6e5 R11: 00000000d0a15080 R12: ffff8880110a68c8<br /> R13: 0000000000000000 R14: ffff88800f51b400 R15: ffffffff814fec10<br /> FS: 00007f87bc0dc780(0000) GS:ffff88803e600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffa0206000 CR3: 0000000010b70000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> bpf_trampoline_update+0x25a/0x6b0<br /> __bpf_trampoline_link_prog+0x101/0x240<br /> bpf_trampoline_link_prog+0x2d/0x50<br /> bpf_tracing_prog_attach+0x24c/0x530<br /> bpf_raw_tp_link_attach+0x73/0x1d0<br /> __sys_bpf+0x100e/0x2570<br /> __x64_sys_bpf+0x1c/0x30<br /> do_syscall_64+0x5b/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> With this patch, when modify_fentry or register_fentry returns -EAGAIN<br /> from bpf_tramp_ftrace_ops_func, the pageattr of im-&gt;image will be reset<br /> to nx+rw.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: associate skb with a device at tx<br /> <br /> Syzkaller triggered flow dissector warning with the following:<br /> <br /> r0 = openat$ppp(0xffffffffffffff9c, &amp;(0x7f0000000000), 0xc0802, 0x0)<br /> ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &amp;(0x7f00000000c0))<br /> ioctl$PPPIOCSACTIVE(r0, 0x40107446, &amp;(0x7f0000000240)={0x2, &amp;(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})<br /> pwritev(r0, &amp;(0x7f0000000040)=[{&amp;(0x7f0000000140)=&amp;#39;\x00!&amp;#39;, 0x2}], 0x1, 0x0, 0x0)<br /> <br /> [ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0<br /> [ 9.485929] skb_get_poff+0x53/0xa0<br /> [ 9.485937] bpf_skb_get_pay_offset+0xe/0x20<br /> [ 9.485944] ? ppp_send_frame+0xc2/0x5b0<br /> [ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60<br /> [ 9.485958] ? __ppp_xmit_process+0x7a/0xe0<br /> [ 9.485968] ? ppp_xmit_process+0x5b/0xb0<br /> [ 9.485974] ? ppp_write+0x12a/0x190<br /> [ 9.485981] ? do_iter_write+0x18e/0x2d0<br /> [ 9.485987] ? __import_iovec+0x30/0x130<br /> [ 9.485997] ? do_pwritev+0x1b6/0x240<br /> [ 9.486016] ? trace_hardirqs_on+0x47/0x50<br /> [ 9.486023] ? __x64_sys_pwritev+0x24/0x30<br /> [ 9.486026] ? do_syscall_64+0x3d/0x80<br /> [ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Flow dissector tries to find skb net namespace either via device<br /> or via socket. Neigher is set in ppp_send_frame, so let&amp;#39;s manually<br /> use ppp-&gt;dev.