{"vulnerability": "cve-2024-4669", "sightings": [{"uuid": "ef8a244f-9e71-4800-8747-1243cc8fbfa9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-46695", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "ccf7aa37-8d60-46e3-8c23-6e39cb014ed3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46697", "type": "seen", "source": "https://t.me/cvedetector/5551", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46697 - NFSd Use-After-Free Buffer Overflow\", \n  \"Content\": \"CVE ID : CVE-2024-46697 \nPublished : Sept. 13, 2024, 6:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnfsd: ensure that nfsd4_fattr_args.context is zeroed out  \n  \nIf nfsd4_encode_fattr4 ends up doing a \"goto out\" before we get to  \nchecking for the security label, then args.context will be set to  \nuninitialized junk on the stack, which we'll then try to free.  \nInitialize it early. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"13 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T13:10:59.000000Z"}, {"uuid": "eed92caf-4877-4931-b8d7-be756582fd5e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46696", "type": "seen", "source": "https://t.me/cvedetector/5543", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46696 - Linux NFSd Uninitialized Memory Access\", \n  \"Content\": \"CVE ID : CVE-2024-46696 \nPublished : Sept. 13, 2024, 6:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnfsd: fix potential UAF in nfsd4_cb_getattr_release  \n  \nOnce we drop the delegation reference, the fields embedded in it are no  \nlonger safe to access. Do that last. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"13 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T08:45:36.000000Z"}, {"uuid": "02ee1300-735c-4e84-a8ab-c8f70b776486", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46693", "type": "seen", "source": "https://t.me/cvedetector/5549", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46693 - Qualcomm QCOM Linux Kernel NULL Pointer Dereference\", \n  \"Content\": \"CVE ID : CVE-2024-46693 \nPublished : Sept. 13, 2024, 6:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsoc: qcom: pmic_glink: Fix race during initialization  \n  \nAs pointed out by Stephen Boyd it is possible that during initialization  \nof the pmic_glink child drivers, the protection-domain notifiers fires,  \nand the associated work is scheduled, before the client registration  \nreturns and as a result the local \"client\" pointer has been initialized.  \n  \nThe outcome of this is a NULL pointer dereference as the \"client\"  \npointer is blindly dereferenced.  \n  \nTimeline provided by Stephen:  \n CPU0                               CPU1  \n ----                               ----  \n ucsi-&gt;client = NULL;  \n devm_pmic_glink_register_client()  \n  client-&gt;pdr_notify(client-&gt;priv, pg-&gt;client_state)  \n   pmic_glink_ucsi_pdr_notify()  \n    schedule_work(&amp;ucsi-&gt;register_work)  \n      \n                                    pmic_glink_ucsi_register()  \n                                     ucsi_register()  \n                                      pmic_glink_ucsi_read_version()  \n                                       pmic_glink_ucsi_read()  \n                                        pmic_glink_ucsi_read()  \n                                         pmic_glink_send(ucsi-&gt;client)  \n                                           \n ucsi-&gt;client = client // Too late!  \n  \nThis code is identical across the altmode, battery manager and usci  \nchild drivers.  \n  \nResolve this by splitting the allocation of the \"client\" object and the  \nregistration thereof into two operations.  \n  \nThis only happens if the protection domain registry is populated at the  \ntime of registration, which by the introduction of commit '1ebcde047c54  \n(\"soc: qcom: add pd-mapper implementation\")' became much more likely. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"13 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T08:45:47.000000Z"}, {"uuid": "3a65b895-cd81-4e0f-9a2f-c47ae143a44d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46694", "type": "seen", "source": "https://t.me/cvedetector/5548", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46694 - AMD Display Null Object Pointer Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-46694 \nPublished : Sept. 13, 2024, 6:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/amd/display: avoid using null object of framebuffer  \n  \nInstead of using state-&gt;fb-&gt;obj[0] directly, get object from framebuffer  \nby calling drm_gem_fb_get_obj() and return error code when object is  \nnull to avoid using null object of framebuffer.  \n  \n(cherry picked from commit 73dd0ad9e5dad53766ea3e631303430116f834b3) \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"13 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T08:45:43.000000Z"}, {"uuid": "9d0ca2ad-a389-41c9-a7b3-5d39f8404f9f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46692", "type": "seen", "source": "https://t.me/cvedetector/5547", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46692 - Qualcomm qcom Firmware Atomic Sleep Mode Deadlock\", \n  \"Content\": \"CVE ID : CVE-2024-46692 \nPublished : Sept. 13, 2024, 6:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfirmware: qcom: scm: Mark get_wq_ctx() as atomic call  \n  \nCurrently get_wq_ctx() is wrongly configured as a standard call. When two  \nSMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to  \nresume the corresponding sleeping thread. But if get_wq_ctx() is  \ninterrupted, goes to sleep and another SMC call is waiting to be allocated  \na waitq context, it leads to a deadlock.  \n  \nTo avoid this get_wq_ctx() must be an atomic call and can't be a standard  \nSMC call. Hence mark get_wq_ctx() as a fast call. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"13 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T08:45:42.000000Z"}, {"uuid": "b2dd91d4-2d33-4cfd-b561-c8835419efc9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46698", "type": "seen", "source": "https://t.me/cvedetector/5544", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46698 - Cisco Linux Kernel Video NULL Pointer Dereference\", \n  \"Content\": \"CVE ID : CVE-2024-46698 \nPublished : Sept. 13, 2024, 6:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nvideo/aperture: optionally match the device in sysfb_disable()  \n  \nIn aperture_remove_conflicting_pci_devices(), we currently only  \ncall sysfb_disable() on vga class devices.  This leads to the  \nfollowing problem when the pimary device is not VGA compatible:  \n  \n1. A PCI device with a non-VGA class is the boot display  \n2. That device is probed first and it is not a VGA device so  \n   sysfb_disable() is not called, but the device resources  \n   are freed by aperture_detach_platform_device()  \n3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable()  \n4. NULL pointer dereference via sysfb_disable() since the resources  \n   have already been freed by aperture_detach_platform_device() when  \n   it was called by the other device.  \n  \nFix this by passing a device pointer to sysfb_disable() and checking  \nthe device to determine if we should execute it or not.  \n  \nv2: Fix build when CONFIG_SCREEN_INFO is not set  \nv3: Move device check into the mutex  \n    Drop primary variable in aperture_remove_conflicting_pci_devices()  \n    Drop __init on pci sysfb_pci_dev_is_enabled() \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"13 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T08:45:40.000000Z"}, {"uuid": "02bd3543-61b1-4c6e-a8c2-0ead2d41eaa5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46699", "type": "seen", "source": "https://t.me/cvedetector/5545", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46699 - AMD v3d Preemption Enablement Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-46699 \nPublished : Sept. 13, 2024, 6:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/v3d: Disable preemption while updating GPU stats  \n  \nWe forgot to disable preemption around the write_seqcount_begin/end() pair  \nwhile updating GPU stats:  \n  \n  [ ] WARNING: CPU: 2 PID: 12 at include/linux/seqlock.h:221 __seqprop_assert.isra.0+0x128/0x150 [v3d]  \n  [ ] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] &lt;...snip...[ ] Call trace:  \n  [ ]  __seqprop_assert.isra.0+0x128/0x150 [v3d]  \n  [ ]  v3d_job_start_stats.isra.0+0x90/0x218 [v3d]  \n  [ ]  v3d_bin_job_run+0x23c/0x388 [v3d]  \n  [ ]  drm_sched_run_job_work+0x520/0x6d0 [gpu_sched]  \n  [ ]  process_one_work+0x62c/0xb48  \n  [ ]  worker_thread+0x468/0x5b0  \n  [ ]  kthread+0x1c4/0x1e0  \n  [ ]  ret_from_fork+0x10/0x20  \n  \nFix it. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"13 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T08:45:41.000000Z"}, {"uuid": "e5190e5d-4205-47c5-bf40-83d24dedc96e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46695", "type": "seen", "source": "https://t.me/cvedetector/5542", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46695 - \"NFS SELinux Smack: Root Squashing Permission Bypass\"\", \n  \"Content\": \"CVE ID : CVE-2024-46695 \nPublished : Sept. 13, 2024, 6:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nselinux,smack: don't bypass permissions check in inode_setsecctx hook  \n  \nMarek Gresko reports that the root user on an NFS client is able to  \nchange the security labels on files on an NFS filesystem that is  \nexported with root squashing enabled.  \n  \nThe end of the kerneldoc comment for __vfs_setxattr_noperm() states:  \n  \n *  This function requires the caller to lock the inode's i_mutex before it  \n *  is executed. It also assumes that the caller will make the appropriate  \n *  permission checks.  \n  \nnfsd_setattr() does do permissions checking via fh_verify() and  \nnfsd_permission(), but those don't do all the same permissions checks  \nthat are done by security_inode_setxattr() and its related LSM hooks do.  \n  \nSince nfsd_setattr() is the only consumer of security_inode_setsecctx(),  \nsimplest solution appears to be to replace the call to  \n__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  This  \nfixes the above issue and has the added benefit of causing nfsd to  \nrecall conflicting delegations on a file when a client tries to change  \nits security label. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"13 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-13T08:45:35.000000Z"}]}