CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53088 – i40e: fix race condition by adding filter's intermediate sync state
https://notcve.org/view.php?id=CVE-2024-53088
In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. • https://git.kernel.org/stable/c/278e7d0b9d6864a9749b9473a273892aa1528621 https://git.kernel.org/stable/c/262dc6ea5f1eb18c4d08ad83d51222d0dd0dd42a https://git.kernel.org/stable/c/7ad3fb3bfd43feb4e15c81dffd23ac4e55742791 https://git.kernel.org/stable/c/bf5f837d9fd27d32fb76df0a108babcaf4446ff1 https://git.kernel.org/stable/c/6e046f4937474bc1b9fa980c1ad8f3253fc638f6 https://git.kernel.org/stable/c/f30490e9695ef7da3d0899c6a0293cc7cd373567 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-53084 – drm/imagination: Break an object reference loop
https://notcve.org/view.php?id=CVE-2024-53084
In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler "finished" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context. • https://git.kernel.org/stable/c/cb86db12b290ed07d05df00d99fa150bb123e80e https://git.kernel.org/stable/c/b04ce1e718bd55302b52d05d6873e233cb3ec7a1 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53082 – virtio_net: Add hash_key_length check
https://notcve.org/view.php?id=CVE-2024-53082
In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key. • https://git.kernel.org/stable/c/c7114b1249fa3b5f3a434606ba4cc89c4a27d618 https://git.kernel.org/stable/c/f3401e3c8d339ddb6ccb2e3d11ad634b7846a806 https://git.kernel.org/stable/c/af0aa8aecbe8985079232902894cc4cb62795691 https://git.kernel.org/stable/c/6a18a783b1fa590ad1ed785907263e4b86adcfe2 https://git.kernel.org/stable/c/3f7d9c1964fcd16d02a8a9d4fd6f6cb60c4cc530 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53079 – mm/thp: fix deferred split unqueue naming and locking
https://notcve.org/view.php?id=CVE-2024-53079
In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? • https://git.kernel.org/stable/c/87eaceb3faa59b9b4d940ec9554ce251325d83fe https://git.kernel.org/stable/c/fc4951c3e3358dd82ea508e893695b916c813f17 https://git.kernel.org/stable/c/afb1352d06b1b6b2cfd1f901c766a430c87078b3 https://git.kernel.org/stable/c/f8f931bba0f92052cf842b7e30917b1afcc77d5a •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53072 – platform/x86/amd/pmc: Detect when STB is not available
https://notcve.org/view.php?id=CVE-2024-53072
In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message. • https://git.kernel.org/stable/c/3d7d407dfb05b257e15cb0c6b056428a4a8c2e5d https://git.kernel.org/stable/c/a50863dd1f92d43c975ab2ecc3476617fe98a66e https://git.kernel.org/stable/c/7a3ed3f125292bc3398e04d10108124250892e3f https://git.kernel.org/stable/c/67ff30e24a0466bdd5be1d0b84385ec3c85fdacd https://git.kernel.org/stable/c/bceec87a73804bb4c33b9a6c96e2d27cd893a801 •