CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36978 – net: sched: sch_multiq: fix possible OOB write in multiq_tune()
https://notcve.org/view.php?id=CVE-2024-36978
In the Linux kernel, the following vulnerability has been resolved: net: sched: sch_multiq: fix possible OOB write in multiq_tune() q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: sched: sch_multiq: corrige posible escritura OOB en multiq_tune() q->bands se asignarán a qopt->bands para ejecutar la lógica de código posterior después de kmalloc. Por lo tanto, las antiguas q->bands no deberían usarse en kmalloc. De lo contrario, se producirá una escritura fuera de los límites. • https://git.kernel.org/stable/c/c2999f7fb05b87da4060e38150c70fa46794d82b https://git.kernel.org/stable/c/d5d9d241786f49ae7cbc08e7fc95a115e9d80f3d https://git.kernel.org/stable/c/52b1aa07cda6a199cd6754d3798c7759023bc70f https://git.kernel.org/stable/c/598572c64287aee0b75bbba4e2881496878860f3 https://git.kernel.org/stable/c/0f208fad86631e005754606c3ec80c0d44a11882 https://git.kernel.org/stable/c/54c2c171c11a798fe887b3ff72922aa9d1411c1e https://git.kernel.org/stable/c/d6fb5110e8722bc00748f22caeb650fe4672f129 https://git.kernel.org/stable/c/affc18fdc694190ca7575b9a86632a73b •
CVSS: 4.7EPSS: 0%CPEs: 5EXPL: 0CVE-2024-36977 – usb: dwc3: Wait unconditionally after issuing EndXfer command
https://notcve.org/view.php?id=CVE-2024-36977
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: Wait unconditionally after issuing EndXfer command Currently all controller IP/revisions except DWC3_usb3 >= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWC_usb3 controller revisions >= 3.10a supports GUCTL2[14: Rst_actbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed. Consider a case where an IN request was queued, and parallelly soft_disconnect was called (due to ffs_epfile_release). This eventually calls stop_active_transfer with IOC cleared, hence send_gadget_ep_cmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions >= 310a, we don't forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn't complete by this time, it leads to SMMU faults since the controller would still be accessing those requests. Fix this by ensuring ENDXFER completion by adding 1ms delay in __dwc3_stop_active_transfer() unconditionally. • https://git.kernel.org/stable/c/b353eb6dc285a0775a447f53e5b2a50bf3f9684f https://git.kernel.org/stable/c/341eb08dbca9eae05308c442fbfab1813a44c97a https://git.kernel.org/stable/c/ec96bcf5f96a7a5c556b0e881ac3e5c3924d542c https://git.kernel.org/stable/c/4a387e032909c6dc2b479452c5bbe9a252057925 https://git.kernel.org/stable/c/1ba145f05b5c8f0b1a947a0633b5edff5dd1f1c5 https://git.kernel.org/stable/c/1d26ba0944d398f88aaf997bda3544646cf21945 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36975 – KEYS: trusted: Do not use WARN when encode fails
https://notcve.org/view.php?id=CVE-2024-36975
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Do not use WARN when encode fails When asn1_encode_sequence() fails, WARN is not the correct solution. 1. asn1_encode_sequence() is not an internal function (located in lib/asn1_encode.c). 2. Location is known, which makes the stack trace useless. 3. Results a crash if panic_on_warn is set. It is also noteworthy that the use of WARN is undocumented, and it should be avoided unless there is a carefully considered rationale to use it. Replace WARN with pr_err, and print the return value instead, which is only useful piece of information. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LLAVES: confiable: no usar WARN cuando falla la codificación Cuando falla asn1_encode_sequence(), WARN no es la solución correcta. 1. asn1_encode_sequence() no es una función interna (ubicada en lib/asn1_encode.c). 2. Se conoce la ubicación, lo que hace que el seguimiento de la pila sea inútil. 3. • https://git.kernel.org/stable/c/f2219745250f388edacabe6cca73654131c67d0a https://git.kernel.org/stable/c/96f650995c70237b061b497c66755e32908f8972 https://git.kernel.org/stable/c/681935009fec3fc22af97ee312d4a24ccf3cf087 https://git.kernel.org/stable/c/1c652e1e10676f942149052d9329b8bf2703529a https://git.kernel.org/stable/c/d32c6e09f7c4bec3ebc4941323f0aa6366bc1487 https://git.kernel.org/stable/c/ff91cc12faf798f573dab2abc976c1d5b1862fea https://git.kernel.org/stable/c/050bf3c793a07f96bd1e2fd62e1447f731ed733b •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-36974 – net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP
https://notcve.org/view.php?id=CVE-2024-36974
In the Linux kernel, the following vulnerability has been resolved: net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided, taprio_parse_mqprio_opt() must validate it, or userspace can inject arbitrary data to the kernel, the second time taprio_change() is called. First call (with valid attributes) sets dev->num_tc to a non zero value. Second call (with arbitrary mqprio attributes) returns early from taprio_parse_mqprio_opt() and bad things can happen. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: taprio: validar siempre TCA_TAPRIO_ATTR_PRIOMAP Si se ha proporcionado un atributo TCA_TAPRIO_ATTR_PRIOMAP, taprio_parse_mqprio_opt() debe validarlo, o el espacio de usuario puede inyectar datos arbitrarios al kernel, la segunda vez taprio_change () se llama. La primera llamada (con atributos válidos) establece dev->num_tc en un valor distinto de cero. La segunda llamada (con atributos mqprio arbitrarios) regresa temprano desde taprio_parse_mqprio_opt() y pueden suceder cosas malas. • https://git.kernel.org/stable/c/a3d43c0d56f1b94e74963a2fbadfb70126d92213 https://git.kernel.org/stable/c/c6041e7124464ce7e896ee3f912897ce88a0c4ec https://git.kernel.org/stable/c/6db4af09987cc5d5f0136bd46148b0e0460dae5b https://git.kernel.org/stable/c/d3dde4c217f0c31ab0621912e682b57e677dd923 https://git.kernel.org/stable/c/0bf6cc96612bd396048f57d63f1ad454a846e39c https://git.kernel.org/stable/c/724050ae4b76e4fae05a923cb54101d792cf4404 https://git.kernel.org/stable/c/c37a27a35eadb59286c9092c49c241270c802ae2 https://git.kernel.org/stable/c/f921a58ae20852d188f70842431ce6519 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36973 – misc: microchip: pci1xxxx: fix double free in the error handling of gp_aux_bus_probe()
https://notcve.org/view.php?id=CVE-2024-36973
In the Linux kernel, the following vulnerability has been resolved: misc: microchip: pci1xxxx: fix double free in the error handling of gp_aux_bus_probe() When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function gp_auxiliary_device_release() calls ida_free() and kfree(aux_device_wrapper) to free memory. We should't call them again in the error handling path. Fix this by skipping the redundant cleanup functions. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc: microchip: pci1xxxx: corrige double free en el manejo de errores de gp_aux_bus_probe() Cuando auxiliar_device_add() devuelve error y luego llama a auxiliar_device_uninit(), la función de devolución de llamada gp_auxiliary_device_release() llama a ida_free( ) y kfree(aux_device_wrapper) para liberar memoria. No deberíamos volver a llamarlos en la ruta de manejo de errores. Solucione este problema omitiendo las funciones de limpieza redundantes. • https://git.kernel.org/stable/c/393fc2f5948fd340d016a9557eea6e1ac2f6c60c https://git.kernel.org/stable/c/34ae447b138680b5ed3660f7d935ff3faf88ba1a https://git.kernel.org/stable/c/86c9713602f786f441630c4ee02891987f8618b9 https://git.kernel.org/stable/c/1efe551982297924d05a367aa2b6ec3d275d5742 https://git.kernel.org/stable/c/086c6cbcc563c81d55257f9b27e14faf1d0963d3 •