CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43888 – mm: list_lru: fix UAF for memory cgroup
https://notcve.org/view.php?id=CVE-2024-43888
In the Linux kernel, the following vulnerability has been resolved: mm: list_lru: fix UAF for memory cgroup The mem_cgroup_from_slab_obj() is supposed to be called under rcu lock or cgroup_mutex or others which could prevent returned memcg from being freed. Fix it by adding missing rcu read lock. Found by code inspection. [songmuchun@bytedance.com: only grab rcu lock when necessary, per Vlastimil] Link: https://lkml.kernel.org/r/20240801024603.1865-1-songmuchun@bytedance.com • https://git.kernel.org/stable/c/0a97c01cd20bb96359d8c9dedad92a061ed34e0b https://git.kernel.org/stable/c/4589f77c18dd98b65f45617b6d1e95313cf6fcab https://git.kernel.org/stable/c/5161b48712dcd08ec427c450399d4d1483e21dea •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43887 – net/tcp: Disable TCP-AO static key after RCU grace period
https://notcve.org/view.php?id=CVE-2024-43887
In the Linux kernel, the following vulnerability has been resolved: net/tcp: Disable TCP-AO static key after RCU grace period The lifetime of TCP-AO static_key is the same as the last tcp_ao_info. On the socket destruction tcp_ao_info ceases to be with RCU grace period, while tcp-ao static branch is currently deferred destructed. The static key definition is : DEFINE_STATIC_KEY_DEFERRED_FALSE(tcp_ao_needed, HZ); which means that if RCU grace period is delayed by more than a second and tcp_ao_needed is in the process of disablement, other CPUs may yet see tcp_ao_info which atent dead, but soon-to-be. And that breaks the assumption of static_key_fast_inc_not_disabled(). See the comment near the definition: > * The caller must make sure that the static key can't get disabled while > * in this function. It doesn't patch jump labels, only adds a user to > * an already enabled static key. Originally it was introduced in commit eb8c507296f6 ("jump_label: Prevent key->enabled int overflow"), which is needed for the atomic contexts, one of which would be the creation of a full socket from a request socket. In that atomic context, it's known by the presence of the key (md5/ao) that the static branch is already enabled. So, the ref counter for that static branch is just incremented instead of holding the proper mutex. static_key_fast_inc_not_disabled() is just a helper for such usage case. • https://git.kernel.org/stable/c/67fa83f7c86a86913ab9cd5a13b4bebd8d2ebb43 https://git.kernel.org/stable/c/954d55a59b2501f4a9bd693b40ce45a1c46cb2b3 https://git.kernel.org/stable/c/14ab4792ee120c022f276a7e4768f4dcb08f0cdd •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43886 – drm/amd/display: Add null check in resource_log_pipe_topology_update
https://notcve.org/view.php?id=CVE-2024-43886
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check in resource_log_pipe_topology_update [WHY] When switching from "Extend" to "Second Display Only" we sometimes call resource_get_otg_master_for_stream on a stream for the eDP, which is disconnected. This leads to a null pointer dereference. [HOW] Added a null check in dc_resource.c/resource_log_pipe_topology_update. • https://git.kernel.org/stable/c/c36e922a36bdf69765c340a0857ca74092003bee https://git.kernel.org/stable/c/899d92fd26fe780aad711322aa671f68058207a6 •
CVSS: -EPSS: 0%CPEs: 1EXPL: 0CVE-2024-43885 – btrfs: fix double inode unlock for direct IO sync writes
https://notcve.org/view.php?id=CVE-2024-43885
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double inode unlock for direct IO sync writes If we do a direct IO sync write, at btrfs_sync_file(), and we need to skip inode logging or we get an error starting a transaction or an error when flushing delalloc, we end up unlocking the inode when we shouldn't under the 'out_release_extents' label, and then unlock it again at btrfs_direct_write(). Fix that by checking if we have to skip inode unlocking under that label. • https://git.kernel.org/stable/c/939b656bc8ab203fdbde26ccac22bcb7f0985be5 https://git.kernel.org/stable/c/e0391e92f9ab4fb3dbdeb139c967dcfa7ac4b115 https://git.kernel.org/stable/c/1a607d22dea4f60438747705495ec4d0af2ec451 https://git.kernel.org/stable/c/8bd4c9220416111500c275546c69c63d42185793 https://git.kernel.org/stable/c/7ba27f14161fc20c4fc0051658a22ddd832eb0aa https://git.kernel.org/stable/c/d924a0be2f218501588cf463d70f1c71afea06d9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43884 – Bluetooth: MGMT: Add error handling to pair_device()
https://notcve.org/view.php?id=CVE-2024-43884
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Add error handling to pair_device() hci_conn_params_add() never checks for a NULL value and could lead to a NULL pointer dereference causing a crash. Fixed by adding error handling in the function. • https://git.kernel.org/stable/c/5157b8a503fa834e8569c7fed06981e3d3d53db0 https://git.kernel.org/stable/c/11b4b0e63f2621b33b2e107407a7d67a65994ca1 https://git.kernel.org/stable/c/90e1ff1c15e5a8f3023ca8266e3a85869ed03ee9 https://git.kernel.org/stable/c/9df9783bd85610d3d6e126a1aca221531f6f6dcb https://git.kernel.org/stable/c/951d6cb5eaac5130d076c728f2a6db420621afdb https://git.kernel.org/stable/c/5da2884292329bc9be32a7778e0e119f06abe503 https://git.kernel.org/stable/c/064dd929c76532359d2905d90a7c12348043cfd4 https://git.kernel.org/stable/c/ee0799103b1ae4bcfd80dc11a15df085f •