Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf tool x86: Fix perf_env memory leak<br /> <br /> Found by leak sanitizer:<br /> ```<br /> ==1632594==ERROR: LeakSanitizer: detected memory leaks<br /> <br /> Direct leak of 21 byte(s) in 1 object(s) allocated from:<br /> #0 0x7f2953a7077b in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:439<br /> #1 0x556701d6fbbf in perf_env__read_cpuid util/env.c:369<br /> #2 0x556701d70589 in perf_env__cpuid util/env.c:465<br /> #3 0x55670204bba2 in x86__is_amd_cpu arch/x86/util/env.c:14<br /> #4 0x5567020487a2 in arch__post_evsel_config arch/x86/util/evsel.c:83<br /> #5 0x556701d8f78b in evsel__config util/evsel.c:1366<br /> #6 0x556701ef5872 in evlist__config util/record.c:108<br /> #7 0x556701cd6bcd in test__PERF_RECORD tests/perf-record.c:112<br /> #8 0x556701cacd07 in run_test tests/builtin-test.c:236<br /> #9 0x556701cacfac in test_and_print tests/builtin-test.c:265<br /> #10 0x556701cadddb in __cmd_test tests/builtin-test.c:402<br /> #11 0x556701caf2aa in cmd_test tests/builtin-test.c:559<br /> #12 0x556701d3b557 in run_builtin tools/perf/perf.c:323<br /> #13 0x556701d3bac8 in handle_internal_command tools/perf/perf.c:377<br /> #14 0x556701d3be90 in run_argv tools/perf/perf.c:421<br /> #15 0x556701d3c3f8 in main tools/perf/perf.c:537<br /> #16 0x7f2952a46189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58<br /> <br /> SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s).<br /> ```

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix session state check in reconnect to avoid use-after-free issue<br /> <br /> Don&amp;#39;t collect exiting session in smb2_reconnect_server(), because it<br /> will be released soon.<br /> <br /> Note that the exiting session will stay in server-&gt;smb_ses_list until<br /> it complete the cifs_free_ipc() and logoff() and then delete itself<br /> from the list.

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.