Page 202 of 2900 results (0.007 seconds)

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: usb: udc: remove warning when queue disabled ep It is possible trigger below warning message from mass storage function, WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104 pc : usb_ep_queue+0x7c/0x104 lr : fsg_main_thread+0x494/0x1b3c Root cause is mass storage function try to queue request from main thread, but other thread may already disable ep when function disable. As there is no function failure in the driver, in order to avoid effort to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: udc: elimina la advertencia cuando la cola está deshabilitada ep Es posible que se active el siguiente mensaje de advertencia desde la función de almacenamiento masivo, ADVERTENCIA: CPU: 6 PID: 3839 en drivers/usb/gadget/udc /core.c:294 usb_ep_queue+0x7c/0x104 pc: usb_ep_queue+0x7c/0x104 lr: fsg_main_thread+0x494/0x1b3c La causa principal es que la función de almacenamiento masivo intenta poner en cola la solicitud desde el hilo principal, pero es posible que otro hilo ya deshabilite ep cuando la función se deshabilita. Como no hay ningún fallo de función en el controlador, para evitar el esfuerzo de corregir la advertencia, cambie WARN_ON_ONCE() en usb_ep_queue() a pr_debug(). • https://git.kernel.org/stable/c/2b002c308e184feeaeb72987bca3f1b11e5f70b8 https://git.kernel.org/stable/c/68d951880d0c52c7f13dcefb5501b69b8605ce8c https://git.kernel.org/stable/c/3e944ddc17c042945d983e006df7860687a8849a https://git.kernel.org/stable/c/df5cbb908f1687e8ab97e222a16b7890d5501acf https://git.kernel.org/stable/c/f74c5e0b54b02706d9a862ac6cddade30ac86bcf https://git.kernel.org/stable/c/99731076722eb7ed26b0c87c879da7bb71d24290 https://git.kernel.org/stable/c/36177c2595df12225b95ce74eb1ac77b43d5a58c https://git.kernel.org/stable/c/30511676eb54d480d014352bf784f0257 •

CVSS: 7.5EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ubifs: Set page uptodate in the correct place Page cache reads are lockless, so setting the freshly allocated page uptodate before we've overwritten it with the data it's supposed to have in it will allow a simultaneous reader to see old data. Move the call to SetPageUptodate into ubifs_write_end(), which is after we copied the new data into the page. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: establece la actualización de la página en el lugar correcto. Las lecturas de la caché de la página no tienen bloqueo, por lo que configurar la actualización de la página recién asignada antes de que la sobrescribamos con los datos que se supone que debe contener lo hará. permitir que un lector simultáneo vea datos antiguos. Mueva la llamada a SetPageUptodate a ubifs_write_end(), que es después de que copiamos los nuevos datos en la página. • https://git.kernel.org/stable/c/1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d https://git.kernel.org/stable/c/4aa554832b9dc9e66249df75b8f447d87853e12e https://git.kernel.org/stable/c/778c6ad40256f1c03244fc06d7cdf71f6b5e7310 https://git.kernel.org/stable/c/8f599ab6fabbca4c741107eade70722a98adfd9f https://git.kernel.org/stable/c/f19b1023a3758f40791ec166038d6411c8894ae3 https://git.kernel.org/stable/c/142d87c958d9454c3cffa625fab56f3016e8f9f3 https://git.kernel.org/stable/c/fc99f4e2d2f1ce766c14e98463c2839194ae964f https://git.kernel.org/stable/c/4b7c4fc60d6a46350fbe54f5dc937aeaa • CWE-772: Missing Release of Resource after Effective Lifetime •

CVSS: -EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Define the __io_aw() hook as mmiowb() Commit fb24ea52f78e0d595852e ("drivers: Remove explicit invocations of mmiowb()") remove all mmiowb() in drivers, but it says: "NOTE: mmiowb() has only ever guaranteed ordering in conjunction with spin_unlock(). However, pairing each mmiowb() removal in this patch with the corresponding call to spin_unlock() is not at all trivial, so there is a small chance that this change may regress any drivers incorrectly relying on mmiowb() to order MMIO writes between CPUs using lock-free synchronisation." The mmio in radeon_ring_commit() is protected by a mutex rather than a spinlock, but in the mutex fastpath it behaves similar to spinlock. We can add mmiowb() calls in the radeon driver but the maintainer says he doesn't like such a workaround, and radeon is not the only example of mutex protected mmio. So we should extend the mmiowb tracking system from spinlock to mutex, and maybe other locking primitives. This is not easy and error prone, so we solve it in the architectural code, by simply defining the __io_aw() hook as mmiowb(). • https://git.kernel.org/stable/c/97cd43ba824aec764f5ea2790d0c0a318f885167 https://git.kernel.org/stable/c/d7d7c6cdea875be3b241d7d39873bb431db7154d https://git.kernel.org/stable/c/0b61a7dc6712b78799b3949997e8a5e94db5c4b0 https://git.kernel.org/stable/c/9adec248bba33b1503252caf8e59d81febfc5ceb https://git.kernel.org/stable/c/9c68ece8b2a5c5ff9b2fcaea923dd73efeb174cd •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgpu_ttm_backend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: amdgpu_ttm_gart_bind establece el indicador vinculado a gtt. De lo contrario, después de que se libera GTT bo, se libera el espacio GTT y gart, pero amdgpu_ttm_backend_unbind no borrará la entrada de la tabla de páginas de gart y dejará una asignación válida. entrada que apunta a la página del sistema obsoleto. Luego, si la GPU accede a la dirección de Gart por error, leerá un valor indefinido en lugar de un error de página, lo que será más difícil de depurar y reproducir el problema real. • https://git.kernel.org/stable/c/5d5f1a7f3b1039925f79c7894f153c2a905201fb https://git.kernel.org/stable/c/589c414138a1bed98e652c905937d8f790804efe https://git.kernel.org/stable/c/6fcd12cb90888ef2d8af8d4c04e913252eee4ef3 https://git.kernel.org/stable/c/e8d27caef2c829a306e1f762fb95f06e8ec676f6 https://git.kernel.org/stable/c/5cdce3dda3b3dacde902f63a8ee72c2b7f91912d https://git.kernel.org/stable/c/6c6064cbe58b43533e3451ad6a8ba9736c109ac3 •

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. [arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcmfmac: corregido el error de use after free en brcmf_cfg80211_detach Este es el parche candidato de CVE-2023-47233: https://nvd.nist.gov/vuln/detail /CVE-2023-47233 En el controlador brcm80211, comienza con la siguiente cadena de invocación para iniciar un trabajador de tiempo de espera: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg ->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); Si desconectamos el USB mediante hotplug, llamará a brcmf_usb_disconnect para realizar la limpieza. La cadena de invocación es: brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); Mientras que el activador de tiempo de espera aún puede estar ejecutándose. Esto provocará un error de use after free en cfg en brcmf_cfg80211_escan_timeout_worker. • https://git.kernel.org/stable/c/e756af5b30b008f6ffcfebf8ad0b477f6f225b62 https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169 https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1 https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731 https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744 https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9 •