CVSS: 7.7EPSS: 0%CPEs: 9EXPL: 0CVE-2024-36016 – tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
https://notcve.org/view.php?id=CVE-2024-36016
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: tty: n_gsm: corrige posibles fuera de los límites en gsm0_receive() Suponiendo lo siguiente: - el lado A configura el n_gsm en modo de opción básica - el lado B envía el encabezado de un mensaje básico trama del modo de opción con longitud de datos 1 - el lado A cambia al modo de opción avanzada - el lado B envía 2 bytes de datos que exceden gsm->len Motivo: gsm->len no se usa en el modo de opción avanzada. - el lado A cambia al modo de opción básica - el lado B continúa enviando hasta que gsm0_receive() escribe más allá de gsm->buf Motivo: Ni gsm->state ni gsm->len se han restablecido después de la reconfiguración. Solucione este problema cambiando gsm->count a gsm->len comparación de igual a menor que. También agregue comprobaciones de límite superior contra la constante MAX_MRU en gsm0_receive() y gsm1_receive() para proteger contra la corrupción de memoria de gsm->len y gsm->mru. • https://git.kernel.org/stable/c/e1eaea46bb4020b38a141b84f88565d4603f8dd0 https://git.kernel.org/stable/c/9513d4148950b05bc99fa7314dc883cc0e1605e5 https://git.kernel.org/stable/c/b229bc6c6ea9fe459fc3fa94fd0a27a2f32aca56 https://git.kernel.org/stable/c/0fb736c9931e02dbc7d9a75044c8e1c039e50f04 https://git.kernel.org/stable/c/4c267110fc110390704cc065edb9817fdd10ff54 https://git.kernel.org/stable/c/46f52c89a7e7d2691b97a9728e4591d071ca8abc https://git.kernel.org/stable/c/774d83b008eccb1c48c14dc5486e7aa255731350 https://git.kernel.org/stable/c/f126ce7305fe88f49cdabc6db4168b931 • CWE-125: Out-of-bounds Read CWE-787: Out-of-bounds Write •
CVSS: 5.9EPSS: 0%CPEs: 11EXPL: 0CVE-2023-52881 – tcp: do not accept ACK of bytes we never sent
https://notcve.org/view.php?id=CVE-2023-52881
In the Linux kernel, the following vulnerability has been resolved: tcp: do not accept ACK of bytes we never sent This patch is based on a detailed report and ideas from Yepeng Pan and Christian Rossow. ACK seq validation is currently following RFC 5961 5.2 guidelines: The ACK value is considered acceptable only if it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <= SND.NXT). All incoming segments whose ACK value doesn't satisfy the above condition MUST be discarded and an ACK sent back. It needs to be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a duplicate (SEG.ACK < SND.UNA), it can be ignored. If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return". The "ignored" above implies that the processing of the incoming data segment continues, which means the ACK value is treated as acceptable. • https://git.kernel.org/stable/c/354e4aa391ed50a4d827ff6fc11e0667d0859b25 https://git.kernel.org/stable/c/8d15569e14cfcf9151e9e3b4c0cb98369943a2bb https://git.kernel.org/stable/c/e252bbd8c87b95e9cecdc01350fbb0b46a0f9bf1 https://git.kernel.org/stable/c/2ee4432e82437a7c051c254b065fbf5d4581e1a3 https://git.kernel.org/stable/c/69eae75ca5255e876628ac5cee9eaab31f644b57 https://git.kernel.org/stable/c/458f07ffeccd17f99942311e09ef574ddf4a414a https://git.kernel.org/stable/c/7ffff0cc929fdfc62a74b384c4903d6496c910f0 https://git.kernel.org/stable/c/b17a886ed29f3b70b78ccf632dad03e0c •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52880 – tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
https://notcve.org/view.php?id=CVE-2023-52880
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc Any unprivileged user can attach N_GSM0710 ldisc, but it requires CAP_NET_ADMIN to create a GSM network anyway. Require initial namespace CAP_NET_ADMIN to do that. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tty: n_gsm: requiere CAP_NET_ADMIN para adjuntar el ldisc N_GSM0710. Cualquier usuario sin privilegios puede adjuntar el ldisc N_GSM0710, pero de todos modos requiere CAP_NET_ADMIN para crear una red GSM. Requiere el espacio de nombres inicial CAP_NET_ADMIN para hacer eso. • https://git.kernel.org/stable/c/7d303dee473ba3529d75b63491e9963342107bed https://git.kernel.org/stable/c/7a529c9023a197ab3bf09bb95df32a3813f7ba58 https://git.kernel.org/stable/c/ada28eb4b9561aab93942f3224a2e41d76fe57fa https://git.kernel.org/stable/c/2d154a54c58f9c8375bfbea9f7e51ba3bfb2e43a https://git.kernel.org/stable/c/2b85977977cbd120591b23c2450e90a5806a7167 https://git.kernel.org/stable/c/67c37756898a5a6b2941a13ae7260c89b54e0d88 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html https://lists.debian.org/debian-lts-announce/2024&# • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47571 – staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect()
https://notcve.org/view.php?id=CVE-2021-47571
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect() The free_rtllib() function frees the "dev" pointer so there is use after free on the next line. Re-arrange things to avoid that. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: staging: rtl8192e: Corrige el use after free en _rtl92e_pci_disconnect() La función free_rtllib() libera el puntero "dev" para que haya use after free en la siguiente línea. Reorganice las cosas para evitar eso. • https://git.kernel.org/stable/c/66898177e7e5486dc77a4ba742efa4e2e9e900a4 https://git.kernel.org/stable/c/d43aecb694b10db9a4228ce2d38b5ae8de374443 https://git.kernel.org/stable/c/9186680382934b0e7529d3d70dcc0a21d087683b https://git.kernel.org/stable/c/c0ef0e75a858cbd8618b473f22fbca36106dcf82 https://git.kernel.org/stable/c/bca19bb2dc2d89ce60c4a4a6e59609d4cf2e13ef https://git.kernel.org/stable/c/2e1ec01af2c7139c6a600bbfaea1a018b35094b6 https://git.kernel.org/stable/c/8d0163cec7de995f9eb9c3128c83fb84f0cb1c64 https://git.kernel.org/stable/c/e27ee2f607fe6a9b923ef1fc65461c061 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47566 – proc/vmcore: fix clearing user buffer by properly using clear_user()
https://notcve.org/view.php?id=CVE-2021-47566
In the Linux kernel, the following vulnerability has been resolved: proc/vmcore: fix clearing user buffer by properly using clear_user() To clear a user buffer we cannot simply use memset, we have to use clear_user(). With a virtio-mem device that registers a vmcore_cb and has some logically unplugged memory inside an added Linux memory block, I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[465]: saving vmcore-dmesg.txt complete kdump[467]: saving vmcore BUG: unable to handle page fault for address: 00007f2374e01000 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86 Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81 RSP: 0018:ffffc9000073be08 EFLAGS: 00010212 RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000 RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008 RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Call Trace: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 ksys_read+0x4f/0xc0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access Prevention (SMAP)", which is used to detect wrong access from the kernel to user buffers like this: SMAP triggers a permissions violation on wrong access. In the x86-64 variant of clear_user(), SMAP is properly handled via clac()+stac(). To fix, properly use clear_user() when we're dealing with a user buffer. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: proc/vmcore: corrige el borrado del búfer del usuario usando correctamente clear_user() Para borrar un búfer de usuario no podemos simplemente usar memset, tenemos que usar clear_user(). Con un dispositivo virtio-mem que registra un vmcore_cb y tiene algo de memoria lógicamente desconectada dentro de un bloque de memoria de Linux agregado, puedo desencadenar fácilmente un ERROR copiando el vmcore a través de "cp": systemd[1]: Iniciando el servicio Kdump Vmcore Save. . kdump[420]: Kdump está utilizando el nivel de registro predeterminado (3). kdump[453]: guardar en /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: guardar vmcore-dmesg.txt en /sysroot/var/crash/127.0 .0.1-2021-11-11-14:59:22/ kdump[465]: guardar vmcore-dmesg.txt completo kdump[467]: guardar vmcore ERROR: no se puede manejar el error de página para la dirección: 00007f2374e01000 #PF: escritura del supervisor acceso en modo kernel #PF: error_code(0x0003) - violación de permisos PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Ups: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: p No contaminado 5.15.0+ # 6 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 01/04/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/ 0x86 Código: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 C7 44 05 F8 00 00 00 00 48 83 E7 F81 RSP: 0018: FFFFFC9000073BE08 EFLAGS: 00010212 RAX: 00000000000000001000 RBX: 000000002FD000 RCX: 00007F2374E RSI: 000000000000FFFFDFFF RDI: 00007F2374E01008 RBP: 000000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: 88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2 : 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Seguimiento de llamadas: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 do_syscall_64+0x3b/0x90 Entry_SYSCALL_64_after_hwframe+0x44/0xae Algunas CPU x86-64 tienen una función de CPU llamada "Prevención de acceso en modo supervisor (SMAP)", que se utiliza para detectar accesos incorrectos desde el kernel a los búferes de usuario como este: SMAP desencadena una violación de permisos en caso de acceso incorrecto. • https://git.kernel.org/stable/c/997c136f518c5debd63847e78e2a8694f56dcf90 https://git.kernel.org/stable/c/a9e164bd160be8cbee1df70acb379129e3cd2e7c https://git.kernel.org/stable/c/33a7d698f30fa0b99d50569e9909d3baa65d8f6a https://git.kernel.org/stable/c/99d348b82bcb36171f24411d3f1a15706a2a937a https://git.kernel.org/stable/c/9ef384ed300d1bcfb23d0ab0b487d544444d4b52 https://git.kernel.org/stable/c/fd7974c547abfb03072a4ee706d3a6f182266f89 https://git.kernel.org/stable/c/a8a917058faf4abaec9fb614bb6d5f8fe3529ec6 https://git.kernel.org/stable/c/7b3a34f08d11e7f05cd00b8e09adaa151 • CWE-501: Trust Boundary Violation •