CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-35844 – f2fs: compress: fix reserve_cblocks counting error when out of space
https://notcve.org/view.php?id=CVE-2024-35844
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix reserve_cblocks counting error when out of space When a file only needs one direct_node, performing the following operations will cause the file to be unrepairable: unisoc # ./f2fs_io compress test.apk unisoc #df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.2M 100% /data unisoc # ./f2fs_io release_cblocks test.apk 924 unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 4.8M 100% /data unisoc # dd if=/dev/random of=file4 bs=1M count=3 3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 1.8M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device adb reboot unisoc # df -h | grep dm-48 /dev/block/dm-48 112G 112G 11M 100% /data unisoc # ./f2fs_io reserve_cblocks test.apk 0 This is because the file has only one direct_node. • https://git.kernel.org/stable/c/c75488fb4d82b697f381f855bf5b16779df440aa https://git.kernel.org/stable/c/fa3ac8b1a227d9b470b87972494293348b5839ee https://git.kernel.org/stable/c/889846dfc8ee2cf31148a44bfd2faeb2faadc685 https://git.kernel.org/stable/c/f0bf89e84c3afb79d7a3a9e4bc853ad6a3245c0a https://git.kernel.org/stable/c/569c198c9e2093fd29cc071856a4e548fda506bc https://git.kernel.org/stable/c/fc0aed88afbf6f606205129a7466eebdf528e3f3 https://git.kernel.org/stable/c/2f6d721e14b69d6e1251f69fa238b48e8374e25f http://www.openwall.com/lists/oss-security/2024/05/ •
CVSS: 6.8EPSS: 0%CPEs: 2EXPL: 0CVE-2024-35843 – iommu/vt-d: Use device rbtree in iopf reporting path
https://notcve.org/view.php?id=CVE-2024-35843
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Use device rbtree in iopf reporting path The existing I/O page fault handler currently locates the PCI device by calling pci_get_domain_bus_and_slot(). This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, replace it with device_rbtree_find() to search the device within the probed device rbtree. The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after device_rbtree_find() and before iopf_get_dev_fault_param(), which would cause a use-after-free problem. Add a mutex to synchronize the I/O page fault reporting path and the IOMMU release device path. This lock doesn't introduce any performance overhead, as the conflict between I/O page fault reporting and device releasing is very rare. • https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15 https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-35842 – ASoC: mediatek: sof-common: Add NULL check for normal_link string
https://notcve.org/view.php?id=CVE-2024-35842
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: sof-common: Add NULL check for normal_link string It's not granted that all entries of struct sof_conn_stream declare a `normal_link` (a non-SOF, direct link) string, and this is the case for SoCs that support only SOF paths (hence do not support both direct and SOF usecases). For example, in the case of MT8188 there is no normal_link string in any of the sof_conn_stream entries and there will be more drivers doing that in the future. To avoid possible NULL pointer KPs, add a NULL check for `normal_link`. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: mediatek: sof-common: Agregar verificación NULL para la cadena normal_link No se garantiza que todas las entradas de la estructura sof_conn_stream declaren una cadena `normal_link` (un enlace directo no SOF) , y este es el caso de los SoC que solo admiten rutas SOF (por lo tanto, no admiten casos de uso directos y SOF). Por ejemplo, en el caso de MT8188 no hay una cadena normal_link en ninguna de las entradas de sof_conn_stream y habrá más controladores que lo hagan en el futuro. Para evitar posibles KP de puntero NULL, agregue una verificación NULL para `normal_link`. • https://git.kernel.org/stable/c/0caf1120c58395108344d5df4e09359b67e95094 https://git.kernel.org/stable/c/cad471227a37c0c7c080bfc9ed01b53750e82afe https://git.kernel.org/stable/c/b1d3db6740d0997ffc6e5a0d96ef7cbd62b35fdd https://git.kernel.org/stable/c/cde6ca5872bf67744dffa875a7cb521ab007b7ef https://git.kernel.org/stable/c/e3b3ec967a7d93b9010a5af9a2394c8b5c8f31ed •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-35841 – net: tls, fix WARNIING in __sk_msg_free
https://notcve.org/view.php?id=CVE-2024-35841
In the Linux kernel, the following vulnerability has been resolved: net: tls, fix WARNIING in __sk_msg_free A splice with MSG_SPLICE_PAGES will cause tls code to use the tls_sw_sendmsg_splice path in the TLS sendmsg code to move the user provided pages from the msg into the msg_pl. This will loop over the msg until msg_pl is full, checked by sk_msg_full(msg_pl). The user can also set the MORE flag to hint stack to delay sending until receiving more pages and ideally a full buffer. If the user adds more pages to the msg than can fit in the msg_pl scatterlist (MAX_MSG_FRAGS) we should ignore the MORE flag and send the buffer anyways. What actually happens though is we abort the msg to msg_pl scatterlist setup and then because we forget to set 'full record' indicating we can no longer consume data without a send we fallthrough to the 'continue' path which will check if msg_data_left(msg) has more bytes to send and then attempts to fit them in the already full msg_pl. Then next iteration of sender doing send will encounter a full msg_pl and throw the warning in the syzbot report. To fix simply check if we have a full_record in splice code path and if not send the msg regardless of MORE flag. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: tls, corrija la ADVERTENCIA en __sk_msg_free Un empalme con MSG_SPLICE_PAGES hará que el código tls use la ruta tls_sw_sendmsg_splice en el código TLS sendmsg para mover las páginas proporcionadas por el usuario del msg al msg_pl . • https://git.kernel.org/stable/c/fe1e81d4f73b6cbaed4fcc476960d26770642842 https://git.kernel.org/stable/c/02e368eb1444a4af649b73cbe2edd51780511d86 https://git.kernel.org/stable/c/294e7ea85f34748f04e5f3f9dba6f6b911d31aa8 https://git.kernel.org/stable/c/dc9dfc8dc629e42f2234e3327b75324ffc752bc9 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-35840 – mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
https://notcve.org/view.php?id=CVE-2024-35840
In the Linux kernel, the following vulnerability has been resolved: mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect() subflow_finish_connect() uses four fields (backup, join_id, thmac, none) that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set in mptcp_parse_option() En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: use OPTION_MPTCP_MPJ_SYNACK en subflow_finish_connect() subflow_finish_connect() usa cuatro campos (backup, join_id, thmac, none) que pueden contener basura a menos que se haya configurado OPTION_MPTCP_MPJ_SYNACK en mptcp_parse_option() • https://git.kernel.org/stable/c/f296234c98a8fcec94eec80304a873f635d350ea https://git.kernel.org/stable/c/413b913507326972135d2977975dbff8b7f2c453 https://git.kernel.org/stable/c/51e4cb032d49ce094605f27e45eabebc0408893c https://git.kernel.org/stable/c/ad3e8f5c3d5c53841046ef7a947c04ad45a20721 https://git.kernel.org/stable/c/76e8de7273a22a00d27e9b8b7d4d043d6433416a https://git.kernel.org/stable/c/be1d9d9d38da922bd4beeec5b6dd821ff5a1dfeb •