CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48850 – net-sysfs: add check for netdevice being present to speed_show
https://notcve.org/view.php?id=CVE-2022-48850
In the Linux kernel, the following vulnerability has been resolved: net-sysfs: add check for netdevice being present to speed_show When bringing down the netdevice or system shutdown, a panic can be triggered while accessing the sysfs path because the device is already removed. [ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called [ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called ... [ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null) [ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280 crash> bt ... PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd" ... #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778 [exception RIP: dma_pool_alloc+0x1ab] RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046 RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090 RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00 R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0 R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core] #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core] #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core] #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core] #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core] #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core] #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core] #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46 #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208 #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3 #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596 #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10 #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5 #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92 crash> net_device.state ffff89443b0c0000 state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER) To prevent this scenario, we also make sure that the netdevice is present. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net-sysfs: agregue verificación para que netdevice esté presente en speed_show Al desactivar el netdevice o apagar el sistema, se puede desencadenar un pánico al acceder a la ruta sysfs porque el dispositivo ya está eliminado. [ 755.549084] mlx5_core 0000:12:00.1: Se llamó al apagado [ 756.404455] mlx5_core 0000:12:00.0: Se llamó al apagado... [ 757.937260] ERROR: no se puede manejar la desreferencia del puntero NULL del kernel en (nulo) [ 758.031397] IP: [] dma_pool_alloc+0x1ab/0x280 crash> bt... PID: 12649 TAREA: ffff8924108f2100 CPU: 1 COMANDO: "amsd"... #9 [ffff89240e1a38b0] page_fault en ffffffff8f38c778 [excepción RIP: pool_alloc+0x1ab] RIP : ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046 RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000 RDX: 00000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090 RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00 R10: ffffffffc04680d4 R11: d R12: 00000000000080d0 R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg en ffffffffc04680f3 [mlx5_core] #11 [ffff89240e1a3a18] d_exec en ffffffffc046ad62 [mlx5_core] #12 [ffff89240e1a3ab8] mlx5_cmd_exec en ffffffffc046b4fb [mlx5_core] #13 [ffff89240e1a3ae8] mlx5_core_access_reg en ffffffffc0475434 [mlx5_core] #14 [ffff89240e1a3b40] mlx5e_get_fec_caps en ffffffffc04a7348 [mlx5_core] #15 [ffff89240e1a3bb0] get_fec_supported_advertised en ffffffffc04992bf [mlx5_core] #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings en ffffffffc049ab36 [mlx5_core] #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings en ffffffff8f25db46 #18 [ ffff89240e1a3d48] speed_show en ffffffff8f277208 #19 [ffff89240e1a3dd8] dev_attr_show en ffffffff8f0b70e3 #20 [ffff89240e1a3df8] sysfs_kf_seq_show en ffffffff8eedbedf #21 40e1a3e18] kernfs_seq_show en ffffffff8eeda596 #22 [ffff89240e1a3e28] seq_read en ffffffff8ee76d10 #23 [ffff89240e1a3e98] kernfs_fop_read en ffffffff8eedaef5 #24 8] vfs_read en ffffffff8ee4e3ff #25 [ffff89240e1a3f08] sys_read en ffffffff8ee4f27f #26 [ffff89240e1a3f50] system_call_fastpath en ffffffff8f395f92 crash> net_device.state ffff89443b0c0000 estado = 0x5 LINK_STATE_START| __LINK_STATE_NOCARRIER) Para evitar este escenario, también nos aseguramos de que el netdevice esté presente. • https://git.kernel.org/stable/c/a7b9ab04c5932dee7ec95e0abc58b0df350c0dd2 https://git.kernel.org/stable/c/081369ad088a76429984483b8a5f7e967a125aad https://git.kernel.org/stable/c/75fc8363227a999e8f3d17e2eb28dce5600dcd3f https://git.kernel.org/stable/c/8879b5313e9fa5e0c6d6812a0d25d83aed0110e2 https://git.kernel.org/stable/c/d15c9f6e3335002fea1c33bc8f71a705fa96976c https://git.kernel.org/stable/c/8d5e69d8fbf3a35ab4fbe56b8f092802b43f3ef6 https://git.kernel.org/stable/c/3a79f380b3e10edf6caa9aac90163a5d7a282204 https://git.kernel.org/stable/c/4224cfd7fb6523f7a9d1c8bb91bb5df1e • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48849 – drm/amdgpu: bypass tiling flag check in virtual display case (v2)
https://notcve.org/view.php?id=CVE-2022-48849
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: bypass tiling flag check in virtual display case (v2) vkms leverages common amdgpu framebuffer creation, and also as it does not support FB modifier, there is no need to check tiling flags when initing framebuffer when virtual display is enabled. This can fix below calltrace: amdgpu 0000:00:08.0: GFX9+ requires FB check based on format modifier WARNING: CPU: 0 PID: 1023 at drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150 amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu] v2: check adev->enable_virtual_display instead as vkms can be enabled in bare metal as well. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: omite la verificación del indicador de mosaico en la vitrina virtual (v2) vkms aprovecha la creación de framebuffer amdgpu común y, además, como no admite el modificador FB, no es necesario verificar los indicadores de mosaico al iniciar framebuffer cuando la visualización virtual está habilitada. Esto se puede solucionar a continuación: amdgpu 0000:00:08.0: GFX9+ requiere verificación de FB según el modificador de formato ADVERTENCIA: CPU: 0 PID: 1023 en drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150 amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu] v2: marque adev->enable_virtual_display en su lugar, ya que vkms también se puede habilitar en bare metal. • https://git.kernel.org/stable/c/fcd1d79aa943fff4fbaa0cce1d576995a7960699 https://git.kernel.org/stable/c/cb29021be49858059138f75d6311a7c35a9379b2 https://git.kernel.org/stable/c/e2b993302f40c4eb714ecf896dd9e1c5be7d4cd7 •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48847 – watch_queue: Fix filter limit check
https://notcve.org/view.php?id=CVE-2022-48847
In the Linux kernel, the following vulnerability has been resolved: watch_queue: Fix filter limit check In watch_queue_set_filter(), there are a couple of places where we check that the filter type value does not exceed what the type_filter bitmap can hold. One place calculates the number of bits by: if (tf[i].type >= sizeof(wfilter->type_filter) * 8) which is fine, but the second does: if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG) which is not. This can lead to a couple of out-of-bounds writes due to a too-large type: (1) __set_bit() on wfilter->type_filter (2) Writing more elements in wfilter->filters[] than we allocated. Fix this by just using the proper WATCH_TYPE__NR instead, which is the number of types we actually know about. The bug may cause an oops looking something like: BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740 Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611 ... Call Trace: <TASK> dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 ... kasan_report.cold+0x7f/0x11b ... watch_queue_set_filter+0x659/0x740 ... __x64_sys_ioctl+0x127/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Allocated by task 611: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 watch_queue_set_filter+0x23a/0x740 __x64_sys_ioctl+0x127/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff88800d2c66a0 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 28 bytes inside of 32-byte region [ffff88800d2c66a0, ffff88800d2c66c0) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: watch_queue: corrige la verificación del límite del filtro En watch_queue_set_filter(), hay un par de lugares donde verificamos que el valor del tipo de filtro no exceda lo que puede contener el mapa de bits type_filter. Un lugar calcula el número de bits mediante: if (tf[i].type >= sizeof(wfilter->type_filter) * 8) lo cual está bien, pero el segundo sí: if (tf[i].type >= sizeof( wfilter->type_filter) * BITS_PER_LONG) que no lo es. Esto puede provocar un par de escrituras fuera de los límites debido a un tipo demasiado grande: (1) __set_bit() en wfilter->type_filter (2) Escribir más elementos en wfilter->filters[] de los que asignamos. • https://git.kernel.org/stable/c/c73be61cede5882f9605a852414db559c0ebedfd https://git.kernel.org/stable/c/648895da69ced90ca770fd941c3d9479a9d72c16 https://git.kernel.org/stable/c/1b09f28f70a5046acd64138075ae3f095238b045 https://git.kernel.org/stable/c/b36588ebbcef74583824c08352e75838d6fb4ff2 https://git.kernel.org/stable/c/c993ee0f9f81caf5767a50d1faeba39a0dc82af2 • CWE-787: Out-of-bounds Write •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48846 – block: release rq qos structures for queue without disk
https://notcve.org/view.php?id=CVE-2022-48846
In the Linux kernel, the following vulnerability has been resolved: block: release rq qos structures for queue without disk blkcg_init_queue() may add rq qos structures to request queue, previously blk_cleanup_queue() calls rq_qos_exit() to release them, but commit 8e141f9eb803 ("block: drain file system I/O on del_gendisk") moves rq_qos_exit() into del_gendisk(), so memory leak is caused because queues may not have disk, such as un-present scsi luns, nvme admin queue, ... Fixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back. BTW, v5.18 won't need this patch any more since we move blkcg_init_queue()/blkcg_exit_queue() into disk allocation/release handler, and patches have been in for-5.18/block. • https://git.kernel.org/stable/c/8e141f9eb803e209714a80aa6ec073893f94c526 https://git.kernel.org/stable/c/d4ad8736ac982111bb0be8306bf19c8207f6600e https://git.kernel.org/stable/c/60c2c8e2ef3a3ec79de8cbc80a06ca0c21df8c29 https://git.kernel.org/stable/c/daaca3522a8e67c46e39ef09c1d542e866f85f3b •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48845 – MIPS: smp: fill in sibling and core maps earlier
https://notcve.org/view.php?id=CVE-2022-48845
In the Linux kernel, the following vulnerability has been resolved: MIPS: smp: fill in sibling and core maps earlier After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting the following: [ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi)) [ 0.048183] ------------[ cut here ]------------ [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [ 0.048220] Modules linked in: [ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000 [ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 [ 0.048389] ... [ 0.048396] Call Trace: [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80 [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c [ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240 [ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80 [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 [ 0.048523] [<8106593c>] start_secondary+0xbc/0x280 [ 0.048539] [ 0.048543] ---[ end trace 0000000000000000 ]--- [ 0.048636] Synchronize counters for CPU 1: done. ...for each but CPU 0/boot. Basic debug printks right before the mentioned line say: [ 0.048170] CPU: 1, smt_mask: So smt_mask, which is sibling mask obviously, is empty when entering the function. This is critical, as sched_core_cpu_starting() calculates core-scheduling parameters only once per CPU start, and it's crucial to have all the parameters filled in at that moment (at least it uses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on MIPS). A bit of debugging led me to that set_cpu_sibling_map() performing the actual map calculation, was being invocated after notify_cpu_start(), and exactly the latter function starts CPU HP callback round (sched_core_cpu_starting() is basically a CPU HP callback). While the flow is same on ARM64 (maps after the notifier, although before calling set_cpu_online()), x86 started calculating sibling maps earlier than starting the CPU HP callbacks in Linux 4.14 (see [0] for the reference). Neither me nor my brief tests couldn't find any potential caveats in calculating the maps right after performing delay calibration, but the WARN splat is now gone. The very same debug prints now yield exactly what I expected from them: [ 0.048433] CPU: 1, smt_mask: 0-1 [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef En el kernel de Linux, se resolvió la siguiente vulnerabilidad: MIPS: smp: complete los mapas de hermanos y núcleos antes Después de habilitar CONFIG_SCHED_CORE (aterrizado durante el ciclo 5.14), se inició interAptiv de 2 núcleos y 2 subprocesos por núcleo (controlado por CPS) emitiendo lo siguiente: [0.025698] La revisión de CPU1 es: 0001a120 (MIPS interAptiv (multi)) [0.048183] ------------[ cortar aquí ]------------ [0.048187] ADVERTENCIA: CPU: 1 PID: 0 en kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [0.048220] Módulos vinculados en: [0.048233] CPU: 1 PID: 0 Comm: swapper/1 No contaminado 5.17 .0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [0.048247] Pila: 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc 4 00000000 00000000 00000000 00000000 00000000 [ 0,048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 [ 0.048389] ... 0.048396] Seguimiento de llamadas: [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60 /0x80 [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c [ 0.048467] [<810bd418>] 198/0x240 [ 0.048483] [<810c6514>] sched_cpu_starting +0x14/0x80 [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 [ 0.048523] [<8106593c>] _secundario+0xbc/0x280 [ 0,048539] [ 0,048543] - --[ end trace 0000000000000000 ]--- [ 0.048636] Sincronizar contadores para CPU 1: hecho. ...para cada uno menos CPU 0/arranque. Las impresiones de depuración básicas justo antes de la línea mencionada dicen: [0.048170] CPU: 1, smt_mask: Entonces smt_mask, que obviamente es una máscara hermana, está vacía al ingresar a la función. Esto es crítico, ya que sched_core_cpu_starting() calcula los parámetros de programación central solo una vez por inicio de CPU, y es crucial tener todos los parámetros completados en ese momento (al menos usa cpu_smt_mask() que de hecho es `&cpu_sibling_map[cpu]` en MIPS). • https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98 https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565 https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7 https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7 https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239 https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe498 •