CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48823 – scsi: qedf: Fix refcount issue when LOGO is received during TMF
https://notcve.org/view.php?id=CVE-2022-48823
In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Fix refcount issue when LOGO is received during TMF Hung task call trace was seen during LOGO processing. [ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued... [ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0 [ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET [ 974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1. [ 974.309625] host1: rport 016900: Received LOGO request while in state Ready [ 974.309627] host1: rport 016900: Delete port [ 974.309642] host1: rport 016900: work event 3 [ 974.309644] host1: rport 016900: lld callback ev 3 [ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport is uploading, not executing flush. [ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: task mgmt command success... [ 984.031088] INFO: task jbd2/dm-15-8:7645 blocked for more than 120 seconds. [ 984.031136] Not tainted 4.18.0-305.el8.x86_64 #1 [ 984.031166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080 [ 984.031212] Call Trace: [ 984.031222] __schedule+0x2c4/0x700 [ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0 [ 984.031233] ? bit_wait_timeout+0x90/0x90 [ 984.031235] schedule+0x38/0xa0 [ 984.031238] io_schedule+0x12/0x40 [ 984.031240] bit_wait_io+0xd/0x50 [ 984.031243] __wait_on_bit+0x6c/0x80 [ 984.031248] ? free_buffer_head+0x21/0x50 [ 984.031251] out_of_line_wait_on_bit+0x91/0xb0 [ 984.031257] ? init_wait_var_entry+0x50/0x50 [ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2] [ 984.031280] kjournald2+0xbd/0x270 [jbd2] [ 984.031284] ? • https://git.kernel.org/stable/c/7cc32ff0cd6c44a3c26de5faecfe8b5546198fad https://git.kernel.org/stable/c/87f187e5265bc8e3b38faef8b9db864cdd61dde7 https://git.kernel.org/stable/c/6be8eaad75ca73131e2a697f0270dc8ee73814a8 https://git.kernel.org/stable/c/7fcbed38503bb34c6e6538b6a9482d1c6bead1e8 https://git.kernel.org/stable/c/5239ab63f17cee643bd4bf6addfedebaa7d4f41e •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48822 – usb: f_fs: Fix use-after-free for epfile
https://notcve.org/view.php?id=CVE-2022-48822
In the Linux kernel, the following vulnerability has been resolved: usb: f_fs: Fix use-after-free for epfile Consider a case where ffs_func_eps_disable is called from ffs_func_disable as part of composition switch and at the same time ffs_epfile_release get called from userspace. ffs_epfile_release will free up the read buffer and call ffs_data_closed which in turn destroys ffs->epfiles and mark it as NULL. While this was happening the driver has already initialized the local epfile in ffs_func_eps_disable which is now freed and waiting to acquire the spinlock. Once spinlock is acquired the driver proceeds with the stale value of epfile and tries to free the already freed read buffer causing use-after-free. Following is the illustration of the race: CPU1 CPU2 ffs_func_eps_disable epfiles (local copy) ffs_epfile_release ffs_data_closed if (last file closed) ffs_data_reset ffs_data_clear ffs_epfiles_destroy spin_lock dereference epfiles Fix this races by taking epfiles local copy & assigning it under spinlock and if epfiles(local) is null then update it in ffs->epfiles then finally destroy it. Extending the scope further from the race, protecting the ep related structures, and concurrent accesses. • https://git.kernel.org/stable/c/a9e6f83c2df199187a5248f824f31b6787ae23ae https://git.kernel.org/stable/c/5cd8f6788ff34999dbd4cbec81a6adfc215e1e60 https://git.kernel.org/stable/c/32048f4be071f9a6966744243f1786f45bb22dc2 https://git.kernel.org/stable/c/cfe5f6fd335d882bcc829a1c8a7d462a455c626e https://git.kernel.org/stable/c/c9fc422c9a43e3d58d246334a71f3390401781dc https://git.kernel.org/stable/c/0042178a69eb77a979e36a50dcce9794a3140ef8 https://git.kernel.org/stable/c/72a8aee863af099d4434314c4536d6c9a61dcf3c https://git.kernel.org/stable/c/3e078b18753669615301d946297bafd69 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48821 – misc: fastrpc: avoid double fput() on failed usercopy
https://notcve.org/view.php?id=CVE-2022-48821
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: avoid double fput() on failed usercopy If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact, dma_buf_fd() called fd_install() before, i.e. "consumed" one reference, leaving us with none. Calling dma_buf_put() will therefore put a reference we no longer own, leading to a valid file descritor table entry for an already released 'file' object which is a straight use-after-free. Simply avoid calling dma_buf_put() and rely on the process exit code to do the necessary cleanup, if needed, i.e. if the file descriptor is still valid. • https://git.kernel.org/stable/c/6cffd79504ce040f460831030d3069fa1c99bb71 https://git.kernel.org/stable/c/4e6fd2b5fcf8e7119305a6042bd92e7f2b9ed215 https://git.kernel.org/stable/c/a5ce7ee5fcc07583159f54ab4af5164de00148f5 https://git.kernel.org/stable/c/e4382d0a39f9a1e260d62fdc079ddae5293c037d https://git.kernel.org/stable/c/76f85c307ef9f10aa2cef1b1d5ee654c1f3345fc https://git.kernel.org/stable/c/46963e2e0629cb31c96b1d47ddd89dc3d8990b34 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48820 – phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable()
https://notcve.org/view.php?id=CVE-2022-48820
In the Linux kernel, the following vulnerability has been resolved: phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable() This error path needs to decrement "usbphyc->n_pll_cons.counter" before returning. • https://git.kernel.org/stable/c/5b1af71280abd82efbe28cd28d553363dfde0a34 https://git.kernel.org/stable/c/94b16ca86ab688ed6fad4548f70137f93cf1f0a9 https://git.kernel.org/stable/c/0ad1a88fa3eb0ded7798f52b79bc33f75fc9a6d2 https://git.kernel.org/stable/c/cfc826c88a79e22ba5d8001556eb2c7efd8a01b6 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48819 – tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case
https://notcve.org/view.php?id=CVE-2022-48819
In the Linux kernel, the following vulnerability has been resolved: tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY) calls over the same TCP socket would again trigger the infamous warning in inet_sock_destruct() WARN_ON(sk_forward_alloc_get(sk)); While Talal took into account a mix of regular copied data and MSG_ZEROCOPY one in the same skb, the sendpage() path has been forgotten. We want the charging to happen for sendpage(), because pages could be coming from a pipe. What is missing is the downgrading of pure zerocopy status to make sure sk_forward_alloc will stay synced. Add tcp_downgrade_zcopy_pure() helper so that we can use it from the two callers. • https://git.kernel.org/stable/c/9b65b17db72313b7a4fe9bc9502928c88be57986 https://git.kernel.org/stable/c/47f3860c4931175f112f28dcac66eacca9b1040f https://git.kernel.org/stable/c/f8d9d938514f46c4892aff6bfe32f425e84d81cc •