Page 135 of 2776 results (0.011 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix memleak in ttm_transfered_destroy We need to cleanup the fences for ghost objects as well. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214029 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214447 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/ttm: corrige memleak en ttm_transfered_destroy También necesitamos limpiar las barreras para detectar objetos fantasma. Error: https://bugzilla.kernel.org/show_bug.cgi?id=214029 Error: https://bugzilla.kernel.org/show_bug.cgi? • https://git.kernel.org/stable/c/bd99782f3ca491879e8524c89b1c0f40071903bd https://git.kernel.org/stable/c/960b1fdfc39aba8f41e9e27b2de0c925c74182d9 https://git.kernel.org/stable/c/c21b4002214c1c7e7b627b9b53375612f7aab6db https://git.kernel.org/stable/c/bbc920fb320f1c241cc34ac85edaa0058922246a https://git.kernel.org/stable/c/132a3d998d6753047f22152731fba2b0d6b463dd https://git.kernel.org/stable/c/0db55f9a1bafbe3dac750ea669de9134922389b5 •

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

In the Linux kernel, the following vulnerability has been resolved: IB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields Overflowing either addrlimit or bytes_togo can allow userspace to trigger a buffer overflow of kernel memory. Check for overflows in all the places doing math on user controlled buffers. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: IB/qib: Protege contra el desbordamiento del búfer en los campos de struct qib_user_sdma_pkt. El desbordamiento de addrlimit o bytes_togo puede permitir que el espacio de usuario desencadene un desbordamiento del búfer de la memoria del kernel. Compruebe si hay desbordamientos en todos los lugares que realizan cálculos en búferes controlados por el usuario. • https://git.kernel.org/stable/c/f931551bafe1f10ded7f5282e2aa162c267a2e5d https://git.kernel.org/stable/c/bda41654b6e0c125a624ca35d6d20beb8015b5d0 https://git.kernel.org/stable/c/3f57c3f67fd93b4da86aeffea1ca32c484d054ad https://git.kernel.org/stable/c/60833707b968d5ae02a75edb7886dcd4a957cf0d https://git.kernel.org/stable/c/73d2892148aa4397a885b4f4afcfc5b27a325c42 https://git.kernel.org/stable/c/0f8cdfff06829a0b0348b6debc29ff6a61967724 https://git.kernel.org/stable/c/c3e17e58f571f34c51aeb17274ed02c2ed5cf780 https://git.kernel.org/stable/c/0d4395477741608d123dad51def9fe50b •

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

In the Linux kernel, the following vulnerability has been resolved: net: batman-adv: fix error handling Syzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was in wrong error handling in batadv_mesh_init(). Before this patch batadv_mesh_init() was calling batadv_mesh_free() in case of any batadv_*_init() calls failure. This approach may work well, when there is some kind of indicator, which can tell which parts of batadv are initialized; but there isn't any. All written above lead to cleaning up uninitialized fields. Even if we hide ODEBUG warning by initializing bat_priv->nc.work, syzbot was able to hit GPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1] To fix these bugs we can unwind batadv_*_init() calls one by one. It is good approach for 2 reasons: 1) It fixes bugs on error handling path 2) It improves the performance, since we won't call unneeded batadv_*_free() functions. So, this patch makes all batadv_*_init() clean up all allocated memory before returning with an error to no call correspoing batadv_*_free() and open-codes batadv_mesh_free() with proper order to avoid touching uninitialized fields. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: batman-adv: corrección de manejo de errores Syzbot informó advertencia ODEBUG en batadv_nc_mesh_free(). • https://git.kernel.org/stable/c/c6c8fea29769d998d94fcec9b9f14d4b52b349d3 https://git.kernel.org/stable/c/0c6b199f09be489c48622537a550787fc80aea73 https://git.kernel.org/stable/c/07533f1a673ce1126d0a72ef1e4b5eaaa3dd6d20 https://git.kernel.org/stable/c/e50f957652190b5a88a8ebce7e5ab14ebd0d3f00 https://git.kernel.org/stable/c/fbf150b16a3635634b7dfb7f229d8fcd643c6c51 https://git.kernel.org/stable/c/6422e8471890273994fe8cc6d452b0dcd2c9483e https://git.kernel.org/stable/c/b0a2cd38553c77928ef1646ed1518486b1e70ae8 https://git.kernel.org/stable/c/a8f7359259dd5923adc6129284fdad12f • CWE-544: Missing Standardized Error Handling Mechanism •

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

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Put LLD module refcnt after SCSI device is released SCSI host release is triggered when SCSI device is freed. We have to make sure that the low-level device driver module won't be unloaded before SCSI host instance is released because shost->hostt is required in the release handler. Make sure to put LLD module refcnt after SCSI device is released. Fixes a kernel panic of 'BUG: unable to handle page fault for address' reported by Changhui and Yi. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: colocar el módulo LLD refcnt después de liberar el dispositivo SCSI. La liberación del host SCSI se activa cuando se libera el dispositivo SCSI. Tenemos que asegurarnos de que el módulo del controlador de dispositivo de bajo nivel no se descargue antes de que se lance la instancia del host SCSI porque se requiere shost->hostt en el controlador de lanzamiento. • https://git.kernel.org/stable/c/1105573d964f7b78734348466b01f5f6ba8a1813 https://git.kernel.org/stable/c/8e4814a461787e15a31d322d9efbe0d4f6822428 https://git.kernel.org/stable/c/61a0faa89f21861d1f8d059123b5c285a5d9ffee https://git.kernel.org/stable/c/c2df161f69fb1c67f63adbd193368b47f511edc0 https://git.kernel.org/stable/c/1ce287eff9f23181d5644db787f472463a61f68b https://git.kernel.org/stable/c/7b57c38d12aed1b5d92f74748bed25e0d041729f https://git.kernel.org/stable/c/f30822c0b4c35ec86187ab055263943dc71a6836 https://git.kernel.org/stable/c/f2b85040acec9a928b4eb1b57a989324e •

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

In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix use-after-free in rtl8712_dl_fw Syzbot reported use-after-free in rtl8712_dl_fw(). The problem was in race condition between r871xu_dev_remove() ->ndo_open() callback. It's easy to see from crash log, that driver accesses released firmware in ->ndo_open() callback. It may happen, since driver was releasing firmware _before_ unregistering netdev. Fix it by moving unregister_netdev() before cleaning up resources. Call Trace: ... rtl871x_open_fw drivers/staging/rtl8712/hal_init.c:83 [inline] rtl8712_dl_fw+0xd95/0xe10 drivers/staging/rtl8712/hal_init.c:170 rtl8712_hal_init drivers/staging/rtl8712/hal_init.c:330 [inline] rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394 netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380 __dev_open+0x2bc/0x4d0 net/core/dev.c:1484 Freed by task 1306: ... release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053 r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599 usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: staging: rtl8712: corrige el use-after-free en rtl8712_dl_fw Syzbot informó el use-after-free en rtl8712_dl_fw(). El problema estaba en la condición de ejecución entre la devolución de llamada r871xu_dev_remove() ->ndo_open(). • https://git.kernel.org/stable/c/8c213fa59199f9673d66970d6940fa093186642f https://git.kernel.org/stable/c/bc5d453eab4506cb52397db8830d1070904265a4 https://git.kernel.org/stable/c/c430094541a80575259a94ff879063ef01473506 https://git.kernel.org/stable/c/befd23bd3b17f1a3f9c943a8580b47444c7c63ed https://git.kernel.org/stable/c/a65c9afe9f2f55b7a7fb4a25ab654cd4139683a4 https://git.kernel.org/stable/c/c052cc1a069c3e575619cf64ec427eb41176ca70 •