Vulnerabilities

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 /> 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.

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 /> nfc: pn533: Clear nfc_target before being used<br /> <br /> Fix a slab-out-of-bounds read that occurs in nla_put() called from<br /> nfc_genl_send_target() when target-&gt;sensb_res_len, which is duplicated<br /> from an nfc_target in pn533, is too large as the nfc_target is not<br /> properly initialized and retains garbage values. Clear nfc_targets with<br /> memset() before they are used.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> BUG: KASAN: slab-out-of-bounds in nla_put<br /> Call Trace:<br /> memcpy<br /> nla_put<br /> nfc_genl_dump_targets<br /> genl_lock_dumpit<br /> netlink_dump<br /> __netlink_dump_start<br /> genl_family_rcv_msg_dumpit<br /> genl_rcv_msg<br /> netlink_rcv_skb<br /> genl_rcv<br /> netlink_unicast<br /> netlink_sendmsg<br /> sock_sendmsg<br /> ____sys_sendmsg<br /> ___sys_sendmsg<br /> __sys_sendmsg<br /> do_syscall_64

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: kill hooked chains to avoid loops on deduplicated compressed images<br /> <br /> After heavily stressing EROFS with several images which include a<br /> hand-crafted image of repeated patterns for more than 46 days, I found<br /> two chains could be linked with each other almost simultaneously and<br /> form a loop so that the entire loop won&amp;#39;t be submitted. As a<br /> consequence, the corresponding file pages will remain locked forever.<br /> <br /> It can be _only_ observed on data-deduplicated compressed images.<br /> For example, consider two chains with five pclusters in total:<br /> Chain 1: 2-&gt;3-&gt;4-&gt;5 -- The tail pcluster is 5;<br /> Chain 2: 5-&gt;1-&gt;2 -- The tail pcluster is 2.<br /> <br /> Chain 2 could link to Chain 1 with pcluster 5; and Chain 1 could link<br /> to Chain 2 at the same time with pcluster 2.<br /> <br /> Since hooked chains are all linked locklessly now, I have no idea how<br /> to simply avoid the race. Instead, let&amp;#39;s avoid hooked chains completely<br /> until I could work out a proper way to fix this and end users finally<br /> tell us that it&amp;#39;s needed to add it back.<br /> <br /> Actually, this optimization can be found with multi-threaded workloads<br /> (especially even more often on deduplicated compressed images), yet I&amp;#39;m<br /> not sure about the overall system impacts of not having this compared<br /> with implementation complexity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Clean up integer overflow checking in map_user_pages()<br /> <br /> The encode_dma() function has some validation on in_trans-&gt;size but it<br /> would be more clear to move those checks to find_and_map_user_pages().<br /> <br /> The encode_dma() had two checks:<br /> <br /> if (in_trans-&gt;addr + in_trans-&gt;size addr || !in_trans-&gt;size)<br /> return -EINVAL;<br /> <br /> The in_trans-&gt;addr variable is the starting address. The in_trans-&gt;size<br /> variable is the total size of the transfer. The transfer can occur in<br /> parts and the resources-&gt;xferred_dma_size tracks how many bytes we have<br /> already transferred.<br /> <br /> This patch introduces a new variable "remaining" which represents the<br /> amount we want to transfer (in_trans-&gt;size) minus the amount we have<br /> already transferred (resources-&gt;xferred_dma_size).<br /> <br /> I have modified the check for if in_trans-&gt;size is zero to instead check<br /> if in_trans-&gt;size is less than resources-&gt;xferred_dma_size. If we have<br /> already transferred more bytes than in_trans-&gt;size then there are negative<br /> bytes remaining which doesn&amp;#39;t make sense. If there are zero bytes<br /> remaining to be copied, just return success.<br /> <br /> The check in encode_dma() checked that "addr + size" could not overflow<br /> and barring a driver bug that should work, but it&amp;#39;s easier to check if<br /> we do this in parts. First check that "in_trans-&gt;addr +<br /> resources-&gt;xferred_dma_size" is safe. Then check that "xfer_start_addr +<br /> remaining" is safe.<br /> <br /> My final concern was that we are dealing with u64 values but on 32bit<br /> systems the kmalloc() function will truncate the sizes to 32 bits. So<br /> I calculated "total = in_trans-&gt;size + offset_in_page(xfer_start_addr);"<br /> and returned -EINVAL if it were &gt;= SIZE_MAX. This will not affect 64bit<br /> systems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper()<br /> <br /> As the comment of pci_get_domain_bus_and_slot() says, it returns<br /> a PCI device with refcount incremented, so it doesn&amp;#39;t need to<br /> call an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCI<br /> device needs to be put in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hpsa: Fix possible memory leak in hpsa_init_one()<br /> <br /> The hpda_alloc_ctlr_info() allocates h and its field reply_map. However, in<br /> hpsa_init_one(), if alloc_percpu() failed, the hpsa_init_one() jumps to<br /> clean1 directly, which frees h and leaks the h-&gt;reply_map.<br /> <br /> Fix by calling hpda_free_ctlr_info() to release h-&gt;replay_map and h instead<br /> free h directly.