CVSS: 4.4EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47373 – irqchip/gic-v3-its: Fix potential VPE leak on error
https://notcve.org/view.php?id=CVE-2021-47373
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Fix potential VPE leak on error In its_vpe_irq_domain_alloc, when its_vpe_init() returns an error, there is an off-by-one in the number of VPEs to be freed. Fix it by simply passing the number of VPEs allocated, which is the index of the loop iterating over the VPEs. [maz: fixed commit message] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: irqchip/gic-v3-its: soluciona una posible fuga de VPE en caso de error. En its_vpe_irq_domain_alloc, cuando its_vpe_init() devuelve un error, hay un error de uno en uno en el número de VPE. para ser liberado. Solucionelo simplemente pasando el número de VPE asignados, que es el índice del bucle que se itera sobre los VPE. [maz: mensaje de confirmación fijo] • https://git.kernel.org/stable/c/7d75bbb4bc1ad90386776459d37e4ddfe605671e https://git.kernel.org/stable/c/7d39992d45acd6f2d6b2f62389c55b61fb3d486b https://git.kernel.org/stable/c/5701e8bff314c155e7afdc467b1e0389d86853d0 https://git.kernel.org/stable/c/42d3711c23781045e7a5cd28536c774b9a66d20b https://git.kernel.org/stable/c/568662e37f927e3dc3e475f3ff7cf4ab7719c5e7 https://git.kernel.org/stable/c/e0c1c2e5da19685a20557a50f10c6aa4fa26aa84 https://git.kernel.org/stable/c/280bef512933b2dda01d681d8cbe499b98fc5bdd https://access.redhat.com/security/cve/CVE-2021-47373 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47372 – net: macb: fix use after free on rmmod
https://notcve.org/view.php?id=CVE-2021-47372
In the Linux kernel, the following vulnerability has been resolved: net: macb: fix use after free on rmmod plat_dev->dev->platform_data is released by platform_device_unregister(), use of pclk and hclk is a use-after-free. Since device unregister won't need a clk device we adjust the function call sequence to fix this issue. [ 31.261225] BUG: KASAN: use-after-free in macb_remove+0x77/0xc6 [macb_pci] [ 31.275563] Freed by task 306: [ 30.276782] platform_device_release+0x25/0x80 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: macb: corrige el use after free en rmmod plat_dev->dev->platform_data es publicado por platform_device_unregister(), el uso de pclk y hclk es un use after free. Dado que la cancelación del registro del dispositivo no necesitará un dispositivo clk, ajustamos la secuencia de llamada a la función para solucionar este problema. [31.261225] ERROR: KASAN: use after free en macb_remove+0x77/0xc6 [macb_pci] [31.275563] Liberado por la tarea 306: [30.276782] platform_device_release+0x25/0x80 • https://git.kernel.org/stable/c/a7d521cc726f30b8e679a6f36d04b18a8ab3c536 https://git.kernel.org/stable/c/46670fb832ee80943715df618632ca13c2e96f2b https://git.kernel.org/stable/c/1da750d1e2140ef43d64d17f301ff6f41b45541e https://git.kernel.org/stable/c/7721221e87d25c9840d9ca6b986dbdc410d5ce2b https://git.kernel.org/stable/c/4ad6f2d23b0f6ac0d3e5f3102a4256d1c86c90f5 https://git.kernel.org/stable/c/d82d5303c4c539db86588ffb5dc5b26c3f1513e8 •
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 •