CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48824 – scsi: myrs: Fix crash in error case
https://notcve.org/view.php?id=CVE-2022-48824
In the Linux kernel, the following vulnerability has been resolved: scsi: myrs: Fix crash in error case In myrs_detect(), cs->disable_intr is NULL when privdata->hw_init() fails with non-zero. In this case, myrs_cleanup(cs) will call a NULL ptr and crash the kernel. [ 1.105606] myrs 0000:00:03.0: Unknown Initialization Error 5A [ 1.105872] myrs 0000:00:03.0: Failed to initialize Controller [ 1.106082] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.110774] Call Trace: [ 1.110950] myrs_cleanup+0xe4/0x150 [myrs] [ 1.111135] myrs_probe.cold+0x91/0x56a [myrs] [ 1.111302] ? DAC960_GEM_intr_handler+0x1f0/0x1f0 [myrs] [ 1.111500] local_pci_probe+0x48/0x90 • https://git.kernel.org/stable/c/5c5ceea00c8c9df150708e66cb9f2891192c1162 https://git.kernel.org/stable/c/0e42c4a3d732517edc3766dd45a14e60d29dd929 https://git.kernel.org/stable/c/6207f35c213f6cb2fc3f13b5e77f08c710e1de19 https://git.kernel.org/stable/c/1d6cd26605b4d662063a83c15c776b5299a1cb23 https://git.kernel.org/stable/c/4db09593af0b0b4d7d4805ebb3273df51d7cc30d •
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-48811 – ibmvnic: don't release napi in __ibmvnic_open()
https://notcve.org/view.php?id=CVE-2022-48811
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: don't release napi in __ibmvnic_open() If __ibmvnic_open() encounters an error such as when setting link state, it calls release_resources() which frees the napi structures needlessly. Instead, have __ibmvnic_open() only clean up the work it did so far (i.e. disable napi and irqs) and leave the rest to the callers. If caller of __ibmvnic_open() is ibmvnic_open(), it should release the resources immediately. If the caller is do_reset() or do_hard_reset(), they will release the resources on the next reset. This fixes following crash that occurred when running the drmgr command several times to add/remove a vnic interface: [102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq [102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq [102056] ibmvnic 30000003 env3: Replenished 8 pools Kernel attempted to read user page (10) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000a3c840 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries ... CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1 Workqueue: events_long __ibmvnic_reset [ibmvnic] NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820 REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28248484 XER: 00000004 CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0 GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000 ... NIP [c000000000a3c840] napi_enable+0x20/0xc0 LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic] Call Trace: [c0000000548e3a80] [0000000000000006] 0x6 (unreliable) [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic] [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic] [c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570 [c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660 [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0 [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010 38a0fff6 e92d1100 f9210028 39200000 <e9030010> f9010020 60420000 e9210020 ---[ end trace 5f8033b08fd27706 ]--- • https://git.kernel.org/stable/c/ed651a10875f13135a5f59c1bae4d51b377b3925 https://git.kernel.org/stable/c/960dfaf3b578dd23af012590e809ae2d58ba1827 https://git.kernel.org/stable/c/e08cb9056fb2564d1f6bad789bdf79ab09bf2f81 https://git.kernel.org/stable/c/61772b0908c640d0309c40f7d41d062ca4e979fa •