Page 15 of 5191 results (0.008 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: vsock: Update rx_bytes on read_skb() Make sure virtio_transport_inc_rx_pkt() and virtio_transport_dec_rx_pkt() calls are balanced (i.e. virtio_vsock_sock::rx_bytes doesn't lie) after vsock_transport::read_skb(). While here, also inform the peer that we've freed up space and it has more credit. Failing to update rx_bytes after packet is dequeued leads to a warning on SOCK_STREAM recv(): [ 233.396654] rx_queue is empty, but rx_bytes is non-zero [ 233.396702] WARNING: CPU: 11 PID: 40601 at net/vmw_vsock/virtio_transport_common.c:589 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vsock: Actualizar rx_bytes en read_skb() Asegúrese de que las llamadas a virtio_transport_inc_rx_pkt() y virtio_transport_dec_rx_pkt() estén equilibradas (es decir, virtio_vsock_sock::rx_bytes no mienta) después de vsock_transport::read_skb(). Mientras esté aquí, también informe al par que hemos liberado espacio y que tiene más crédito. Si no se actualiza rx_bytes después de que se saca el paquete de la cola, se genera una advertencia en SOCK_STREAM recv(): [ 233.396654] rx_queue está vacío, pero rx_bytes no es cero [ 233.396702] ADVERTENCIA: CPU: 11 PID: 40601 en net/vmw_vsock/virtio_transport_common.c:589 • https://git.kernel.org/stable/c/634f1a7110b439c65fd8a809171c1d2d28bcea6f https://git.kernel.org/stable/c/66cd51de31c682a311c2fa25c580b7ea45859dd9 https://git.kernel.org/stable/c/e5ca2b98090b4bb1c393088c724af6c37812a829 https://git.kernel.org/stable/c/3543152f2d330141d9394d28855cb90b860091d2 •

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

In the Linux kernel, the following vulnerability has been resolved: net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb->len being too long, add dev_kfree_skb() to fix it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sun3_82586: corrige una posible pérdida de memoria en sun3_82586_send_packet(). sun3_82586_send_packet() devuelve NETDEV_TX_OK sin liberar skb en caso de que skb->len sea demasiado largo, agrega dev_kfree_skb() para solucionarlo. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/137010d26dc5cd47cd62fef77cbe952d31951b7a https://git.kernel.org/stable/c/8d5b20fbc548650019afa96822b6a33ea4ec8aa5 https://git.kernel.org/stable/c/db755e55349045375c5c7036e8650afb3ff419d8 https://git.kernel.org/stable/c/9c6ce55e6f0bd1541f112833006b4052614c7d94 https://git.kernel.org/stable/c/1a17a4ac2d57102497fac53b53c666dba6a0c20d https://git.kernel.org/stable/c/6dc937a3086e344f965ca5c459f8f3eb6b68d890 https://git.kernel.org/stable/c/84f2bac74000dbb7a177d9b98a17031ec •

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

In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: be2net: corrige una posible pérdida de memoria en be_xmit(). Be_xmit() devuelve NETDEV_TX_OK sin liberar skb en caso de que be_xmit_enqueue() falle, agregue dev_kfree_skb_any() para solucionarlo. • https://git.kernel.org/stable/c/760c295e0e8d982917d004c9095cff61c0cbd803 https://git.kernel.org/stable/c/941026023c256939943a47d1c66671526befbb26 https://git.kernel.org/stable/c/6b7ce8ee01c33c380aaa5077ff25215492e7eb0e https://git.kernel.org/stable/c/77bc881d370e850b7f3cd2b5eae67d596b40efbc https://git.kernel.org/stable/c/919ab6e2370289a2748780f44a43333cd3878aa7 https://git.kernel.org/stable/c/4c5f170ef4f85731a4d43ad9a6ac51106c0946be https://git.kernel.org/stable/c/641c1beed52bf3c6deb0193fe4d38ec9ff75d2ae https://git.kernel.org/stable/c/e86a79b804e26e3b7f1e415b22a085c0b •

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

In the Linux kernel, the following vulnerability has been resolved: fsl/fman: Fix refcount handling of fman-related devices In mac_probe() there are multiple calls to of_find_device_by_node(), fman_bind() and fman_port_bind() which takes references to of_dev->dev. Not all references taken by these calls are released later on error path in mac_probe() and in mac_remove() which lead to reference leaks. Add references release. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fsl/fman: se ha corregido el manejo de refcount de dispositivos relacionados con fman En mac_probe() hay múltiples llamadas a of_find_device_by_node(), fman_bind() y fman_port_bind() que toman referencias a of_dev->dev. No todas las referencias tomadas por estas llamadas se liberan más tarde en la ruta de error en mac_probe() y en mac_remove(), lo que provoca fugas de referencias. Agregar referencias release. • https://git.kernel.org/stable/c/3933961682a30ae7d405cda344c040a129fea422 https://git.kernel.org/stable/c/5ed4334fc9512f934fe2ae9c4cf7f8142e451b8b https://git.kernel.org/stable/c/3c2a3619d565fe16bf59b0a047bab103a2ee4490 https://git.kernel.org/stable/c/1dec67e0d9fbb087c2ab17bf1bd17208231c3bb1 •

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

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overloading of MEM_UNINIT's meaning Lonial reported an issue in the BPF verifier where check_mem_size_reg() has the following code: if (!tnum_is_const(reg->var_off)) /* For unprivileged variable accesses, disable raw * mode so that the program is required to * initialize all the memory that the helper could * just partially fill up. */ meta = NULL; This means that writes are not checked when the register containing the size of the passed buffer has not a fixed size. Through this bug, a BPF program can write to a map which is marked as read-only, for example, .rodata global maps. The problem is that MEM_UNINIT's initial meaning that "the passed buffer to the BPF helper does not need to be initialized" which was added back in commit 435faee1aae9 ("bpf, verifier: add ARG_PTR_TO_RAW_STACK type") got overloaded over time with "the passed buffer is being written to". The problem however is that checks such as the above which were added later via 06c1c049721a ("bpf: allow helpers access to variable memory") set meta to NULL in order force the user to always initialize the passed buffer to the helper. Due to the current double meaning of MEM_UNINIT, this bypasses verifier write checks to the memory (not boundary checks though) and only assumes the latter memory is read instead. Fix this by reverting MEM_UNINIT back to its original meaning, and having MEM_WRITE as an annotation to BPF helpers in order to then trigger the BPF verifier checks for writing to memory. Some notes: check_arg_pair_ok() ensures that for ARG_CONST_SIZE{,_OR_ZERO} we can access fn->arg_type[arg - 1] since it must contain a preceding ARG_PTR_TO_MEM. For check_mem_reg() the meta argument can be removed altogether since we do check both BPF_READ and BPF_WRITE. • https://git.kernel.org/stable/c/7b3552d3f9f6897851fc453b5131a967167e43c2 https://git.kernel.org/stable/c/6099a6c8a749a5c8d5f8b4c4342022a92072a02b https://git.kernel.org/stable/c/bfe25df63048edd4ceaf78a2fc755d5e2befc978 https://git.kernel.org/stable/c/717c39718dbc4f7ebcbb7b625fb11851cd9007fe https://git.kernel.org/stable/c/5d0bba8232bf22ce13747cbfc8f696318ff01a50 https://git.kernel.org/stable/c/70674d11d14eeecad90be4b409a22b902112ba32 https://git.kernel.org/stable/c/a08d942ecbf46e23a192093f6983cb1d779f4fa8 https://git.kernel.org/stable/c/48068ccaea957469f1adf78dfd2c1c9a7 •