CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38560 – scsi: bfa: Ensure the copied buf is NUL terminated
https://notcve.org/view.php?id=CVE-2024-38560
In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Ensure the copied buf is NUL terminated Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: bfa: asegúrese de que el buf copiado tenga terminación NUL. Actualmente, asignamos un búfer del kernel de tamaño nbytes y copiamos nbytes del espacio de usuario a ese búfer. • https://git.kernel.org/stable/c/9f30b674759b9a2da25aefe25d885161d8a911cb https://git.kernel.org/stable/c/481fc0c8617304a67649027c4a44723a139a0462 https://git.kernel.org/stable/c/595a6b98deec01b6dbb20139f71edcd5fb760ec2 https://git.kernel.org/stable/c/00b425ff0891283207d7bad607a2412225274d7a https://git.kernel.org/stable/c/1708e3cf2488788cba5489e4f913d227de757baf https://git.kernel.org/stable/c/7d3e694c4fe30f3aba9cd5ae86fb947a54c3db5c https://git.kernel.org/stable/c/204714e68015d6946279719fd464ecaf57240f35 https://git.kernel.org/stable/c/7510fab46b1cbd1680e2a096e779aec33 •
CVSS: 4.4EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38559 – scsi: qedf: Ensure the copied buf is NUL terminated
https://notcve.org/view.php?id=CVE-2024-38559
In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Ensure the copied buf is NUL terminated Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qedf: asegúrese de que el buf copiado tenga terminación NUL. Actualmente, asignamos un búfer del kernel del tamaño de un conteo y copiamos el conteo desde el espacio de usuario a ese búfer. • https://git.kernel.org/stable/c/61d8658b4a435eac729966cc94cdda077a8df5cd https://git.kernel.org/stable/c/1f84a2744ad813be23fc4be99fb74bfb24aadb95 https://git.kernel.org/stable/c/a75001678e1d38aa607d5b898ec7ff8ed0700d59 https://git.kernel.org/stable/c/769b9fd2af02c069451fe9108dba73355d9a021c https://git.kernel.org/stable/c/dccd97b39ab2f2b1b9a47a1394647a4d65815255 https://git.kernel.org/stable/c/d93318f19d1e1a6d5f04f5d965eaa9055bb7c613 https://git.kernel.org/stable/c/563e609275927c0b75fbfd0d90441543aa7b5e0d https://git.kernel.org/stable/c/4907f5ad246fa9b51093ed7dfc7da9ebb • CWE-125: Out-of-bounds Read CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38558 – net: openvswitch: fix overwriting ct original tuple for ICMPv6
https://notcve.org/view.php?id=CVE-2024-38558
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix overwriting ct original tuple for ICMPv6 OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch: corrige la sobrescritura de la tupla original de ct para ICMPv6 OVS_PACKET_CMD_EXECUTE tiene 3 atributos principales: - OVS_PACKET_ATTR_KEY - Metadatos de paquetes en formato netlink. - OVS_PACKET_ATTR_PACKET: contenido del paquete binario. - OVS_PACKET_ATTR_ACTIONS: acciones a ejecutar en el paquete. • https://git.kernel.org/stable/c/9dd7f8907c3705dc7a7a375d1c6e30b06e6daffc https://git.kernel.org/stable/c/6a51ac92bf35d34b4996d6eb67e2fe469f573b11 https://git.kernel.org/stable/c/0b532f59437f688563e9c58bdc1436fefa46e3b5 https://git.kernel.org/stable/c/5ab6aecbede080b44b8e34720ab72050bf1e6982 https://git.kernel.org/stable/c/483eb70f441e2df66ade78aa7217e6e4caadfef3 https://git.kernel.org/stable/c/9ec8b0ccadb908d92f7ee211a4eff05fd932f3f6 https://git.kernel.org/stable/c/78741b4caae1e880368cb2f5110635f3ce45ecfd https://git.kernel.org/stable/c/431e9215576d7b728f3f53a704d237a52 • CWE-665: Improper Initialization •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38553 – net: fec: remove .ndo_poll_controller to avoid deadlocks
https://notcve.org/view.php?id=CVE-2024-38553
In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fec: elimine .ndo_poll_controller para evitar interbloqueos. • https://git.kernel.org/stable/c/7f5c6addcdc039c1a7c435857e6284ecac5d97c8 https://git.kernel.org/stable/c/d38625f71950e79e254515c5fc585552dad4b33e https://git.kernel.org/stable/c/accdd6b912c4219b8e056d1f1ad2e85bc66ee243 https://git.kernel.org/stable/c/87bcbc9b7e0b43a69d44efa5f32f11e32d08fa6f https://git.kernel.org/stable/c/c2e0c58b25a0a0c37ec643255558c5af4450c9f5 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38549 – drm/mediatek: Add 0 size check to mtk_drm_gem_obj
https://notcve.org/view.php?id=CVE-2024-38549
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Add 0 size check to mtk_drm_gem_obj Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: drm/mediatek: Agregar verificación de tamaño 0 a mtk_drm_gem_obj Agregar una verificación a mtk_drm_gem_init si intentamos asignar un objeto GEM de 0 bytes. Actualmente, no existe tal verificación y el kernel entrará en pánico si una aplicación de espacio de usuario intenta asignar un búfer GBM 0x0. Probado intentando asignar un búfer GBM 0x0 en un MT8188 y verificando que ahora devolvemos EINVAL. • https://git.kernel.org/stable/c/119f5173628aa7a0c3cf9db83460d40709e8241d https://git.kernel.org/stable/c/79078880795478d551a05acc41f957700030d364 https://git.kernel.org/stable/c/be34a1b351ea7faeb15dde8c44fe89de3980ae67 https://git.kernel.org/stable/c/d17b75ee9c2e44d3a3682c4ea5ab713ea6073350 https://git.kernel.org/stable/c/0e3b6f9123726858cac299e1654e3d20424cabe4 https://git.kernel.org/stable/c/13562c2d48c9ee330de1077d00146742be368f05 https://git.kernel.org/stable/c/af26ea99019caee1500bf7e60c861136c0bf8594 https://git.kernel.org/stable/c/9489951e3ae505534c4013db4e76b1b5a •