Page 371 of 2243 results (0.011 seconds)

CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: EDAC/thunderx: Fix possible out-of-bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ... Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: EDAC/thunderx: corrige un posible acceso a cadenas fuera de los límites Al habilitar -Wstringop-overflow globalmente se expone una advertencia para un error común en el uso de strncat(): drivers/edac/ thunderx_edac.c: En la función 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' el límite especificado 1024 es igual al tamaño de destino [-Werror=stringop-overflow=] 1136 | strncat(msj, otro, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msj, otro, OCX_MESSAGE_SIZE); ... 1150 | strncat(msj, otro, OCX_MESSAGE_SIZE); ... Aparentemente, el autor de este controlador esperaba que strncat() se comportara de la manera que lo hace strlcat(), que utiliza el tamaño del búfer de destino como tercer argumento en lugar de la longitud del búfer de origen. El resultado es que no se comprueba el tamaño del búfer asignado. Cámbielo a strlcat(). • https://git.kernel.org/stable/c/41003396f932d7f027725c7acebb6a7caa41dc3e https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601 https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6 https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21 https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398 https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057 https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc4 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer CWE-805: Buffer Access with Incorrect Length Value •

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? • https://git.kernel.org/stable/c/f88814cc2578c121e6edef686365036db72af0ed https://git.kernel.org/stable/c/552952e51fad35670459674bcb8a03bd96fe4646 https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8 https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826 https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737 https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548 https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e627 • CWE-476: NULL Pointer Dereference •

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: bpf: fix check for attempt to corrupt spilled pointer When register is spilled onto a stack as a 1/2/4-byte register, we set slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it, depending on actual spill size). So to check if some stack slot has spilled register we need to consult slot_type[7], not slot_type[0]. To avoid the need to remember and double-check this in the future, just use is_spilled_reg() helper. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: revisión de corrección para intentar dañar el puntero derramado Cuando el registro se derrama en una pila como un registro de 1/2/4 bytes, configuramos slot_type[BPF_REG_SIZE - 1] (más potencialmente algunos más debajo de él, dependiendo del tamaño real del derrame). Entonces, para verificar si alguna ranura de la pila se ha desbordado, debemos consultar slot_type[7], no slot_type[0]. Para evitar la necesidad de recordar y volver a verificar esto en el futuro, simplemente use el asistente is_spilled_reg(). • https://git.kernel.org/stable/c/cdd73a5ed0840da88a3b9ad353f568e6f156d417 https://git.kernel.org/stable/c/07c286c10a9cedbd71f20269ff3a4e73d9aab2fe https://git.kernel.org/stable/c/27113c59b6d0a587b29ae72d4ff3f832f58b0651 https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104 https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174 https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a •

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length needs to be aligned with block size Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling bio_integrity_free. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bloque: agregar verifique que la longitud de la partición debe estar alineada con el tamaño del bloque Antes de llamar a agregar partición o cambiar el tamaño de la partición, no se verifica si la longitud está alineada con el tamaño del bloque lógico. Si el tamaño del bloque lógico del disco es mayor que 512 bytes, entonces el tamaño de la partición tal vez no sea el múltiplo del tamaño del bloque lógico, y cuando se lea el último sector, bio_truncate() ajustará el tamaño de la biografía, lo que resultará en un error de E/S si el tamaño del comando de lectura es menor que el tamaño del bloque lógico. Si se admiten datos de integridad, esto también resultará en una desreferencia del puntero nulo al llamar a bio_integrity_free. A flaw was found in the Linux kernel's block subsystem, where a NULL pointer dereference occurs if partitions are created or resized with a size that is not a multiple of the logical block size. • https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62 https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503 https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8 https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8 https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5 https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://access.redhat.com/security/cve/CVE-2023 • CWE-476: NULL Pointer Dereference •

CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed Returning an error code from .remove() makes the driver core emit the little helpful error message: remove callback returned a non-zero value. This will be ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case. Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a use-after-free. So replace the error return (and with it the little helpful error message) by a more useful error message and continue to cleanup. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: 8250: omap: no omita la liberación de recursos si pm_runtime_resume_and_get() falla. • https://git.kernel.org/stable/c/2d66412563ef8953e2bac2d98d2d832b3f3f49cd https://git.kernel.org/stable/c/d833cba201adf9237168e19f0d76e4d7aa69f303 https://git.kernel.org/stable/c/e0db709a58bdeb8966890882261a3f8438c5c9b7 https://git.kernel.org/stable/c/e3f0c638f428fd66b5871154b62706772045f91a https://git.kernel.org/stable/c/02eed6390dbe61115f3e3f63829c95c611aee67b https://git.kernel.org/stable/c/b502fb43f7fb55aaf07f6092ab44657595214b93 https://git.kernel.org/stable/c/bc57f3ef8a9eb0180606696f586a6dcfaa175ed0 https://git.kernel.org/stable/c/828cd829483f0cda920710997aed79130 • CWE-416: Use After Free •