CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47555 – net: vlan: fix underflow for the real_dev refcnt
https://notcve.org/view.php?id=CVE-2021-47555
In the Linux kernel, the following vulnerability has been resolved: net: vlan: fix underflow for the real_dev refcnt Inject error before dev_hold(real_dev) in register_vlan_dev(), and execute the following testcase: ip link add dev dummy1 type dummy ip link add name dummy1.100 link dummy1 type vlan id 100 ip link del dev dummy1 When the dummy netdevice is removed, we will get a WARNING as following: ======================================================================= refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 2 PID: 0 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 and an endless loop of: ======================================================================= unregister_netdevice: waiting for dummy1 to become free. Usage count = -1073741824 That is because dev_put(real_dev) in vlan_dev_free() be called without dev_hold(real_dev) in register_vlan_dev(). It makes the refcnt of real_dev underflow. Move the dev_hold(real_dev) to vlan_dev_init() which is the call-back of ndo_init(). That makes dev_hold() and dev_put() for vlan's real_dev symmetrical. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: vlan: corrige el desbordamiento insuficiente para real_dev refcnt Inyecte el error antes de dev_hold(real_dev) en Register_vlan_dev() y ejecute el siguiente caso de prueba: ip link add dev dummy1 tipo dummy ip link add nombre dummy1.100 link dummy1 tipo vlan id 100 ip link del dev dummy1 Cuando se elimina el dispositivo de red ficticio, recibiremos una ADVERTENCIA como la siguiente: ===================== ==================================================== = refcount_t: decremento hit 0; pérdida de memoria. • https://git.kernel.org/stable/c/700602b662d7eaa816b1a3cb0abe7a85de358fd4 https://git.kernel.org/stable/c/e04a7a84bb77f9cdf4475340fe931389bc72331c https://git.kernel.org/stable/c/21032425c36ff85f16e72ca92193a8c401e4acd5 https://git.kernel.org/stable/c/fca96b3f852a1b369b7b2844ce357cd689879934 https://git.kernel.org/stable/c/5e44178864b38dd70b877985abd7d86fdb95f27d https://git.kernel.org/stable/c/6e800ee43218a56acc93676bbb3d93b74779e555 https://git.kernel.org/stable/c/f7fc72a508cf115c273a7a29350069def1041890 https://git.kernel.org/stable/c/01d9cc2dea3fde3bad6d27f464eff4634 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47553 – sched/scs: Reset task stack state in bringup_cpu()
https://notcve.org/view.php?id=CVE-2021-47553
In the Linux kernel, the following vulnerability has been resolved: sched/scs: Reset task stack state in bringup_cpu() To hot unplug a CPU, the idle task on that CPU calls a few layers of C code before finally leaving the kernel. When KASAN is in use, poisoned shadow is left around for each of the active stack frames, and when shadow call stacks are in use. When shadow call stacks (SCS) are in use the task's saved SCS SP is left pointing at an arbitrary point within the task's shadow call stack. When a CPU is offlined than onlined back into the kernel, this stale state can adversely affect execution. Stale KASAN shadow can alias new stackframes and result in bogus KASAN warnings. A stale SCS SP is effectively a memory leak, and prevents a portion of the shadow call stack being used. • https://git.kernel.org/stable/c/3c51d82d0b7862d7d246016c74b4390fb1fa1f11 https://git.kernel.org/stable/c/f1a0a376ca0c4ef1fc3d24e3e502acbb5b795674 https://git.kernel.org/stable/c/1cb358b3ac1bb43aa8c4283830a84216dda65d39 https://git.kernel.org/stable/c/24c79a7e54ccfa29fb8cbf7ed8d1e48ff1ec6e3d https://git.kernel.org/stable/c/e6ee7abd6bfe559ad9989004b34c320fd638c526 https://git.kernel.org/stable/c/229c555260cb9c1ccdab861e16f0410f1718f302 https://git.kernel.org/stable/c/dce1ca0525bfdc8a69a9343bc714fbc19a2f04b3 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47552 – blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()
https://notcve.org/view.php?id=CVE-2021-47552
In the Linux kernel, the following vulnerability has been resolved: blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release() For avoiding to slow down queue destroy, we don't call blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to cancel dispatch work in blk_release_queue(). However, this way has caused kernel oops[1], reported by Changhui. The log shows that scsi_device can be freed before running blk_release_queue(), which is expected too since scsi_device is released after the scsi disk is closed and the scsi_device is removed. Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue() and disk_release(): 1) when disk_release() is run, the disk has been closed, and any sync dispatch activities have been done, so canceling dispatch work is enough to quiesce filesystem I/O dispatch activity. 2) in blk_cleanup_queue(), we only focus on passthrough request, and passthrough request is always explicitly allocated & freed by its caller, so once queue is frozen, all sync dispatch activity for passthrough request has been done, then it is enough to just cancel dispatch work for avoiding any dispatch activity. [1] kernel panic log [12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300 [12622.777186] #PF: supervisor read access in kernel mode [12622.782918] #PF: error_code(0x0000) - not-present page [12622.788649] PGD 0 P4D 0 [12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI [12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1 [12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015 [12622.813321] Workqueue: kblockd blk_mq_run_work_fn [12622.818572] RIP: 0010:sbitmap_get+0x75/0x190 [12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 <48> 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58 [12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202 [12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004 [12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030 [12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334 [12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000 [12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030 [12622.889926] FS: 0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000 [12622.898956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0 [12622.913328] Call Trace: [12622.916055] <TASK> [12622.918394] scsi_mq_get_budget+0x1a/0x110 [12622.922969] __blk_mq_do_dispatch_sched+0x1d4/0x320 [12622.928404] ? pick_next_task_fair+0x39/0x390 [12622.933268] __blk_mq_sched_dispatch_requests+0xf4/0x140 [12622.939194] blk_mq_sched_dispatch_requests+0x30/0x60 [12622.944829] __blk_mq_run_hw_queue+0x30/0xa0 [12622.949593] process_one_work+0x1e8/0x3c0 [12622.954059] worker_thread+0x50/0x3b0 [12622.958144] ? rescuer_thread+0x370/0x370 [12622.962616] kthread+0x158/0x180 [12622.966218] ? • https://git.kernel.org/stable/c/e03513f58919d9e2bc6df765ca2c9da863d03d90 https://git.kernel.org/stable/c/2a19b28f7929866e1cec92a3619f4de9f2d20005 •
CVSS: 6.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47551 – drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered again
https://notcve.org/view.php?id=CVE-2021-47551
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered again In SRIOV configuration, the reset may failed to bring asic back to normal but stop cpsch already been called, the start_cpsch will not be called since there is no resume in this case. When reset been triggered again, driver should avoid to do uninitialization again. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/amdkfd: corrige el pánico del kernel cuando el reinicio falla y se activa nuevamente. En la configuración SRIOV, el reinicio puede no lograr que asic vuelva a la normalidad, pero ya se ha llamado a detener cpsch, el No se llamará a start_cpsch ya que en este caso no hay ningún currículum. Cuando el reinicio se activa nuevamente, el controlador debe evitar realizar la desinicialización nuevamente. • https://git.kernel.org/stable/c/74aafe99efb68f15e50be9f7032c2168512f98a8 https://git.kernel.org/stable/c/06c6f8f86ec243b89e52f0c3dc7062bcb9de74df https://git.kernel.org/stable/c/2cf49e00d40d5132e3d067b5aa6d84791929ab15 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47550 – drm/amd/amdgpu: fix potential memleak
https://notcve.org/view.php?id=CVE-2021-47550
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: fix potential memleak In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed There is a potential memleak if not call kobject_put. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/amdgpu: corrige una posible fuga de mem en la función amdgpu_get_xgmi_hive, cuando falla kobject_init_and_add Hay una posible fuga de mem si no se llama a kobject_put. • https://git.kernel.org/stable/c/c746945fb6bcbe3863c9ea6369c7ef376e38e5eb https://git.kernel.org/stable/c/75752ada77e0726327adf68018b9f50ae091baeb https://git.kernel.org/stable/c/27dfaedc0d321b4ea4e10c53e4679d6911ab17aa • CWE-401: Missing Release of Memory after Effective Lifetime •