CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49873 – mm/filemap: fix filemap_get_folios_contig THP panic
https://notcve.org/view.php?id=CVE-2024-49873
In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series "memfd-pin huge page fixes". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM "2" is an xarray sibling entry. • https://git.kernel.org/stable/c/89c1905d9c140372b7f50ef48f42378cf85d9bc5 https://git.kernel.org/stable/c/570dd14bfecf281fa467c80f8ec92b26370ee36a https://git.kernel.org/stable/c/c225c4f6056b46a8a5bf2ed35abf17a2d6887691 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49872 – mm/gup: fix memfd_pin_folios alloc race panic
https://notcve.org/view.php?id=CVE-2024-49872
In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the "while start_idx" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error. • https://git.kernel.org/stable/c/89c1905d9c140372b7f50ef48f42378cf85d9bc5 https://git.kernel.org/stable/c/e28f39b359c0cfdcc011603e51187085a5f1e5e3 https://git.kernel.org/stable/c/ce645b9fdc78ec5d28067286e92871ddae6817d5 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-49871 – Input: adp5589-keys - fix NULL pointer dereference
https://notcve.org/view.php?id=CVE-2024-49871
In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early. • https://git.kernel.org/stable/c/30df385e35a48f773b85117fc490152c2395e45b https://git.kernel.org/stable/c/4449fedb8a710043fc0925409eba844c192d4337 https://git.kernel.org/stable/c/34e304cc53ae5d3c8e3f08b41dd11e0d4f3e01ed https://git.kernel.org/stable/c/7c3f04223aaf82489472d614c6decee5a1ce8d7f https://git.kernel.org/stable/c/9a38791ee79bd17d225c15a6d1479448be127a59 https://git.kernel.org/stable/c/122b160561f6429701a0559a0f39b0ae309488c6 https://git.kernel.org/stable/c/fb5cc65f973661241e4a2b7390b429aa7b330c69 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49870 – cachefiles: fix dentry leak in cachefiles_open_file()
https://notcve.org/view.php?id=CVE-2024-49870
In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: <TASK> d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code. • https://git.kernel.org/stable/c/1f08c925e7a38002bde509e66f6f891468848511 https://git.kernel.org/stable/c/d32ff64c872d7e08e893c32ba6a2374583444410 https://git.kernel.org/stable/c/c7d10fa7d7691558ff967668494672415f5fa151 https://git.kernel.org/stable/c/e4a28489b310339b2b8187bec0a437709be551c1 https://git.kernel.org/stable/c/7fa2382f97421978514a419c93054eca69f5247b https://git.kernel.org/stable/c/da6ef2dffe6056aad3435e6cf7c6471c2a62187c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49869 – btrfs: send: fix buffer overflow detection when copying path to cache entry
https://notcve.org/view.php?id=CVE-2024-49869
In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 ("btrfs: send: annotate struct name_cache_entry with __counted_by()") we annotated the variable length array "name" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the "name_len" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: <TASK> ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? • https://git.kernel.org/stable/c/c0247d289e73e18f6ddb0895de30c09770fbed95 https://git.kernel.org/stable/c/843738ede6cb8b959fb22591fcbabe8b456d7216 https://git.kernel.org/stable/c/96c6ca71572a3556ed0c37237305657ff47174b7 •