CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47045 – scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb()
https://notcve.org/view.php?id=CVE-2021-47045
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb() It is possible to call lpfc_issue_els_plogi() passing a did for which no matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a null pointer to a lpfc_nodelist structure resulting in a null pointer dereference. Fix by returning an error status if no valid ndlp is found. Fix up comments regarding ndlp reference counting. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: lpfc: corrige la desreferencia del puntero nulo en lpfc_prep_els_iocb() Es posible llamar a lpfc_issue_els_plogi() pasando un did para el cual no se encuentra ningún ndlp coincidente. Luego se realiza una llamada a lpfc_prep_els_iocb() con un puntero nulo a una estructura lpfc_nodelist, lo que da como resultado una desreferencia del puntero nulo. • https://git.kernel.org/stable/c/4430f7fd09ecb037570119e0aacbf0c17b8f98b2 https://git.kernel.org/stable/c/a09677de458d500b00701f6036baa423d9995408 https://git.kernel.org/stable/c/9bdcfbed2a9fe24d2c7eaa1bad7c705e18de8cc7 https://git.kernel.org/stable/c/8dd1c125f7f838abad009b64bff5f0a11afe3cb6 •
CVSS: 7.7EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47044 – sched/fair: Fix shift-out-of-bounds in load_balance()
https://notcve.org/view.php?id=CVE-2021-47044
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix shift-out-of-bounds in load_balance() Syzbot reported a handful of occurrences where an sd->nr_balance_failed can grow to much higher values than one would expect. A successful load_balance() resets it to 0; a failed one increments it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an active balance, which will either set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run on env->dst_cpu, then the increment is done without any further modification. This could then be repeated ad nauseam, and would explain the absurdly high values reported by syzbot (86, 149). VincentG noted there is value in letting sd->cache_nice_tries grow, so the shift itself should be fixed. That means preventing: """ If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. """ Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) - 1. I had a look around for other similar cases via coccinelle: @expr@ position pos; expression E1; expression E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depends on expr@ position pos; expression expr.E1; constant cst; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depends on ! • https://git.kernel.org/stable/c/5a7f555904671c0737819fe4d19bd6143de3f6c0 https://git.kernel.org/stable/c/80862cbf76c2646f709a57c4517aefe0b094c774 https://git.kernel.org/stable/c/2f3eab368e313dba35fc2f51ede778bf7b030b54 https://git.kernel.org/stable/c/805cea93e66ca7deaaf6ad3b67224ce47c104c2f https://git.kernel.org/stable/c/39a2a6eb5c9b66ea7c8055026303b3aa681b49a5 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47043 – media: venus: core: Fix some resource leaks in the error path of 'venus_probe()'
https://notcve.org/view.php?id=CVE-2021-47043
In the Linux kernel, the following vulnerability has been resolved: media: venus: core: Fix some resource leaks in the error path of 'venus_probe()' If an error occurs after a successful 'of_icc_get()' call, it must be undone. Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak. Update the remove function accordingly and axe the now unneeded 'icc_put()' calls. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: media: venus: core: corrige algunas fugas de recursos en la ruta de error de 'venus_probe()' Si se produce un error después de una llamada exitosa a 'of_icc_get()', se debe deshacer . Utilice 'devm_of_icc_get()' en lugar de 'of_icc_get()' para evitar la fuga. Actualice la función de eliminación en consecuencia y elimine las llamadas 'icc_put()' ahora innecesarias. • https://git.kernel.org/stable/c/32f0a6ddc8c98a1aade2bf3d07c79d5d2c6ceb9a https://git.kernel.org/stable/c/00b68a7478343afdf83f30c43e64db5296057030 https://git.kernel.org/stable/c/940d01eceb3a7866fbfca136a55a5625fc75a565 https://git.kernel.org/stable/c/711acdf0228dc71601247f28b56f13e850e395c8 https://git.kernel.org/stable/c/5a465c5391a856a0c1e9554964d660676c35d1b2 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47042 – drm/amd/display: Free local data after use
https://notcve.org/view.php?id=CVE-2021-47042
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Free local data after use Fixes the following memory leak in dc_link_construct(): unreferenced object 0xffffa03e81471400 (size 1024): comm "amd_module_load", pid 2486, jiffies 4294946026 (age 10.544s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0 [<00000000e7c59f0e>] link_create+0xce/0xac0 [amdgpu] [<000000002fb6c072>] dc_create+0x370/0x720 [amdgpu] [<000000000094d1f3>] amdgpu_dm_init+0x18e/0x17a0 [amdgpu] [<00000000bec048fd>] dm_hw_init+0x12/0x20 [amdgpu] [<00000000a2bb7cf6>] amdgpu_device_init+0x1463/0x1e60 [amdgpu] [<0000000032d3bb13>] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu] [<00000000a27834f9>] amdgpu_pci_probe+0x192/0x280 [amdgpu] [<00000000fec7d291>] local_pci_probe+0x47/0xa0 [<0000000055dbbfa7>] pci_device_probe+0xe3/0x180 [<00000000815da970>] really_probe+0x1c4/0x4e0 [<00000000b4b6974b>] driver_probe_device+0x62/0x150 [<000000000f9ecc61>] device_driver_attach+0x58/0x60 [<000000000f65c843>] __driver_attach+0xd6/0x150 [<000000002f5e3683>] bus_for_each_dev+0x6a/0xc0 [<00000000a1cfc897>] driver_attach+0x1e/0x20 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: datos locales gratuitos después de su uso. Corrige la siguiente pérdida de memoria en dc_link_construct(): objeto sin referencia 0xffffa03e81471400 (tamaño 1024): comm "amd_module_load", pid 2486, jiffies 4294946026 (edad 10,544 s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso: [<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0 [<00000000e7c59f0e>] link_create+0xce/0xac0 [amdgpu] [<000000002fb6c072>] dc_create+0x370/0x720 [amdgpu] [<000000000094d1f3>] amdgpu_dm_init+0x18e/0x17a0 [amdgpu] [<00000000bec048fd>] dm_hw_in es+0x12/0x20 [amdgpu] [<00000000a2bb7cf6>] amdgpu_device_init+0x1463 /0x1e60 [amdgpu] [<0000000032d3bb13>] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu] [<00000000a27834f9>] amdgpu_pci_probe+0x192/0x280 [amdgpu] [<00000000fec7d29 1>] local_pci_probe+0x47/0xa0 [<0000000055dbbfa7>] pci_device_probe+0xe3/ 0x180 [<00000000815da970>] very_probe+0x1c4/0x4e0 [<00000000b4b6974b>] driver_probe_device+0x62/0x150 [<000000000f9ecc61>] device_driver_attach+0x58/0x60 [<0000000 00f65c843>] __driver_attach+0xd6/0x150 [<000000002f5e3683>] bus_for_each_dev+0x6a/ 0xc0 [<00000000a1cfc897>] controlador_attach+0x1e/0x20 • https://git.kernel.org/stable/c/3a00c04212d1cfe1426338b78f4ead623508c874 https://git.kernel.org/stable/c/296443139f893b554dddd56a99ba8471ab5802d4 https://git.kernel.org/stable/c/616cf23b6cf40ad6f03ffbddfa1b6c4eb68d8ae1 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47041 – nvmet-tcp: fix incorrect locking in state_change sk callback
https://notcve.org/view.php?id=CVE-2021-47041
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? • https://git.kernel.org/stable/c/872d26a391da92ed8f0c0f5cb5fef428067b7f30 https://git.kernel.org/stable/c/999d606a820c36ae9b9e9611360c8b3d8d4bb777 https://git.kernel.org/stable/c/60ade0d56b06537a28884745059b3801c78e03bc https://git.kernel.org/stable/c/06beaa1a9f6e501213195e47c30416032fd2bbd5 https://git.kernel.org/stable/c/906c538340dde6d891df89fe7dac8eaa724e40da https://git.kernel.org/stable/c/b5332a9f3f3d884a1b646ce155e664cc558c1722 •