Page 74 of 1409 results (0.007 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Validate payload length before processing block Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load() to be done before the block is processed. The check that the length of a block payload does not exceed the number of remaining bytes in the firwmware file buffer was being done near the end of the loop iteration. However, some code before that check used the length field without validating it. • https://git.kernel.org/stable/c/f6bc909e7673c30abcbdb329e7d0aa2e83c103d7 https://git.kernel.org/stable/c/259955eca9b7acf1299b1ac077d8cfbe12df35d8 https://git.kernel.org/stable/c/3a9cd924aec1288d675df721f244da4dd7e16cff https://git.kernel.org/stable/c/71d9e313d8f7e18c543a9c80506fe6b1eb1fe0c8 https://git.kernel.org/stable/c/6598afa9320b6ab13041616950ca5f8f938c0cf1 https://access.redhat.com/security/cve/CVE-2024-42237 https://bugzilla.redhat.com/show_bug.cgi?id=2303505 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •

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

In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Prevent OOB read/write in usb_string_copy() Userspace provided string 's' could trivially have the length zero. Left unchecked this will firstly result in an OOB read in the form `if (str[0 - 1] == '\n') followed closely by an OOB write in the form `str[0 - 1] = '\0'`. There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short. • https://git.kernel.org/stable/c/a444c3fc264119801575ab086e03fb4952f23fd0 https://git.kernel.org/stable/c/c95fbdde87e39e5e0ae27f28bf6711edfb985caa https://git.kernel.org/stable/c/e8474a10c535e6a2024c3b06e37e4a3a23beb490 https://git.kernel.org/stable/c/72b8ee0d9826e8ed00e0bdfce3e46b98419b37ce https://git.kernel.org/stable/c/2d16f63d8030903e5031853e79d731ee5d474e70 https://git.kernel.org/stable/c/d1205033e912f9332c1dbefa812e6ceb0575ce0a https://git.kernel.org/stable/c/eecfefad0953b2f31aaefa058f7f348ff39c4bba https://git.kernel.org/stable/c/6d3c721e686ea6c59e18289b400cc95c7 •

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

In the Linux kernel, the following vulnerability has been resolved: s390/mm: Add NULL pointer check to crst_table_free() base_crst_free() crst_table_free() used to work with NULL pointers before the conversion to ptdescs. Since crst_table_free() can be called with a NULL pointer (error handling in crst_table_upgrade() add an explicit check. Also add the same check to base_crst_free() for consistency reasons. In real life this should not happen, since order two GFP_KERNEL allocations will not fail, unless FAIL_PAGE_ALLOC is enabled and used. • https://git.kernel.org/stable/c/6326c26c1514757242829b292b26eac589013200 https://git.kernel.org/stable/c/794fa52b94637d6b2e8c9474fbe3983af5c9f046 https://git.kernel.org/stable/c/f80bd8bb6f380bc265834c46058d38b34174813e https://git.kernel.org/stable/c/b5efb63acf7bddaf20eacfcac654c25c446eabe8 •

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

In the Linux kernel, the following vulnerability has been resolved: mm: fix crashes from deferred split racing folio migration Even on 6.10-rc6, I've been seeing elusive "Bad page state"s (often on flags when freeing, yet the flags shown are not bad: PG_locked had been set and cleared??), and VM_BUG_ON_PAGE(page_ref_count(page) == 0)s from deferred_split_scan()'s folio_put(), and a variety of other BUG and WARN symptoms implying double free by deferred split and large folio migration. 6.7 commit 9bcef5973e31 ("mm: memcg: fix split queue list crash when large folio migration") was right to fix the memcg-dependent locking broken in 85ce2c517ade ("memcontrol: only transfer the memcg data for migration"), but missed a subtlety of deferred_split_scan(): it moves folios to its own local list to work on them without split_queue_lock, during which time folio->_deferred_list is not empty, but even the "right" lock does nothing to secure the folio and the list it is on. Fortunately, deferred_split_scan() is careful to use folio_try_get(): so folio_migrate_mapping() can avoid the race by folio_undo_large_rmappable() while the old folio's reference count is temporarily frozen to 0 - adding such a freeze in the !mapping case too (originally, folio lock and unmapping and no swap cache left an anon folio unreachable, so no freezing was needed there: but the deferred split queue offers a way to reach it). • https://git.kernel.org/stable/c/9bcef5973e31020e5aa8571eb994d67b77318356 https://git.kernel.org/stable/c/fc7facce686b64201dbf0b9614cc1d0bfad70010 https://git.kernel.org/stable/c/be9581ea8c058d81154251cb0695987098996cad •

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

In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed • https://git.kernel.org/stable/c/1177afeca833174ba83504688eec898c6214f4bf https://git.kernel.org/stable/c/63e5d035e3a7ab7412a008f202633c5e6a0a28ea https://git.kernel.org/stable/c/34b76d1922e41da1fa73d43b764cddd82ac9733c https://git.kernel.org/stable/c/20cf67dcb7db842f941eff1af6ee5e9dc41796d7 https://git.kernel.org/stable/c/2d33654d40a05afd91ab24c9a73ab512a0670a9a https://git.kernel.org/stable/c/9525af1f58f67df387768770fcf6d6a8f23aee3d https://git.kernel.org/stable/c/33d38c5da17f8db2d80e811b7829d2822c10625e https://git.kernel.org/stable/c/69c7b2fe4c9cc1d3b1186d1c5606627ec •