Page 20 of 3076 results (0.015 seconds)

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

21 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: tracing: Have process_string() also allow arrays In order to catch a common bug where a TRACE_EVENT() TP_fast_assign() assigns an address of an allocated string to the ring buffer and then references it in TP_printk(), which can be executed hours later when the string is free, the function test_event_printk() runs on all events as they are registered to make sure there's no unwanted dereferencing. It calls process_string() to handle cases i... • https://git.kernel.org/stable/c/f3ff759ec636b4094b8eb2c3801e4e6c97a6b712 •

CVSS: 4.7EPSS: 0%CPEs: 4EXPL: 1

20 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period io_eventfd_do_signal() is invoked from an RCU callback, but when dropping the reference to the io_ev_fd, it calls io_eventfd_free() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the io_ev_fd should be deferred another RCU grace period. Just call io_eventfd_put() rather than open-code the dec-and-test and free, which will correctl... • https://packetstorm.news/files/id/189367 •

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

19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: dm array: fix releasing a faulty array block twice in dm_array_cursor_end When dm_bm_read_lock() fails due to locking or checksum errors, it releases the faulty block implicitly while leaving an invalid output pointer behind. The caller of dm_bm_read_lock() should not operate on this invalid dm_block pointer, or it will lead to undefined result. For example, the dm_array_cursor incorrectly caches the invalid pointer on reading a faulty arra... • https://git.kernel.org/stable/c/fdd1315aa5f022fe6574efdc2d9535f75a0ee255 •

CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0

19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Set private->all_drm_private[i]->drm to NULL if mtk_drm_bind returns err The pointer need to be set to NULL, otherwise KASAN complains about use-after-free. Because in mtk_drm_bind, all private's drm are set as follows. private->all_drm_private[i]->drm = drm; And drm will be released by drm_dev_put in case mtk_drm_kms_init returns failure. However, the shutdown path still accesses the previous allocated memory in drm_atomic_he... • https://git.kernel.org/stable/c/1ef7ed48356cd5f9af2b7671956991b658d8c2ba • CWE-416: Use After Free •

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

19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix a missing return value check bug In the smb2_send_interim_resp(), if ksmbd_alloc_work_struct() fails to allocate a node, it returns a NULL pointer to the in_work pointer. This can lead to an illegal memory write of in_work->response_buf when allocate_interim_rsp_buf() attempts to perform a kzalloc() on it. To address this issue, incorporating a check for the return value of ksmbd_alloc_work_struct() ensures that the function retu... • https://git.kernel.org/stable/c/6f0207218c4c125f5bf32055ac4220b4ef3b7e67 •

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

19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: fs: relax assertions on failure to encode file handles Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons. The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle. There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encod... • https://git.kernel.org/stable/c/f47c834a9131ae64bee3c462f4e610c67b0a000f •

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

19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add check for granularity in dml ceil/floor helpers [Why] Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2() should check for granularity is non zero to avoid assert and divide-by-zero error in dcn_bw_ functions. [How] Add check for granularity 0. (cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec) In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add check for granu... • https://git.kernel.org/stable/c/8a9315e6f7b2d94c65a1ba476481deddb20fc3ae •

CVSS: 7.1EPSS: 0%CPEs: 5EXPL: 0

19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: topology: Keep the cpumask unchanged when printing cpumap During fuzz testing, the following warning was discovered: different return values (15 and 11) from vsnprintf("%*pbl ", ...) test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmap_print_to_buf+0x89/0x100 core_siblings_list_read+0x7e/0xb0 kernfs_file_read_iter+0x15b/... • https://git.kernel.org/stable/c/bb9ec13d156e85dfd6a8afd0bb61ccf5736ed257 •

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

19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: misc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling Resolve kernel panic caused by improper handling of IRQs while accessing GPIO values. This is done by replacing generic_handle_irq with handle_nested_irq. In the Linux kernel, the following vulnerability has been resolved: misc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling Resolve kernel panic caused by improper handling of IRQs while accessing GP... • https://git.kernel.org/stable/c/1f4d8ae231f47c7d890198cd847055a96482a443 •

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

19 Jan 2025 — In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Remove WARN_ON in functionfs_bind This commit addresses an issue related to below kernel panic where panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON in functionsfs_bind, which easily leads to the following scenarios. 1.adb_write in adbd 2. UDC write via configfs ================= ===================== ->usb_ffs_open_thread() ->UDC write ->open_functionfs() ->configfs_write_iter() ->adb_open() ->ga... • https://git.kernel.org/stable/c/ddf8abd2599491cbad959c700b90ba72a5dce8d0 •