{"vulnerability": "cve-2024-3948", "sightings": [{"uuid": "12a6e7e5-75d2-4746-bfd5-390a1229ceaa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39484", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "e6601b2f-7824-4660-92cb-2be644b737b0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39482", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "55331bd0-9c48-419f-b81d-b1e273bdd2e4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39487", "type": "seen", "source": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-226-07", "content": "", "creation_timestamp": "2025-08-14T10:00:00.000000Z"}, {"uuid": "37040a00-2c35-4bd6-8e8e-527145f15e7c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-39484", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "de21cf1f-3660-440b-a93f-e768d6f05559", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-39482", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "dc1a9efa-d147-4425-8b02-28fe04bb122c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39488", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/531", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39488 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39488 \nPublished : July 10, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \narm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY  \n  \nWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes  \nto bug_table entries, and as a result the last entry in a bug table will  \nbe ignored, potentially leading to an unexpected panic(). All prior  \nentries in the table will be handled correctly.  \n  \nThe arm64 ABI requires that struct fields of up to 8 bytes are  \nnaturally-aligned, with padding added within a struct such that struct  \nare suitably aligned within arrays.  \n  \nWhen CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:  \n  \n struct bug_entry {  \n  signed int      bug_addr_disp; // 4 bytes  \n  signed int      file_disp; // 4 bytes  \n  unsigned short  line;  // 2 bytes  \n  unsigned short  flags;  // 2 bytes  \n }  \n  \n... with 12 bytes total, requiring 4-byte alignment.  \n  \nWhen CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:  \n  \n struct bug_entry {  \n  signed int      bug_addr_disp; // 4 bytes  \n  unsigned short  flags;  // 2 bytes  \n    // 2 bytes  \n }  \n  \n... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing  \npadding, requiring 4-byte alginment.  \n  \nWhen we create a bug_entry in assembly, we align the start of the entry  \nto 4 bytes, which implicitly handles padding for any prior entries.  \nHowever, we do not align the end of the entry, and so when  \nCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding  \nbytes.  \n  \nFor the main kernel image this is not a problem as find_bug() doesn't  \ndepend on the trailing padding bytes when searching for entries:  \n  \n for (bug = __start___bug_table; bug num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);  \n  \n... and as the last bug_entry lacks the necessary padding bytes, this entry  \nwill not be counted, e.g. in the case of a single entry:  \n  \n sechdrs[i].sh_size == 6  \n sizeof(struct bug_entry) == 8;  \n  \n sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;  \n  \nConsequently module_find_bug() will miss the last bug_entry when it does:  \n  \n for (i = 0; i num_bugs; ++i, ++bug)  \n  if (bugaddr == bug_addr(bug))  \n   goto out;  \n  \n... which can lead to a kenrel panic due to an unhandled bug.  \n  \nThis can be demonstrated with the following module:  \n  \n static int __init buginit(void)  \n {  \n  WARN(1, \"hello\\n\");  \n  return 0;  \n }  \n  \n static void __exit bugexit(void)  \n {  \n }  \n  \n module_init(buginit);  \n module_exit(bugexit);  \n MODULE_LICENSE(\"GPL\");  \n  \n... which will trigger a kernel panic when loaded:  \n  \n ------------[ cut here ]------------  \n hello  \n Unexpected kernel BRK exception at EL1  \n Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP  \n Modules linked in: hello(O+)  \n CPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8  \n Hardware name: linux,dummy-virt (DT)  \n pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)  \n pc : buginit+0x18/0x1000 [hello]  \n lr : buginit+0x18/0x1000 [hello]  \n sp : ffff800080533ae0  \n x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000  \n x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58  \n x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0  \n x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006  \n x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720  \n x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312  \n x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8  \n x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000  \n x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000  \n x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0  \n Call trace:  \n  buginit+0x18/0x1000 [hello]  \n  do_one_initcall+0x80/0x1c8  \n  do_init_module+0x60/0x218  [...]", "creation_timestamp": "2024-07-10T10:54:49.000000Z"}, {"uuid": "59097c87-fc3f-4668-960d-5026e46c123c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39489", "type": "seen", "source": "https://t.me/cvedetector/530", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39489 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39489 \nPublished : July 10, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nipv6: sr: fix memleak in seg6_hmac_init_algo  \n  \nseg6_hmac_init_algo returns without cleaning up the previous allocations  \nif one fails, so it's going to leak all that memory and the crypto tfms.  \n  \nUpdate seg6_hmac_exit to only free the memory when allocated, so we can  \nreuse the code directly. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"10 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-10T10:54:48.000000Z"}, {"uuid": "a0dfe5cc-fa53-48af-b7af-37b0e4fc7c9c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39481", "type": "seen", "source": "https://t.me/cvedetector/86", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39481 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39481 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nmedia: mc: Fix graph walk in media_pipeline_start \n \nThe graph walk tries to follow all links, even if they are not between \npads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link. \n \nFix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK \nlinks. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:12.000000Z"}, {"uuid": "59d7da03-a6d1-4348-8b79-3a042276bf0a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39482", "type": "seen", "source": "https://t.me/cvedetector/84", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39482 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39482 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nbcache: fix variable length array abuse in btree_iter \n \nbtree_iter is used in two ways: either allocated on the stack with a \nfixed size MAX_BSETS, or from a mempool with a dynamic size based on the \nspecific cache set. Previously, the struct had a fixed-length array of \nsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sized \niterators, which causes UBSAN to complain. \n \nThis patch uses the same approach as in bcachefs's sort_iter and splits \nthe iterator into a btree_iter with a flexible array member and a \nbtree_iter_stack which embeds a btree_iter as well as a fixed-length \ndata array. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:10.000000Z"}, {"uuid": "6ece1bda-e61b-47cf-ae25-c7f2550eb834", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39483", "type": "seen", "source": "https://t.me/cvedetector/82", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39483 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39483 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nKVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked \n \nWhen requesting an NMI window, WARN on vNMI support being enabled if and \nonly if NMIs are actually masked, i.e. if the vCPU is already handling an \nNMI.  KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of \nview) is to inject one NMI and pend the other.  When using vNMI, KVM pends \nthe second NMI simply by setting V_NMI_PENDING, and lets the CPU do the \nrest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). \n \nHowever, if KVM can't immediately inject an NMI, e.g. because the vCPU is \nin an STI shadow or is running with GIF=0, then KVM will request an NMI \nwindow and trigger the WARN (but still function correctly). \n \nWhether or not the GIF=0 case makes sense is debatable, as the intent of \nKVM's behavior is to provide functionality that is as close to real \nhardware as possible.  E.g. if two NMIs are sent in quick succession, the \nprobability of both NMIs arriving in an STI shadow is infinitesimally low \non real hardware, but significantly larger in a virtual environment, e.g. \nif the vCPU is preempted in the STI shadow.  For GIF=0, the argument isn't \nas clear cut, because the window where two NMIs can collide is much larger \nin bare metal (though still small). \n \nThat said, KVM should not have divergent behavior for the GIF=0 case based \non whether or not vNMI support is enabled.  And KVM has allowed \nsimultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 \n(\"KVM: Fix simultaneous NMIs\").  I.e. KVM's GIF=0 handling shouldn't be \nmodified without a *really* good reason to do so, and if KVM's behavior \nwere to be modified, it should be done irrespective of vNMI support. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:05.000000Z"}, {"uuid": "5705fcdd-ffec-4815-b863-4a14d25feeb2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39487", "type": "seen", "source": "https://t.me/cvedetector/297", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39487 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39487 \nPublished : July 9, 2024, 10:15 a.m. | 47\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()  \n  \nIn function bond_option_arp_ip_targets_set(), if newval->string is an  \nempty string, newval->string+1 will point to the byte after the  \nstring, causing an out-of-bound read.  \n  \nBUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418  \nRead of size 1 at addr ffff8881119c4781 by task syz-executor665/8107  \nCPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1  \nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014  \nCall Trace:  \n   \n __dump_stack lib/dump_stack.c:88 [inline]  \n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106  \n print_address_description mm/kasan/report.c:364 [inline]  \n print_report+0xc1/0x5e0 mm/kasan/report.c:475  \n kasan_report+0xbe/0xf0 mm/kasan/report.c:588  \n strlen+0x7d/0xa0 lib/string.c:418  \n __fortify_strlen include/linux/fortify-string.h:210 [inline]  \n in4_pton+0xa3/0x3f0 net/core/utils.c:130  \n bond_option_arp_ip_targets_set+0xc2/0x910  \ndrivers/net/bonding/bond_options.c:1201  \n __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767  \n __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792  \n bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817  \n bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156  \n dev_attr_store+0x54/0x80 drivers/base/core.c:2366  \n sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136  \n kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334  \n call_write_iter include/linux/fs.h:2020 [inline]  \n new_sync_write fs/read_write.c:491 [inline]  \n vfs_write+0x96a/0xd80 fs/read_write.c:584  \n ksys_write+0x122/0x250 fs/read_write.c:637  \n do_syscall_x64 arch/x86/entry/common.c:52 [inline]  \n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83  \n entry_SYSCALL_64_after_hwframe+0x63/0x6b  \n---[ end trace ]---  \n  \nFix it by adding a check of string length before using it. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-09T13:05:23.000000Z"}, {"uuid": "b82200f6-7627-45f7-b588-3a33640e4585", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39480", "type": "seen", "source": "https://t.me/cvedetector/88", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39480 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39480 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nkdb: Fix buffer overflow during tab-complete \n \nCurrently, when the user attempts symbol completion with the Tab key, kdb \nwill use strncpy() to insert the completed symbol into the command buffer. \nUnfortunately it passes the size of the source buffer rather than the \ndestination to strncpy() with predictably horrible results. Most obviously \nif the command buffer is already full but cp, the cursor position, is in \nthe middle of the buffer, then we will write past the end of the supplied \nbuffer. \n \nFix this by replacing the dubious strncpy() calls with memmove()/memcpy() \ncalls plus explicit boundary checks to make sure we have enough space \nbefore we start moving characters around. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:13.000000Z"}, {"uuid": "21336160-f200-41cd-a73c-8c8fc314fb75", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39484", "type": "seen", "source": "https://t.me/cvedetector/80", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39484 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39484 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nmmc: davinci: Don't strip remove function when driver is builtin \n \nUsing __exit for the remove function results in the remove callback being \ndiscarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. \nusing sysfs or hotplug), the driver is just removed without the cleanup \nbeing performed. This results in resource leaks. Fix it by compiling in the \nremove callback unconditionally. \n \nThis also fixes a W=1 modpost warning: \n \nWARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in \nreference: davinci_mmcsd_driver+0x10 (section: .data) -> \ndavinci_mmcsd_remove (section: .exit.text) \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:03.000000Z"}, {"uuid": "92a7a835-fe95-47a0-b51c-35e0c76b7c4a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39486", "type": "seen", "source": "https://t.me/cvedetector/141", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39486 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39486 \nPublished : July 6, 2024, 10:15 a.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \ndrm/drm_file: Fix pid refcounting race \n \n \nfilp->pid is supposed to be a refcounted pointer; however, before this \npatch, drm_file_update_pid() only increments the refcount of a struct \npid after storing a pointer to it in filp->pid and dropping the \ndev->filelist_mutex, making the following race possible: \n \nprocess A               process B \n=========               ========= \n                        begin drm_file_update_pid \n                        mutex_lock(&dev->filelist_mutex) \n                        rcu_replace_pointer(filp->pid, , 1) \n                        mutex_unlock(&dev->filelist_mutex) \nbegin drm_file_update_pid \nmutex_lock(&dev->filelist_mutex) \nrcu_replace_pointer(filp->pid, , 1) \nmutex_unlock(&dev->filelist_mutex) \nget_pid() \nsynchronize_rcu() \nput_pid()   *** pid B reaches refcount 0 and is freed here *** \n                        get_pid()   *** UAF *** \n                        synchronize_rcu() \n                        put_pid() \n \nAs far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y \nbecause it requires RCU to detect a quiescent state in code that is not \nexplicitly calling into the scheduler. \n \nThis race leads to use-after-free of a \"struct pid\". \nIt is probably somewhat hard to hit because process A has to pass \nthrough a synchronize_rcu() operation while process B is between \nmutex_unlock() and get_pid(). \n \nFix it by ensuring that by the time a pointer to the current task's pid \nis stored in the file, an extra reference to the pid has been taken. \n \nThis fix also removes the condition for synchronize_rcu(); I think \nthat optimization is unnecessary complexity, since in that case we \nwould usually have bailed out on the lockless check above. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"06 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-06T12:44:38.000000Z"}, {"uuid": "81e9f41e-429a-447d-b597-0405022348c7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-39485", "type": "seen", "source": "https://t.me/cvedetector/91", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-39485 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-39485 \nPublished : July 5, 2024, 7:15 a.m. | 17\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved: \n \nmedia: v4l: async: Properly re-initialise notifier entry in unregister \n \nThe notifier_entry of a notifier is not re-initialised after unregistering \nthe notifier. This leads to dangling pointers being left there so use \nlist_del_init() to return the notifier_entry an empty list. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"05 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-05T09:34:19.000000Z"}, {"uuid": "157b6332-3bf5-464b-8938-e1fe4b629cea", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-3948", "type": "seen", "source": "Telegram/Xsq4XSCmmPzPfBAerdlaBdZEfVA6dId5qLDixfpnLAxQEPD9", "content": "", "creation_timestamp": "2025-02-14T10:00:30.000000Z"}]}