Page 240 of 1471 results (0.008 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: dbg-tlv: ensure NUL termination The iwl_fw_ini_debug_info_tlv is used as a string, so we must ensure the string is terminated correctly before using it. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: dbg-tlv: asegurar terminación NUL. El iwl_fw_ini_debug_info_tlv se usa como una cadena, por lo que debemos asegurarnos de que la cadena termine correctamente antes de usarla. • https://git.kernel.org/stable/c/a9248de42464e546b624e3fc6a8b04b991af3591 https://git.kernel.org/stable/c/fabe2db7de32a881e437ee69db32e0de785a6209 https://git.kernel.org/stable/c/96aa40761673da045a7774f874487cdb50c6a2f7 https://git.kernel.org/stable/c/c855a1a5b7e3de57e6b1b29563113d5e3bfdb89a https://git.kernel.org/stable/c/783d413f332a3ebec916664b366c28f58147f82c https://git.kernel.org/stable/c/fec14d1cdd92f340b9ba2bd220abf96f9609f2a9 https://git.kernel.org/stable/c/71d4186d470e9cda7cd1a0921b4afda737c6f641 https://git.kernel.org/stable/c/ea1d166fae14e05d49ffb0ea9fcd4658f • CWE-134: Use of Externally-Controlled Format String •

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

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: 0

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: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: io_uring: Fix release of pinned pages when __io_uaddr_map fails Looking at the error path of __io_uaddr_map, if we fail after pinning the pages for any reasons, ret will be set to -EINVAL and the error handler won't properly release the pinned pages. I didn't manage to trigger it without forcing a failure, but it can happen in real life when memory is heavily fragmented. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corregida la liberación de páginas fijadas cuando falla __io_uaddr_map. Mirando la ruta de error de __io_uaddr_map, si fallamos después de fijar las páginas por cualquier motivo, ret se establecerá en -EINVAL y el El controlador de errores no libera correctamente las páginas fijadas. No logré activarlo sin forzar un fallo, pero puede suceder en la vida real cuando la memoria está muy fragmentada. • https://git.kernel.org/stable/c/223ef474316466e9f61f6e0064f3a6fe4923a2c5 https://git.kernel.org/stable/c/3f3164ce6396138747984ee9e61158e248246300 https://git.kernel.org/stable/c/0b6f39c175ba5f0ef72bdb3b9d2a06ad78621d62 https://git.kernel.org/stable/c/712e2c8415f55a4a4ddaa98a430b87f624109f69 https://git.kernel.org/stable/c/4d376d7ad62b6a8e8dfff56b559d9d275e5b9b3a https://git.kernel.org/stable/c/67d1189d1095d471ed7fa426c7e384a7140a5dd7 •

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

In the Linux kernel, the following vulnerability has been resolved: media: tc358743: register v4l2 async device only after successful setup Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: media: tc358743: registre el dispositivo asíncrono v4l2 solo después de una configuración exitosa Asegúrese de que el dispositivo se haya configurado correctamente antes de registrar el dispositivo asíncrono v4l2, permitiendo así el acceso al espacio de usuario. • https://git.kernel.org/stable/c/4c5211a100399c3823563193dd881dcb3b7d24fc https://git.kernel.org/stable/c/17c2650de14842c25c569cbb2126c421489a3a24 https://git.kernel.org/stable/c/daf21394f9898fb9f0698c3e50de08132d2164e6 https://git.kernel.org/stable/c/610f20e5cf35ca9c0992693cae0dd8643ce932e7 https://git.kernel.org/stable/c/b8505a1aee8f1edc9d16d72ae09c93de086e2a1a https://git.kernel.org/stable/c/8ba8db9786b55047df5ad3db3e01dd886687a77d https://git.kernel.org/stable/c/edbb3226c985469a2f8eb69885055c9f5550f468 https://git.kernel.org/stable/c/c915c46a25c3efb084c4f5e69a053d7f7 •