{"vulnerability": "cve-2024-4495", "sightings": [{"uuid": "bee9b0c1-2977-430e-8530-566250530512", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-44950", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "6bb3323a-eba9-45dd-b823-5060228ba6db", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44952", "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": "6f85a15f-8780-4e80-b46a-215cc378db6d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44954", "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": "2a37cd11-18c8-4706-9da2-f9171e24fbef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-44957", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "1a5f180a-3289-4971-bcea-5effe9a264bd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-44958", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "4c54dbb4-237e-4a9c-81d7-423f9045059d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-44950", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "0fa2be01-ee51-45bb-bc3a-69a68a4e95bd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44957", "type": "seen", "source": "https://t.me/cvedetector/4847", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44957 - Xen Privcmd Spinlock Race Condition\", \n  \"Content\": \"CVE ID : CVE-2024-44957 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nxen: privcmd: Switch from mutex to spinlock for irqfds  \n  \nirqfd_wakeup() gets EPOLLHUP, when it is called by  \neventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which  \ngets called under spin_lock_irqsave(). We can't use a mutex here as it  \nwill lead to a deadlock.  \n  \nFix it by switching over to a spin lock. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:56:27.000000Z"}, {"uuid": "c140a324-e857-4bb7-bee6-ea1fd9088dbe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44959", "type": "seen", "source": "https://t.me/cvedetector/4844", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44959 - Linux tracefs RCU List Corruption\", \n  \"Content\": \"CVE ID : CVE-2024-44959 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ntracefs: Use generic inode RCU for synchronizing freeing  \n  \nWith structure layout randomization enabled for 'struct inode' we need to  \navoid overlapping any of the RCU-used / initialized-only-once members,  \ne.g. i_lru or i_sb_list to not corrupt related list traversals when making  \nuse of the rcu_head.  \n  \nFor an unlucky structure layout of 'struct inode' we may end up with the  \nfollowing splat when running the ftrace selftests:  \n  \n[<...] list_del corruption, ffff888103ee2cb0->next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object])  \n[<...] ------------[ cut here ]------------  \n[<...] kernel BUG at lib/list_debug.c:54!  \n[<...] invalid opcode: 0000 [#1] PREEMPT SMP KASAN  \n[<...] CPU: 3 PID: 2550 Comm: mount Tainted: G                 N  6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65  \n[<...] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014  \n[<...] RIP: 0010:[] __list_del_entry_valid_or_report+0x138/0x3e0  \n[<...] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff  0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f  \n[<...] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283  \n[<...] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000  \n[<...] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001  \n[<...] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25  \n[<...] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d  \n[<...] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000  \n[<...] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object]  \n[<...] RDX: __list_del_entry_valid_or_report+0x108/0x3e0  \n[<...] RSI: __func__.47+0x4340/0x4400  \n[<...] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object]  \n[<...] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550]  \n[<...] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550]  \n[<...] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550]  \n[<...] R14: tracefs_inode_cache+0x78/0x4e0 [slab object]  \n[<...] FS:  00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000  \n[<...] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n[<...] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0  \n[<...] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  \n[<...] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  \n[<...] ASID: 0003  \n[<...] Stack:  \n[<...]  ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0  \n[<...]  ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f  \n[<...]  0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392  \n[<...] Call Trace:  \n[<...]    \n[<...]  [] ? lock_release+0x175/0x380 fffffe80416afaf0  \n[<...]  [] list_lru_del+0x152/0x740 fffffe80416afb48  \n[<...]  [] list_lru_del_obj+0x113/0x280 fffffe80416afb88  \n[<...]  [] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90  \n[<...]  [] iput_final+0x1c4/0x9a0 fffffe80416afbb8  \n[<...]  [] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8  \n[<...]  [] __dentry_kill+0x23c/0xf00 fffffe80416afc40  \n[<...]  [] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48  \n[<...]  [] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70  \n[<...]  [] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78  \n[<...]  [] shrink_dentry_list+0x288/0x760 fffffe80416afc80  \n[<...]  [] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8  \n[<...]  [] ? debug_smp_[...]", "creation_timestamp": "2024-09-04T21:56:24.000000Z"}, {"uuid": "ff520856-7656-42a4-9b57-3407459b2f73", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44952", "type": "seen", "source": "https://t.me/cvedetector/4843", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44952 - Apache Linux kernel Driver Core Device Locking Deadlock\", \n  \"Content\": \"CVE ID : CVE-2024-44952 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndriver core: Fix uevent_show() vs driver detach race  \n  \nuevent_show() wants to de-reference dev->driver->name. There is no clean  \nway for a device attribute to de-reference dev->driver unless that  \nattribute is defined via (struct device_driver).dev_groups. Instead, the  \nanti-pattern of taking the device_lock() in the attribute handler risks  \ndeadlocks with code paths that remove device attributes while holding  \nthe lock.  \n  \nThis deadlock is typically invisible to lockdep given the device_lock()  \nis marked lockdep_set_novalidate_class(), but some subsystems allocate a  \nlocal lockdep key for @dev->mutex to reveal reports of the form:  \n  \n ======================================================  \n WARNING: possible circular locking dependency detected  \n 6.10.0-rc7+ #275 Tainted: G           OE    N  \n ------------------------------------------------------  \n modprobe/2374 is trying to acquire lock:  \n ffff8c2270070de0 (kn->active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220  \n  \n but task is already holding lock:  \n ffff8c22016e88f8 (&cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210  \n  \n which lock already depends on the new lock.  \n  \n the existing dependency chain (in reverse order) is:  \n  \n -> #1 (&cxl_root_key){+.+.}-{3:3}:  \n        __mutex_lock+0x99/0xc30  \n        uevent_show+0xac/0x130  \n        dev_attr_show+0x18/0x40  \n        sysfs_kf_seq_show+0xac/0xf0  \n        seq_read_iter+0x110/0x450  \n        vfs_read+0x25b/0x340  \n        ksys_read+0x67/0xf0  \n        do_syscall_64+0x75/0x190  \n        entry_SYSCALL_64_after_hwframe+0x76/0x7e  \n  \n -> #0 (kn->active#6){++++}-{0:0}:  \n        __lock_acquire+0x121a/0x1fa0  \n        lock_acquire+0xd6/0x2e0  \n        kernfs_drain+0x1e9/0x200  \n        __kernfs_remove+0xde/0x220  \n        kernfs_remove_by_name_ns+0x5e/0xa0  \n        device_del+0x168/0x410  \n        device_unregister+0x13/0x60  \n        devres_release_all+0xb8/0x110  \n        device_unbind_cleanup+0xe/0x70  \n        device_release_driver_internal+0x1c7/0x210  \n        driver_detach+0x47/0x90  \n        bus_remove_driver+0x6c/0xf0  \n        cxl_acpi_exit+0xc/0x11 [cxl_acpi]  \n        __do_sys_delete_module.isra.0+0x181/0x260  \n        do_syscall_64+0x75/0x190  \n        entry_SYSCALL_64_after_hwframe+0x76/0x7e  \n  \nThe observation though is that driver objects are typically much longer  \nlived than device objects. It is reasonable to perform lockless  \nde-reference of a @driver pointer even if it is racing detach from a  \ndevice. Given the infrequency of driver unregistration, use  \nsynchronize_rcu() in module_remove_driver() to close any potential  \nraces.  It is potentially overkill to suffer synchronize_rcu() just to  \nhandle the rare module removal racing uevent_show() event.  \n  \nThanks to Tetsuo Handa for the debug analysis of the syzbot report [1]. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:56:20.000000Z"}, {"uuid": "e3053ec7-9562-4b9c-8802-e60db8d91fa9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44954", "type": "seen", "source": "https://t.me/cvedetector/4842", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44954 - Ubuntu Linux Kernel ALSA Line6 Race Condition\", \n  \"Content\": \"CVE ID : CVE-2024-44954 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nALSA: line6: Fix racy access to midibuf  \n  \nThere can be concurrent accesses to line6 midibuf from both the URB  \ncompletion callback and the rawmidi API access.  This could be a cause  \nof KMSAN warning triggered by syzkaller below (so put as reported-by  \nhere).  \n  \nThis patch protects the midibuf call of the former code path with a  \nspinlock for avoiding the possible races. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:56:19.000000Z"}, {"uuid": "eb8e5044-a744-4e3a-8b44-9d8b4c89a77d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44950", "type": "seen", "source": "https://t.me/cvedetector/4841", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44950 - Linux Kernel Serial sc16is7xx FIFO Access Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-44950 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nserial: sc16is7xx: fix invalid FIFO access with special register set  \n  \nWhen enabling access to the special register set, Receiver time-out and  \nRHR interrupts can happen. In this case, the IRQ handler will try to read  \nfrom the FIFO thru the RHR register at address 0x00, but address 0x00 is  \nmapped to DLL register, resulting in erroneous FIFO reading.  \n  \nCall graph example:  \n    sc16is7xx_startup(): entry  \n    sc16is7xx_ms_proc(): entry  \n    sc16is7xx_set_termios(): entry  \n    sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set  \n    sc16is7xx_port_irq() entry            --> IIR is 0x0C  \n    sc16is7xx_handle_rx() entry  \n    sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is  \n                               mapped to DLL (LCR=LCR_CONF_MODE_A)  \n    sc16is7xx_set_baud(): exit --> Restore access to general register set  \n  \nFix the problem by claiming the efr_lock mutex when accessing the Special  \nregister set. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:56:19.000000Z"}, {"uuid": "323ce1c8-a5dd-4805-82b0-1358dd046ddc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44955", "type": "seen", "source": "https://t.me/cvedetector/4849", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44955 - AMD Display Null Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-44955 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute  \n  \n[Why]  \nWhen unplug one of monitors connected after mst hub, encounter null pointer dereference.  \n  \nIt's due to dc_sink get released immediately in early_unregister() or detect_ctx(). When  \ncommit new state which directly referring to info stored in dc_sink will cause null pointer  \ndereference.  \n  \n[how]  \nRemove redundant checking condition. Relevant condition should already be covered by checking  \nif dsc_aux is null or not. Also reset dsc_aux to NULL when the connector is disconnected. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:57:05.000000Z"}, {"uuid": "a4f2c5d8-13fc-4418-bd06-96511f0848f9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44956", "type": "seen", "source": "https://t.me/cvedetector/4839", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44956 - \" Linux DRM Deadlock Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-44956 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/xe/preempt_fence: enlarge the fence critical section  \n  \nIt is really easy to introduce subtle deadlocks in  \npreempt_fence_work_func() since we operate on single global ordered-wq  \nfor signalling our preempt fences behind the scenes, so even though we  \nsignal a particular fence, everything in the callback should be in the  \nfence critical section, since blocking in the callback will prevent  \nother published fences from signalling. If we enlarge the fence critical  \nsection to cover the entire callback, then lockdep should be able to  \nunderstand this better, and complain if we grab a sensitive lock like  \nvm->lock, which is also held when waiting on preempt fences. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:56:17.000000Z"}, {"uuid": "6d0240d5-1cff-4263-bb57-6aa9e81d2957", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44958", "type": "seen", "source": "https://t.me/cvedetector/4838", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44958 - Linux Kernel SMT sched vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-44958 \nPublished : Sept. 4, 2024, 7:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsched/smt: Fix unbalance sched_smt_present dec/inc  \n  \nI got the following warn report while doing stress test:  \n  \njump label: negative count!  \nWARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0  \nCall Trace:  \n   \n __static_key_slow_dec_cpuslocked+0x16/0x70  \n sched_cpu_deactivate+0x26e/0x2a0  \n cpuhp_invoke_callback+0x3ad/0x10d0  \n cpuhp_thread_fun+0x3f5/0x680  \n smpboot_thread_fn+0x56d/0x8d0  \n kthread+0x309/0x400  \n ret_from_fork+0x41/0x70  \n ret_from_fork_asm+0x1b/0x30  \n   \n  \nBecause when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),  \nthe cpu offline failed, but sched_smt_present is decremented before  \ncalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so  \nfix it by incrementing sched_smt_present in the error path. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-04T21:56:13.000000Z"}]}