Page 385 of 3378 results (0.014 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: cpumap: Zero-initialise xdp_rxq_info struct before running XDP program When running an XDP program that is attached to a cpumap entry, we don't initialise the xdp_rxq_info data structure being used in the xdp_buff that backs the XDP program invocation. Tobias noticed that this leads to random values being returned as the xdp_md->rx_queue_index value for XDP programs running in a cpumap. This means we're basically returning the contents of the uninitialised memory, which is bad. Fix this by zero-initialising the rxq data structure before running the XDP program. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpumap: Inicializa a cero la estructura xdp_rxq_info antes de ejecutar el programa XDP Cuando ejecutas un programa XDP que está adjunto a una entrada de cpumap, no inicializamos la estructura de datos xdp_rxq_info que se utiliza en xdp_buff que respalda la invocación del programa XDP. Tobias notó que esto lleva a que se devuelvan valores aleatorios como el valor xdp_md->rx_queue_index para programas XDP que se ejecutan en un cpumap. • https://git.kernel.org/stable/c/9216477449f33cdbc9c9a99d49f500b7fbb81702 https://git.kernel.org/stable/c/5f4e51abfbe6eb444fa91906a5cd083044278297 https://git.kernel.org/stable/c/f0363af9619c77730764f10360e36c6445c12f7b https://git.kernel.org/stable/c/3420b3ff1ff489c177ea1cb7bd9fbbc4e9a0be95 https://git.kernel.org/stable/c/f562e4c4aab00986dde3093c4be919c3f2b85a4a https://git.kernel.org/stable/c/eaa7cb836659ced2d9f814ac32aa3ec193803ed6 https://git.kernel.org/stable/c/2487007aa3b9fafbd2cb14068f49791ce1d7ede5 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-908: Use of Uninitialized Resource •

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

In the Linux kernel, the following vulnerability has been resolved: netrom: Fix data-races around sysctl_net_busy_read We need to protect the reader reading the sysctl value because the value can be changed concurrently. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netrom: corrige carreras de datos alrededor de sysctl_net_busy_read Necesitamos proteger al lector que lee el valor de sysctl porque el valor se puede cambiar simultáneamente. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/d623fd5298d95b65d27ef5a618ebf39541074856 https://git.kernel.org/stable/c/f9055fa2b2931261d5f89948ee5bc315b6a22d4a https://git.kernel.org/stable/c/bbf950a6e96a91cf8cf0c71117b94ed3fafc9dd3 https://git.kernel.org/stable/c/0866afaff19d8460308b022345ed116a12b1d0e1 https://git.kernel.org/stable/c/43464808669ba9d23996f0b6d875450191687caf https://git.kernel.org/stable/c/34cab94f7473e7b09f5205d4583fb5096cb63b5b https://git.kernel.org/stable/c/16d71319e29d5825ab53f263b59fdd8dc •

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

In the Linux kernel, the following vulnerability has been resolved: net: mctp: take ownership of skb in mctp_local_output Currently, mctp_local_output only takes ownership of skb on success, and we may leak an skb if mctp_local_output fails in specific states; the skb ownership isn't transferred until the actual output routing occurs. Instead, make mctp_local_output free the skb on all error paths up to the route action, so it always consumes the passed skb. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: mctp: toma posesión de skb en mctp_local_output Actualmente, mctp_local_output solo toma propiedad de skb en caso de éxito, y podemos filtrar un fallo skb si mctp_local_output en estados específicos; la propiedad del skb no se transfiere hasta que se produce el enrutamiento de salida real. En su lugar, haga que mctp_local_output libere el skb en todas las rutas de error hasta la acción de ruta, de modo que siempre consuma el skb pasado. • https://git.kernel.org/stable/c/833ef3b91de692ef33b800bca6b1569c39dece74 https://git.kernel.org/stable/c/a3c8fa54e904b0ddb52a08cc2d8ac239054f61fd https://git.kernel.org/stable/c/cbebc55ceacef1fc0651e80e0103cc184552fc68 https://git.kernel.org/stable/c/a639441c880ac479495e5ab37e3c29f21ae5771b https://git.kernel.org/stable/c/3773d65ae5154ed7df404b050fd7387a36ab5ef3 •

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

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix potential "struct net" leak in inet6_rtm_getaddr() It seems that if userspace provides a correct IFA_TARGET_NETNSID value but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr() returns -EINVAL with an elevated "struct net" refcount. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipv6: soluciona una posible fuga de "struct net" en inet6_rtm_getaddr() Parece que si el espacio de usuario proporciona un valor IFA_TARGET_NETNSID correcto pero no los atributos IFA_ADDRESS e IFA_LOCAL, inet6_rtm_getaddr() devuelve -EINVAL con un recuento elevado de "estructura neta". • https://git.kernel.org/stable/c/6ecf4c37eb3e89b0832c9616089a5cdca3747da7 https://git.kernel.org/stable/c/9d4ffb5b9d879a75e4f7460e8b10e756b4dfb132 https://git.kernel.org/stable/c/810fa7d5e5202fcfb22720304b755f1bdfd4c174 https://git.kernel.org/stable/c/8a54834c03c30e549c33d5da0975f3e1454ec906 https://git.kernel.org/stable/c/1b0998fdd85776775d975d0024bca227597e836a https://git.kernel.org/stable/c/44112bc5c74e64f28f5a9127dc34066c7a09bd0f https://git.kernel.org/stable/c/33a1b6bfef6def2068c8703403759024ce17053e https://git.kernel.org/stable/c/10bfd453da64a057bcfd1a49fb6b271c4 •

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

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST If we received HCI_EV_IO_CAPA_REQUEST while HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote does support SSP since otherwise this event shouldn't be generated. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: hci_event: Corrige el manejo de HCI_EV_IO_CAPA_REQUEST Si recibimos HCI_EV_IO_CAPA_REQUEST mientras HCI_OP_READ_REMOTE_EXT_FEATURES aún no se ha respondido, supongamos que el control remoto admite SSP ya que, de lo contrario, este evento no debería generarse. • https://git.kernel.org/stable/c/ccb8618c972f941ebc6b2b9db491025b3369efcb https://git.kernel.org/stable/c/1769ac55dbf3114d5bf79f11bd5dca80ee263f9c https://git.kernel.org/stable/c/40a33a129d99639921ce00d274cca44ba282f1ac https://git.kernel.org/stable/c/1ef071526848cc3109ade63268854cd7c20ece0c https://git.kernel.org/stable/c/25e5d2883002e235f3378b8592aad14aeeef898c https://git.kernel.org/stable/c/c7f59461f5a78994613afc112cdd73688aef9076 https://git.kernel.org/stable/c/2c7f9fda663a1b31a61744ffc456bdb89c4efc7f https://git.kernel.org/stable/c/746dbb0fc6392eca23de27f8aa9d13979 •