Page 391 of 2457 results (0.018 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: fs/mount_setattr: always cleanup mount_kattr Make sure that finish_mount_kattr() is called after mount_kattr was succesfully built in both the success and failure case to prevent leaking any references we took when we built it. We returned early if path lookup failed thereby risking to leak an additional reference we took when building mount_kattr when an idmapped mount was requested. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/mount_setattr: limpiar siempre mount_kattr. Asegúrese de que se llame a finish_mount_kattr() después de que mount_kattr se haya compilado con éxito tanto en el caso de éxito como en el de fracaso para evitar que se filtren las referencias que tomamos cuando lo compilamos. Regresamos temprano si falla la búsqueda de ruta, por lo que corremos el riesgo de filtrar una referencia adicional que tomamos al compilar mount_kattr cuando se solicitó un montaje con idmapped. • https://git.kernel.org/stable/c/9caccd41541a6f7d6279928d9f971f6642c361af https://git.kernel.org/stable/c/47b5d0a7532d39e42a938f81e3904268145c341d https://git.kernel.org/stable/c/012e332286e2bb9f6ac77d195f17e74b2963d663 • CWE-668: Exposure of Resource to Wrong Sphere •

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

In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests hfi1 user SDMA request processing has two bugs that can cause data corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail iovec does not run up to the page boundary for the buffer pointed to by that iovec.a Here are the specific bugs: 1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past iovec->iov.iov_len and are thus not intended to be in the packet. 2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will contain the wrong data from the iovec pages. This has not been an issue with SDMA packets from hfi1 Verbs or PSM2 because they only produce iovecs that end short of PAGE_SIZE as the tail iovec of an SDMA request. Fixing these bugs exposes other bugs with the SDMA pin cache (struct mmu_rb_handler) that get in way of supporting user SDMA requests with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So this commit fixes those issues as well. Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec payload user SDMA requests can hit: 1. Overlapping memory ranges in mmu_rb_handler will result in duplicate pinnings. 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and (3). 3. • https://git.kernel.org/stable/c/7724105686e718ac476a6ad3304fea2fbcfcffde https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678 https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844 https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80 https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127 •

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

In the Linux kernel, the following vulnerability has been resolved: i2c: Fix a potential use after free Free the adap structure only after we are done using it. This patch just moves the put_device() down a bit to avoid the use after free. [wsa: added comment to the code, added Fixes tag] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: corrige un use after free que libera la estructura adap solo después de que hayamos terminado de usarla. Este parche simplemente mueve put_device() un poco hacia abajo para evitar el use after free. [wsa: comentario agregado al código, etiqueta de correcciones agregada] An out-of-bounds (OOB) memory access flaw was found in the i2c driver module in the Linux kernel. • https://git.kernel.org/stable/c/611e12ea0f121a31d9e9c4ce2a18a77abc2f28d6 https://git.kernel.org/stable/c/e6412ba3b6508bdf9c074d310bf4144afa6aec1a https://git.kernel.org/stable/c/23a191b132cd87f746c62f3dc27da33683d85829 https://git.kernel.org/stable/c/871a1e94929a27bf6e2cd99523865c840bbc2d87 https://git.kernel.org/stable/c/81cb31756888bb062e92d2dca21cd629d77a46a9 https://git.kernel.org/stable/c/35927d7509ab9bf41896b7e44f639504eae08af7 https://git.kernel.org/stable/c/e8e1a046cf87c8b1363e5de835114f2779e2aaf4 https://git.kernel.org/stable/c/12b0606000d0828630c033bf0c74c7484 • CWE-416: Use After Free •

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

In the Linux kernel, the following vulnerability has been resolved: binder: signal epoll threads of self-work In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption. Within binder, a thread may initiate a command via BINDER_WRITE_READ without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards. It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as the thread has pending work. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: carpeta: señal de epoll de subprocesos de autotrabajo En el modo (e)poll, los subprocesos a menudo dependen de eventos de E/S para determinar cuándo los datos están listos para el consumo. • https://git.kernel.org/stable/c/457b9a6f09f011ebcb9b52cc203a6331a6fc2de7 https://git.kernel.org/stable/c/dd64bb8329ce0ea27bc557e4160c2688835402ac https://git.kernel.org/stable/c/42beab162dcee1e691ee4934292d51581c29df61 https://git.kernel.org/stable/c/a423042052ec2bdbf1e552e621e6a768922363cc https://git.kernel.org/stable/c/82722b453dc2f967b172603e389ee7dc1b3137cc https://git.kernel.org/stable/c/90e09c016d72b91e76de25f71c7b93d94cc3c769 https://git.kernel.org/stable/c/a7ae586f6f6024f490b8546c8c84670f96bb9b68 https://git.kernel.org/stable/c/93b372c39c40cbf179e56621e6bc48240 •

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

In the Linux kernel, the following vulnerability has been resolved: moxart: fix potential use-after-free on remove path It was reported that the mmc host structure could be accessed after it was freed in moxart_remove(), so fix this by saving the base register of the device and using it instead of the pointer dereference. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: moxart: corrige el posible use-after-free en la ruta de eliminación. Se informó que se podía acceder a la estructura del host mmc después de que se liberó en moxart_remove(), así que solucione este problema guardando el registro base del dispositivo y usarlo en lugar de la desreferencia del puntero. • https://git.kernel.org/stable/c/f5dc193167591e88797262ec78515a0cbe79ff5f https://git.kernel.org/stable/c/e6f580d0b3349646d4ee1ce0057eb273e8fb7e2e https://git.kernel.org/stable/c/9c25d5ff1856b91bd4365e813f566cb59aaa9552 https://git.kernel.org/stable/c/3a0a7ec5574b510b067cfc734b8bdb6564b31d4e https://git.kernel.org/stable/c/be93028d306dac9f5b59ebebd9ec7abcfc69c156 https://git.kernel.org/stable/c/af0e6c49438b1596e4be8a267d218a0c88a42323 https://git.kernel.org/stable/c/7f901d53f120d1921f84f7b9b118e87e94b403c5 https://git.kernel.org/stable/c/bd2db32e7c3e35bd4d9b8bbff689434a5 • CWE-416: Use After Free •