CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47369 – s390/qeth: fix NULL deref in qeth_clear_working_pool_list()
https://notcve.org/view.php?id=CVE-2021-47369
In the Linux kernel, the following vulnerability has been resolved: s390/qeth: fix NULL deref in qeth_clear_working_pool_list() When qeth_set_online() calls qeth_clear_working_pool_list() to roll back after an error exit from qeth_hardsetup_card(), we are at risk of accessing card->qdio.in_q before it was allocated by qeth_alloc_qdio_queues() via qeth_mpc_initialize(). qeth_clear_working_pool_list() then dereferences NULL, and by writing to queue->bufs[i].pool_entry scribbles all over the CPU's lowcore. Resulting in a crash when those lowcore areas are used next (eg. on the next machine-check interrupt). Such a scenario would typically happen when the device is first set online and its queues aren't allocated yet. An early IO error or certain misconfigs (eg. mismatched transport mode, bad portno) then cause us to error out from qeth_hardsetup_card() with card->qdio.in_q still being NULL. Fix it by checking the pointer for NULL before accessing it. Note that we also have (rare) paths inside qeth_mpc_initialize() where a configuration change can cause us to free the existing queues, expecting that subsequent code will allocate them again. If we then error out before that re-allocation happens, the same bug occurs. Root-caused-by: Heiko Carstens <hca@linux.ibm.com> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/qeth: corrige NULL deref en qeth_clear_working_pool_list(). Cuando qeth_set_online() llama a qeth_clear_working_pool_list() para retroceder después de una salida de error de qeth_hardsetup_card(), corremos el riesgo de acceder a la tarjeta ->qdio.in_q antes de que qeth_alloc_qdio_queues() lo asignara mediante qeth_mpc_initialize(). qeth_clear_working_pool_list() luego elimina la referencia a NULL y, al escribir en queue->bufs[i].pool_entry garabatea por todo el núcleo bajo de la CPU. Lo que resulta en un bloqueo cuando esas áreas de núcleo bajo se usan a continuación (por ejemplo, en la siguiente interrupción de verificación de la máquina). • https://git.kernel.org/stable/c/eff73e16ee116f6eafa2be48fab42659a27cb453 https://git.kernel.org/stable/c/b2400fe7e1011c5f3dc2268e8382082465b1c8a2 https://git.kernel.org/stable/c/22697ca855c06a4a1264d5651542b7d98870a8c4 https://git.kernel.org/stable/c/db94f89e1dadf693c15c2d60de0c34777cea5779 https://git.kernel.org/stable/c/9b00fb12cdc9d8d1c3ffe82a78e74738127803fc https://git.kernel.org/stable/c/248f064af222a1f97ee02c84a98013dfbccad386 • CWE-476: NULL Pointer Dereference •
CVSS: 8.1EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47368 – enetc: Fix illegal access when reading affinity_hint
https://notcve.org/view.php?id=CVE-2021-47368
In the Linux kernel, the following vulnerability has been resolved: enetc: Fix illegal access when reading affinity_hint irq_set_affinity_hit() stores a reference to the cpumask_t parameter in the irq descriptor, and that reference can be accessed later from irq_affinity_hint_proc_show(). Since the cpu_mask parameter passed to irq_set_affinity_hit() has only temporary storage (it's on the stack memory), later accesses to it are illegal. Thus reads from the corresponding procfs affinity_hint file can result in paging request oops. The issue is fixed by the get_cpu_mask() helper, which provides a permanent storage for the cpumask_t parameter. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: enetc: corrige el acceso ilegal al leer affinity_hint irq_set_affinity_hit() almacena una referencia al parámetro cpumask_t en el descriptor irq, y se puede acceder a esa referencia más tarde desde irq_affinity_hint_proc_show(). Dado que el parámetro cpu_mask pasado a irq_set_affinity_hit() solo tiene almacenamiento temporal (está en la memoria de la pila), los accesos posteriores a él son ilegales. • https://git.kernel.org/stable/c/d4fd0404c1c95b17880f254ebfee3485693fa8ba https://git.kernel.org/stable/c/4c4c3052911b577920353a7646e4883d5da40c28 https://git.kernel.org/stable/c/6c3f1b741c6c2914ea120e3a5790d3e900152f7b https://git.kernel.org/stable/c/6f329d9da2a5ae032fcde800a99b118124ed5270 https://git.kernel.org/stable/c/7237a494decfa17d0b9d0076e6cee3235719de90 • CWE-400: Uncontrolled Resource Consumption •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47366 – afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server
https://notcve.org/view.php?id=CVE-2021-47366
In the Linux kernel, the following vulnerability has been resolved: afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and Linux's afs client switches between them when talking to a non-YFS server if the read size, the file position or the sum of the two have the upper 32 bits set of the 64-bit value. This is a problem, however, since the file position and length fields of FS.FetchData are *signed* 32-bit values. Fix this by capturing the capability bits obtained from the fileserver when it's sent an FS.GetCapabilities RPC, rather than just discarding them, and then picking out the VICED_CAPABILITY_64BITFILES flag. This can then be used to decide whether to use FS.FetchData or FS.FetchData64 - and also FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to switch on the parameter values. This capabilities flag could also be used to limit the maximum size of the file, but all servers must be checked for that. Note that the issue does not exist with FS.StoreData - that uses *unsigned* 32-bit values. It's also not a problem with Auristor servers as its YFS.FetchData64 op uses unsigned 64-bit values. This can be tested by cloning a git repo through an OpenAFS client to an OpenAFS server and then doing "git status" on it from a Linux afs client[1]. Provided the clone has a pack file that's in the 2G-4G range, the git status will show errors like: error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index This can be observed in the server's FileLog with something like the following appearing: Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001 Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154 Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866 ... Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5 Note the file position of 18446744071815340032. This is the requested file position sign-extended. • https://git.kernel.org/stable/c/b9b1f8d5930a813879278d0cbfc8c658d6a038dc https://git.kernel.org/stable/c/e66fc460d6dcf85cf12288e133a081205aebcd97 https://git.kernel.org/stable/c/b537a3c21775075395af475dcc6ef212fcf29db8 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47364 – comedi: Fix memory leak in compat_insnlist()
https://notcve.org/view.php?id=CVE-2021-47364
In the Linux kernel, the following vulnerability has been resolved: comedi: Fix memory leak in compat_insnlist() `compat_insnlist()` handles the 32-bit version of the `COMEDI_INSNLIST` ioctl (whenwhen `CONFIG_COMPAT` is enabled). It allocates memory to temporarily hold an array of `struct comedi_insn` converted from the 32-bit version in user space. This memory is only being freed if there is a fault while filling the array, otherwise it is leaked. Add a call to `kfree()` to fix the leak. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: comedi: Reparar pérdida de memoria en compat_insnlist() `compat_insnlist()` maneja la versión de 32 bits del ioctl `COMEDI_INSNLIST` (cuando `CONFIG_COMPAT` está habilitado). Asigna memoria para almacenar temporalmente una matriz de `struct comedi_insn` convertida desde la versión de 32 bits en el espacio de usuario. • https://git.kernel.org/stable/c/b8d47d8813055ce38c0d2ad913d5462017e52692 https://git.kernel.org/stable/c/8d6a21e4cd6a319b0662cbe4ad6199e276ac776a https://git.kernel.org/stable/c/f217b6c1e28ed0b353634ce4d92a155b80bd1671 https://git.kernel.org/stable/c/bb509a6ffed2c8b0950f637ab5779aa818ed1596 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47362 – drm/amd/pm: Update intermediate power state for SI
https://notcve.org/view.php?id=CVE-2021-47362
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Update intermediate power state for SI Update the current state as boot state during dpm initialization. During the subsequent initialization, set_power_state gets called to transition to the final power state. set_power_state refers to values from the current state and without current state populated, it could result in NULL pointer dereference. For ex: on platforms where PCI speed change is supported through ACPI ATCS method, the link speed of current state needs to be queried before deciding on changing to final power state's link speed. The logic to query ATCS-support was broken on certain platforms. The issue became visible when broken ATCS-support logic got fixed with commit f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)"). Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/pm: Actualizar el estado de energía intermedio para SI. Actualiza el estado actual como estado de arranque durante la inicialización de dpm. Durante la inicialización posterior, se llama a set_power_state para realizar la transición al estado de energía final. set_power_state se refiere a valores del estado actual y sin el estado actual poblado, podría resultar en una desreferencia del puntero NULL. • https://git.kernel.org/stable/c/68d4fbe6220cd1f3d07cab0a4901e62f8c12cc68 https://git.kernel.org/stable/c/06a18e64256f7aecb5a27df02faa3568fcd3c105 https://git.kernel.org/stable/c/ab39d3cef526ba09c4c6923b4cd7e6ec1c5d4faa •