Page 427 of 5394 results (0.023 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: sch_htb: fix refcount leak in htb_parent_to_leaf_offload The commit ae81feb7338c ("sch_htb: fix null pointer dereference on a null new_q") fixes a NULL pointer dereference bug, but it is not correct. Because htb_graft_helper properly handles the case when new_q is NULL, and after the previous patch by skipping this call which creates an inconsistency : dev_queue->qdisc will still point to the old qdisc, but cl->parent->leaf.q will point to the new one (which will be noop_qdisc, because new_q was NULL). The code is based on an assumption that these two pointers are the same, so it can lead to refcount leaks. The correct fix is to add a NULL pointer check to protect qdisc_refcount_inc inside htb_parent_to_leaf_offload. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sch_htb: corrige la fuga de recuento en htb_parent_to_leaf_offload el commit ae81feb7338c ("sch_htb: corrige la desreferencia del puntero nulo en un new_q nulo") corrige un error de desreferencia del puntero NULL, pero no es correcto. Debido a que htb_graft_helper maneja adecuadamente el caso cuando new_q es NULL, y después del parche anterior al omitir esta llamada, se crea una inconsistencia: dev_queue->qdisc seguirá apuntando a la qdisc anterior, pero cl->parent->leaf.q apuntará a el nuevo (que será noop_qdisc, porque new_q era NULL). El código se basa en la suposición de que estos dos indicadores son iguales, por lo que puede provocar fugas de recuento. La solución correcta es agregar una verificación de puntero NULL para proteger qdisc_refcount_inc dentro de htb_parent_to_leaf_offload. • https://git.kernel.org/stable/c/ae81feb7338c89cee4e6aa0424bdab2ce2b52da2 https://git.kernel.org/stable/c/2411c02d03892a5057499f8102d0cc1e0f852416 https://git.kernel.org/stable/c/944d671d5faa0d78980a3da5c0f04960ef1ad893 •

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

In the Linux kernel, the following vulnerability has been resolved: io_uring: fix link timeout refs WARNING: CPU: 0 PID: 10242 at lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 RIP: 0010:refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] io_put_req fs/io_uring.c:2140 [inline] io_queue_linked_timeout fs/io_uring.c:6300 [inline] __io_queue_sqe+0xbef/0xec0 fs/io_uring.c:6354 io_submit_sqe fs/io_uring.c:6534 [inline] io_submit_sqes+0x2bbd/0x7c50 fs/io_uring.c:6660 __do_sys_io_uring_enter fs/io_uring.c:9240 [inline] __se_sys_io_uring_enter+0x256/0x1d60 fs/io_uring.c:9182 io_link_timeout_fn() should put only one reference of the linked timeout request, however in case of racing with the master request's completion first io_req_complete() puts one and then io_put_req_deferred() is called. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrige las referencias de tiempo de espera del enlace ADVERTENCIA: CPU: 0 PID: 10242 en lib/refcount.c:28 refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 RIP: 0010: refcount_warn_saturate+0x15b/0x1a0 lib/refcount.c:28 Seguimiento de llamadas: __refcount_sub_and_test include/linux/refcount.h:283 [en línea] __refcount_dec_and_test include/linux/refcount.h:315 [en línea] refcount_dec_and_test include/linux/refcount.h: 333 [en línea] io_put_req fs/io_uring.c:2140 [en línea] io_queue_linked_timeout fs/io_uring.c:6300 [en línea] __io_queue_sqe+0xbef/0xec0 fs/io_uring.c:6354 io_submit_sqe fs/io_uring.c:6534 [en línea] io_submit _sqes +0x2bbd/0x7c50 fs/io_uring.c:6660 __do_sys_io_uring_enter fs/io_uring.c:9240 [en línea] __se_sys_io_uring_enter+0x256/0x1d60 fs/io_uring.c:9182 io_link_timeout_fn() debe poner solo una referencia de la solicitud de tiempo de espera vinculada, sin embargo en En el caso de competir con la finalización de la solicitud maestra, primero io_req_complete() coloca uno y luego se llama a io_put_req_deferred(). • https://git.kernel.org/stable/c/1c20e9040f49687ba2ccc2ffd4411351a6c2ebff https://git.kernel.org/stable/c/9ae1f8dd372e0e4c020b345cf9e09f519265e981 https://git.kernel.org/stable/c/567c81912cec641db75ac6cb64c63f8367c97d19 https://git.kernel.org/stable/c/0b2a990e5d2f76d020cb840c456e6ec5f0c27530 https://git.kernel.org/stable/c/6f5d7a45f58d3abe3a936de1441b8d6318f978ff https://git.kernel.org/stable/c/876808dba2ff7509bdd7f230c4f374a0caf4f410 https://git.kernel.org/stable/c/ff4a96ba5c8f9b266706280ff8021d2ef3f17e86 https://git.kernel.org/stable/c/a298232ee6b9a1d5d732aa497ff8be0d4 •

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

In the Linux kernel, the following vulnerability has been resolved: io_uring: fix ltout double free on completion race Always remove linked timeout on io_link_timeout_fn() from the master request link list, otherwise we may get use-after-free when first io_link_timeout_fn() puts linked timeout in the fail path, and then will be found and put on master's free. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrige la doble liberación de ltout al finalizar la ejecución. Elimina siempre el tiempo de espera vinculado en io_link_timeout_fn() de la lista de vínculos de solicitud maestra; de lo contrario, es posible que obtengamos use-after-free la primera vez que io_link_timeout_fn() coloca el tiempo de espera vinculado en la ruta de falla, y luego será encontrado y puesto en master gratis. • https://git.kernel.org/stable/c/90cd7e424969d29aff653333b4dcb4e2e199d791 https://git.kernel.org/stable/c/1f64f5e903b9d1d157875721e02adadc9d6f0a5d https://git.kernel.org/stable/c/447c19f3b5074409c794b350b10306e1da1ef4ba •

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

In the Linux kernel, the following vulnerability has been resolved: net: caif: fix memory leak in caif_device_notify In case of caif_enroll_dev() fail, allocated link_support won't be assigned to the corresponding structure. So simply free allocated pointer in case of error En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: caif: corrige la pérdida de memoria en caif_device_notify En caso de que falle caif_enroll_dev(), el link_support asignado no se asignará a la estructura correspondiente. Así que simplemente libera el puntero asignado en caso de error. • https://git.kernel.org/stable/c/7c18d2205ea76eef9674e59e1ecae4f332a53e9e https://git.kernel.org/stable/c/b042e2b2039565eb8f0eb51c14fbe1ef463c8cd8 https://git.kernel.org/stable/c/9348c1f10932f13b299cbc8b1bd5f780751fae49 https://git.kernel.org/stable/c/4bca2034b41c15b62d47a19158bb76235fd4455d https://git.kernel.org/stable/c/3be863c11cab725add9fef4237ed4e232c3fc3bb https://git.kernel.org/stable/c/f52f4fd67264c70cd0b4ba326962ebe12d9cba94 https://git.kernel.org/stable/c/af2806345a37313f01b1c9f15e046745b8ee2daa https://git.kernel.org/stable/c/6a0e317f61094d377335547e015dd2ff1 •

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

In the Linux kernel, the following vulnerability has been resolved: net: caif: fix memory leak in cfusbl_device_notify In case of caif_enroll_dev() fail, allocated link_support won't be assigned to the corresponding structure. So simply free allocated pointer in case of error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: caif: corrige la pérdida de memoria en cfusbl_device_notify En caso de que falle caif_enroll_dev(), el link_support asignado no se asignará a la estructura correspondiente. Así que simplemente libera el puntero asignado en caso de error. • https://git.kernel.org/stable/c/7ad65bf68d705b445ef10b77ab50dab22be185ee https://git.kernel.org/stable/c/cc302e30a504e6b60a9ac8df7988646f46cd0294 https://git.kernel.org/stable/c/81afc61cb6e2b553f2c5f992fa79e0ae73857141 https://git.kernel.org/stable/c/e8b37f5009ea7095529790f022859711e6939c76 https://git.kernel.org/stable/c/9ea0ab48e755d8f29fe89eb235fb86176fdb597f https://git.kernel.org/stable/c/4d94f530cd24c85aede6e72b8923f371b45d6886 https://git.kernel.org/stable/c/46403c1f80b0d3f937ff9c4f5edc63bb64bc5051 https://git.kernel.org/stable/c/dde8686985ec24d6b00487080a906609b •