{"vulnerability": "cve-2024-4679", "sightings": [{"uuid": "2453a191-85a7-4e5a-8931-c085f7e8035d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46798", "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": "0401622a-e464-43d5-9337-6201aa4cc771", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46791", "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": "2bd894da-afcd-45e2-b7c3-b9b90926bc8a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46790", "type": "seen", "source": "https://t.me/cvedetector/5936", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46790 - Linux Kernel hwpoison_inject alloc_tag Warning\", \n  \"Content\": \"CVE ID : CVE-2024-46790 \nPublished : Sept. 18, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ncodetag: debug: mark codetags for poisoned page as empty  \n  \nWhen PG_hwpoison pages are freed they are treated differently in  \nfree_pages_prepare() and instead of being released they are isolated.  \n  \nPage allocation tag counters are decremented at this point since the page  \nis considered not in use.  Later on when such pages are released by  \nunpoison_memory(), the allocation tag counters will be decremented again  \nand the following warning gets reported:  \n  \n[  113.930443][ T3282] ------------[ cut here ]------------  \n[  113.931105][ T3282] alloc_tag was not set  \n[  113.931576][ T3282] WARNING: CPU: 2 PID: 3282 at ./include/linux/alloc_tag.h:130 pgalloc_tag_sub.part.66+0x154/0x164  \n[  113.932866][ T3282] Modules linked in: hwpoison_inject fuse ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute ip6table_nat ip6table_man4  \n[  113.941638][ T3282] CPU: 2 UID: 0 PID: 3282 Comm: madvise11 Kdump: loaded Tainted: G        W          6.11.0-rc4-dirty #18  \n[  113.943003][ T3282] Tainted: [W]=WARN  \n[  113.943453][ T3282] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022  \n[  113.944378][ T3282] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)  \n[  113.945319][ T3282] pc : pgalloc_tag_sub.part.66+0x154/0x164  \n[  113.946016][ T3282] lr : pgalloc_tag_sub.part.66+0x154/0x164  \n[  113.946706][ T3282] sp : ffff800087093a10  \n[  113.947197][ T3282] x29: ffff800087093a10 x28: ffff0000d7a9d400 x27: ffff80008249f0a0  \n[  113.948165][ T3282] x26: 0000000000000000 x25: ffff80008249f2b0 x24: 0000000000000000  \n[  113.949134][ T3282] x23: 0000000000000001 x22: 0000000000000001 x21: 0000000000000000  \n[  113.950597][ T3282] x20: ffff0000c08fcad8 x19: ffff80008251e000 x18: ffffffffffffffff  \n[  113.952207][ T3282] x17: 0000000000000000 x16: 0000000000000000 x15: ffff800081746210  \n[  113.953161][ T3282] x14: 0000000000000000 x13: 205d323832335420 x12: 5b5d353031313339  \n[  113.954120][ T3282] x11: ffff800087093500 x10: 000000000000005d x9 : 00000000ffffffd0  \n[  113.955078][ T3282] x8 : 7f7f7f7f7f7f7f7f x7 : ffff80008236ba90 x6 : c0000000ffff7fff  \n[  113.956036][ T3282] x5 : ffff000b34bf4dc8 x4 : ffff8000820aba90 x3 : 0000000000000001  \n[  113.956994][ T3282] x2 : ffff800ab320f000 x1 : 841d1e35ac932e00 x0 : 0000000000000000  \n[  113.957962][ T3282] Call trace:  \n[  113.958350][ T3282]  pgalloc_tag_sub.part.66+0x154/0x164  \n[  113.959000][ T3282]  pgalloc_tag_sub+0x14/0x1c  \n[  113.959539][ T3282]  free_unref_page+0xf4/0x4b8  \n[  113.960096][ T3282]  __folio_put+0xd4/0x120  \n[  113.960614][ T3282]  folio_put+0x24/0x50  \n[  113.961103][ T3282]  unpoison_memory+0x4f0/0x5b0  \n[  113.961678][ T3282]  hwpoison_unpoison+0x30/0x48 [hwpoison_inject]  \n[  113.962436][ T3282]  simple_attr_write_xsigned.isra.34+0xec/0x1cc  \n[  113.963183][ T3282]  simple_attr_write+0x38/0x48  \n[  113.963750][ T3282]  debugfs_attr_write+0x54/0x80  \n[  113.964330][ T3282]  full_proxy_write+0x68/0x98  \n[  113.964880][ T3282]  vfs_write+0xdc/0x4d0  \n[  113.965372][ T3282]  ksys_write+0x78/0x100  \n[  113.965875][ T3282]  __arm64_sys_write+0x24/0x30  \n[  113.966440][ T3282]  invoke_syscall+0x7c/0x104  \n[  113.966984][ T3282]  el0_svc_common.constprop.1+0x88/0x104  \n[  113.967652][ T3282]  do_el0_svc+0x2c/0x38  \n[  113.968893][ T3282]  el0_svc+0x3c/0x1b8  \n[  113.969379][ T3282]  el0t_64_sync_handler+0x98/0xbc  \n[  113.969980][ T3282]  el0t_64_sync+0x19c/0x1a0  \n[  113.970511][ T3282] ---[ end trace 0000000000000000 ]---  \n  \nTo fix this, clear the page tag reference after the page got isolated  \nand accounted for. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"1[...]", "creation_timestamp": "2024-09-18T10:52:38.000000Z"}, {"uuid": "a84f03d5-80eb-4b3a-b8e0-8becf42ea677", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46791", "type": "seen", "source": "https://t.me/cvedetector/5935", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46791 - Linux MCP251X Interrupt Handler Deadlock in Mutex Acquisition\", \n  \"Content\": \"CVE ID : CVE-2024-46791 \nPublished : Sept. 18, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open  \n  \nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and  \ndisables the interrupt handler so that no interrupts can be processed while  \nwaking the device. If an interrupt has already occurred then waiting for  \nthe interrupt handler to complete will deadlock because it will be trying  \nto acquire the same mutex.  \n  \nCPU0                           CPU1  \n----                           ----  \nmcp251x_open()  \n mutex_lock(&priv->mcp_lock)  \n  request_threaded_irq()  \n                                 \n                               mcp251x_can_ist()  \n                                mutex_lock(&priv->mcp_lock)  \n  mcp251x_hw_wake()  \n   disable_irq() <--\nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"18 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-18T10:52:37.000000Z"}, {"uuid": "866e23a8-fcab-4693-8250-0511a042ca40", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46799", "type": "seen", "source": "https://t.me/cvedetector/5934", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46799 - Ti Am65 CPSW NULL Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-46799 \nPublished : Sept. 18, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: ethernet: ti: am65-cpsw: Fix NULL dereference on XDP_TX  \n  \nIf number of TX queues are set to 1 we get a NULL pointer  \ndereference during XDP_TX.  \n  \n~# ethtool -L eth0 tx 1  \n~# ./xdp-trafficgen udp -A  -a  eth0 -t 2  \nTransmitting on eth0 (ifindex 2)  \n[  241.135257] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030  \n  \nFix this by using actual TX queues instead of max TX queues  \nwhen picking the TX channel in am65_cpsw_ndo_xdp_xmit(). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"18 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-18T10:52:33.000000Z"}, {"uuid": "b99bcfe0-fac2-4347-87ef-22cbfa4e8294", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46798", "type": "seen", "source": "https://t.me/cvedetector/5933", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46798 - \"Audiofine Linux Kernel Use-After-Free\"\", \n  \"Content\": \"CVE ID : CVE-2024-46798 \nPublished : Sept. 18, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nASoC: dapm: Fix UAF for snd_soc_pcm_runtime object  \n  \nWhen using kernel with the following extra config,  \n  \n  - CONFIG_KASAN=y  \n  - CONFIG_KASAN_GENERIC=y  \n  - CONFIG_KASAN_INLINE=y  \n  - CONFIG_KASAN_VMALLOC=y  \n  - CONFIG_FRAME_WARN=4096  \n  \nkernel detects that snd_pcm_suspend_all() access a freed  \n'snd_soc_pcm_runtime' object when the system is suspended, which  \nleads to a use-after-free bug:  \n  \n[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270  \n[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330  \n  \n[   52.047785] Call trace:  \n[   52.047787]  dump_backtrace+0x0/0x3c0  \n[   52.047794]  show_stack+0x34/0x50  \n[   52.047797]  dump_stack_lvl+0x68/0x8c  \n[   52.047802]  print_address_description.constprop.0+0x74/0x2c0  \n[   52.047809]  kasan_report+0x210/0x230  \n[   52.047815]  __asan_report_load1_noabort+0x3c/0x50  \n[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270  \n[   52.047824]  snd_soc_suspend+0x19c/0x4e0  \n  \nThe snd_pcm_sync_stop() has a NULL check on 'substream->runtime' before  \nmaking any access. So we need to always set 'substream->runtime' to NULL  \neverytime we kfree() it. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"18 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-18T10:52:32.000000Z"}, {"uuid": "ab64f09b-267b-48ef-a0e8-24ad40de55f6", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46797", "type": "seen", "source": "https://t.me/cvedetector/5931", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46797 - IBM Powerpc qspinlock Deadlock\", \n  \"Content\": \"CVE ID : CVE-2024-46797 \nPublished : Sept. 18, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npowerpc/qspinlock: Fix deadlock in MCS queue  \n  \nIf an interrupt occurs in queued_spin_lock_slowpath() after we increment  \nqnodesp->count and before node->lock is initialized, another CPU might  \nsee stale lock values in get_tail_qnode(). If the stale lock value happens  \nto match the lock on that CPU, then we write to the \"next\" pointer of  \nthe wrong qnode. This causes a deadlock as the former CPU, once it becomes  \nthe head of the MCS queue, will spin indefinitely until it's \"next\" pointer  \nis set by its successor in the queue.  \n  \nRunning stress-ng on a 16 core (16EC/16VP) shared LPAR, results in  \noccasional lockups similar to the following:  \n  \n   $ stress-ng --all 128 --vm-bytes 80% --aggressive \\  \n               --maximize --oomable --verify  --syslog \\  \n               --metrics  --times  --timeout 5m  \n  \n   watchdog: CPU 15 Hard LOCKUP  \n   ......  \n   NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490  \n   LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90  \n   Call Trace:  \n    0xc000002cfffa3bf0 (unreliable)  \n    _raw_spin_lock+0x6c/0x90  \n    raw_spin_rq_lock_nested.part.135+0x4c/0xd0  \n    sched_ttwu_pending+0x60/0x1f0  \n    __flush_smp_call_function_queue+0x1dc/0x670  \n    smp_ipi_demux_relaxed+0xa4/0x100  \n    xive_muxed_ipi_action+0x20/0x40  \n    __handle_irq_event_percpu+0x80/0x240  \n    handle_irq_event_percpu+0x2c/0x80  \n    handle_percpu_irq+0x84/0xd0  \n    generic_handle_irq+0x54/0x80  \n    __do_irq+0xac/0x210  \n    __do_IRQ+0x74/0xd0  \n    0x0  \n    do_IRQ+0x8c/0x170  \n    hardware_interrupt_common_virt+0x29c/0x2a0  \n   --- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490  \n   ......  \n   NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490  \n   LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90  \n   --- interrupt: 500  \n    0xc0000029c1a41d00 (unreliable)  \n    _raw_spin_lock+0x6c/0x90  \n    futex_wake+0x100/0x260  \n    do_futex+0x21c/0x2a0  \n    sys_futex+0x98/0x270  \n    system_call_exception+0x14c/0x2f0  \n    system_call_vectored_common+0x15c/0x2ec  \n  \nThe following code flow illustrates how the deadlock occurs.  \nFor the sake of brevity, assume that both locks (A and B) are  \ncontended and we call the queued_spin_lock_slowpath() function.  \n  \n        CPU0                                   CPU1  \n        ----                                   ----  \n  spin_lock_irqsave(A)                          |  \n  spin_unlock_irqrestore(A)                     |  \n    spin_lock(B)                                |  \n         |                                      |  \n         \u25bc                                      |  \n   id = qnodesp->count++;                       |  \n  (Note that nodes[0].lock == A)                |  \n         |                                      |  \n         \u25bc                                      |  \n      Interrupt                                 |  \n  (happens before \"nodes[0].lock = B\")          |  \n         |                                      |  \n         \u25bc                                      |  \n  spin_lock_irqsave(A)                          |  \n         |                                      |  \n         \u25bc                                      |  \n   id = qnodesp->count++                        |  \n   nodes[1].lock = A                            |  \n         |                                      |  \n         \u25bc                                      |  \n  Tail of MCS queue                             |  \n         |                             spin_lock_irqsave(A)  \n         \u25bc                                      |  \n  Head of MCS queue                             \u25bc  \n         |                             CPU0 is previous tail  \n         \u25bc                                      |  \n   Spin indefinitely                            \u25bc  \n  ([...]", "creation_timestamp": "2024-09-18T10:52:30.000000Z"}, {"uuid": "50033320-f3f3-4fd6-b151-c9c809ea2380", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46795", "type": "seen", "source": "https://t.me/cvedetector/5930", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46795 - Lenovo ksmbd Null Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-46795 \nPublished : Sept. 18, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nksmbd: unset the binding mark of a reused connection  \n  \nSteve French reported null pointer dereference error from sha256 lib.  \ncifs.ko can send session setup requests on reused connection.  \nIf reused connection is used for binding session, conn->binding can  \nstill remain true and generate_preauth_hash() will not set  \nsess->Preauth_HashValue and it will be NULL.  \nIt is used as a material to create an encryption key in  \nksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer  \ndereference error from crypto_shash_update().  \n  \nBUG: kernel NULL pointer dereference, address: 0000000000000000  \n#PF: supervisor read access in kernel mode  \n#PF: error_code(0x0000) - not-present page  \nPGD 0 P4D 0  \nOops: 0000 [#1] PREEMPT SMP PTI  \nCPU: 8 PID: 429254 Comm: kworker/8:39  \nHardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )  \nWorkqueue: ksmbd-io handle_ksmbd_work [ksmbd]  \nRIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]  \n  \n? show_regs+0x6d/0x80  \n? __die+0x24/0x80  \n? page_fault_oops+0x99/0x1b0  \n? do_user_addr_fault+0x2ee/0x6b0  \n? exc_page_fault+0x83/0x1b0  \n? asm_exc_page_fault+0x27/0x30  \n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]  \n? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]  \n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]  \n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]  \n_sha256_update+0x77/0xa0 [sha256_ssse3]  \nsha256_avx2_update+0x15/0x30 [sha256_ssse3]  \ncrypto_shash_update+0x1e/0x40  \nhmac_update+0x12/0x20  \ncrypto_shash_update+0x1e/0x40  \ngenerate_key+0x234/0x380 [ksmbd]  \ngenerate_smb3encryptionkey+0x40/0x1c0 [ksmbd]  \nksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]  \nntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]  \nsmb2_sess_setup+0x952/0xaa0 [ksmbd]  \n__process_request+0xa3/0x1d0 [ksmbd]  \n__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]  \nhandle_ksmbd_work+0x2d/0xa0 [ksmbd]  \nprocess_one_work+0x16c/0x350  \nworker_thread+0x306/0x440  \n? __pfx_worker_thread+0x10/0x10  \nkthread+0xef/0x120  \n? __pfx_kthread+0x10/0x10  \nret_from_fork+0x44/0x70  \n? __pfx_kthread+0x10/0x10  \nret_from_fork_asm+0x1b/0x30 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"18 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-18T10:52:29.000000Z"}, {"uuid": "9661d1d4-a253-4473-9da9-df3a6753510e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46796", "type": "seen", "source": "https://t.me/cvedetector/5928", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46796 - Linux CIFS smb2_set_path_size Double Put Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-46796 \nPublished : Sept. 18, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsmb: client: fix double put of @cfile in smb2_set_path_size()  \n  \nIf smb2_compound_op() is called with a valid @cfile and returned  \n-EINVAL, we need to call cifs_get_writable_path() before retrying it  \nas the reference of @cfile was already dropped by previous call.  \n  \nThis fixes the following KASAN splat when running fstests generic/013  \nagainst Windows Server 2022:  \n  \n  CIFS: Attempting to mount //w22-fs0/scratch  \n  run fstests generic/013 at 2024-09-02 19:48:59  \n  ==================================================================  \n  BUG: KASAN: slab-use-after-free in detach_if_pending+0xab/0x200  \n  Write of size 8 at addr ffff88811f1a3730 by task kworker/3:2/176  \n  \n  CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 Not tainted 6.11.0-rc6 #2  \n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40  \n  04/01/2014  \n  Workqueue: cifsoplockd cifs_oplock_break [cifs]  \n  Call Trace:  \n     \n   dump_stack_lvl+0x5d/0x80  \n   ? detach_if_pending+0xab/0x200  \n   print_report+0x156/0x4d9  \n   ? detach_if_pending+0xab/0x200  \n   ? __virt_addr_valid+0x145/0x300  \n   ? __phys_addr+0x46/0x90  \n   ? detach_if_pending+0xab/0x200  \n   kasan_report+0xda/0x110  \n   ? detach_if_pending+0xab/0x200  \n   detach_if_pending+0xab/0x200  \n   timer_delete+0x96/0xe0  \n   ? __pfx_timer_delete+0x10/0x10  \n   ? rcu_is_watching+0x20/0x50  \n   try_to_grab_pending+0x46/0x3b0  \n   __cancel_work+0x89/0x1b0  \n   ? __pfx___cancel_work+0x10/0x10  \n   ? kasan_save_track+0x14/0x30  \n   cifs_close_deferred_file+0x110/0x2c0 [cifs]  \n   ? __pfx_cifs_close_deferred_file+0x10/0x10 [cifs]  \n   ? __pfx_down_read+0x10/0x10  \n   cifs_oplock_break+0x4c1/0xa50 [cifs]  \n   ? __pfx_cifs_oplock_break+0x10/0x10 [cifs]  \n   ? lock_is_held_type+0x85/0xf0  \n   ? mark_held_locks+0x1a/0x90  \n   process_one_work+0x4c6/0x9f0  \n   ? find_held_lock+0x8a/0xa0  \n   ? __pfx_process_one_work+0x10/0x10  \n   ? lock_acquired+0x220/0x550  \n   ? __list_add_valid_or_report+0x37/0x100  \n   worker_thread+0x2e4/0x570  \n   ? __kthread_parkme+0xd1/0xf0  \n   ? __pfx_worker_thread+0x10/0x10  \n   kthread+0x17f/0x1c0  \n   ? kthread+0xda/0x1c0  \n   ? __pfx_kthread+0x10/0x10  \n   ret_from_fork+0x31/0x60  \n   ? __pfx_kthread+0x10/0x10  \n   ret_from_fork_asm+0x1a/0x30  \n     \n  \n  Allocated by task 1118:  \n   kasan_save_stack+0x30/0x50  \n   kasan_save_track+0x14/0x30  \n   __kasan_kmalloc+0xaa/0xb0  \n   cifs_new_fileinfo+0xc8/0x9d0 [cifs]  \n   cifs_atomic_open+0x467/0x770 [cifs]  \n   lookup_open.isra.0+0x665/0x8b0  \n   path_openat+0x4c3/0x1380  \n   do_filp_open+0x167/0x270  \n   do_sys_openat2+0x129/0x160  \n   __x64_sys_creat+0xad/0xe0  \n   do_syscall_64+0xbb/0x1d0  \n   entry_SYSCALL_64_after_hwframe+0x77/0x7f  \n  \n  Freed by task 83:  \n   kasan_save_stack+0x30/0x50  \n   kasan_save_track+0x14/0x30  \n   kasan_save_free_info+0x3b/0x70  \n   poison_slab_object+0xe9/0x160  \n   __kasan_slab_free+0x32/0x50  \n   kfree+0xf2/0x300  \n   process_one_work+0x4c6/0x9f0  \n   worker_thread+0x2e4/0x570  \n   kthread+0x17f/0x1c0  \n   ret_from_fork+0x31/0x60  \n   ret_from_fork_asm+0x1a/0x30  \n  \n  Last potentially related work creation:  \n   kasan_save_stack+0x30/0x50  \n   __kasan_record_aux_stack+0xad/0xc0  \n   insert_work+0x29/0xe0  \n   __queue_work+0x5ea/0x760  \n   queue_work_on+0x6d/0x90  \n   _cifsFileInfo_put+0x3f6/0x770 [cifs]  \n   smb2_compound_op+0x911/0x3940 [cifs]  \n   smb2_set_path_size+0x228/0x270 [cifs]  \n   cifs_set_file_size+0x197/0x460 [cifs]  \n   cifs_setattr+0xd9c/0x14b0 [cifs]  \n   notify_change+0x4e3/0x740  \n   do_truncate+0xfa/0x180  \n   vfs_truncate+0x195/0x200  \n   __x64_sys_truncate+0x109/0x150  \n   do_syscall_64+0xbb/0x1d0  \n   entry_SYSCALL_64_after_hwframe+0x77/0x7f \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details[...]", "creation_timestamp": "2024-09-18T10:52:25.000000Z"}, {"uuid": "b87aca23-7a1a-4b1f-8bec-dba2c21f042f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46793", "type": "seen", "source": "https://t.me/cvedetector/5927", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46793 - Intel ASoC Linux Kernel NULL Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-46793 \nPublished : Sept. 18, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards harder  \n  \nSince commit 13f58267cda3 (\"ASoC: soc.h: don't create dummy Component  \nvia COMP_DUMMY()\") dummy codecs declared like this:  \n  \nSND_SOC_DAILINK_DEF(dummy,  \n        DAILINK_COMP_ARRAY(COMP_DUMMY()));  \n  \nexpand to:  \n  \nstatic struct snd_soc_dai_link_component dummy[] = {  \n};  \n  \nWhich means that dummy is a zero sized array and thus dais[i].codecs should  \nnot be dereferenced *at all* since it points to the address of the next  \nvariable stored in the data section as the \"dummy\" variable has an address  \nbut no size, so even dereferencing dais[0] is already an out of bounds  \narray reference.  \n  \nWhich means that the if (dais[i].codecs->name) check added in  \ncommit 7d99a70b6595 (\"ASoC: Intel: Boards: Fix NULL pointer deref  \nin BYT/CHT boards\") relies on that the part of the next variable which  \nthe name member maps to just happens to be NULL.  \n  \nWhich apparently so far it usually is, except when it isn't  \nand then it results in crashes like this one:  \n  \n[   28.795659] BUG: unable to handle page fault for address: 0000000000030011  \n...  \n[   28.795780] Call Trace:  \n[   28.795787]    \n...  \n[   28.795862]  ? strcmp+0x18/0x40  \n[   28.795872]  0xffffffffc150c605  \n[   28.795887]  platform_probe+0x40/0xa0  \n...  \n[   28.795979]  ? __pfx_init_module+0x10/0x10 [snd_soc_sst_bytcr_wm5102]  \n  \nReally fix things this time around by checking dais.num_codecs != 0. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"18 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-18T10:52:24.000000Z"}, {"uuid": "05a4146f-955b-4380-a564-bb09902ca890", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46792", "type": "seen", "source": "https://t.me/cvedetector/5925", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46792 - Linux Kernel RISC-V Kernel Memory Information Disclosure\", \n  \"Content\": \"CVE ID : CVE-2024-46792 \nPublished : Sept. 18, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nriscv: misaligned: Restrict user access to kernel memory  \n  \nraw_copy_{to,from}_user() do not call access_ok(), so this code allowed  \nuserspace to access any virtual memory address. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"18 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-18T10:52:22.000000Z"}, {"uuid": "f65e551f-2d40-4af5-9cb8-97e97d58e681", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-46794", "type": "seen", "source": "https://t.me/cvedetector/5926", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-46794 - Linux Kernel TDX x86 Memory Leak\", \n  \"Content\": \"CVE ID : CVE-2024-46794 \nPublished : Sept. 18, 2024, 8:15 a.m. | 35\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nx86/tdx: Fix data leak in mmio_read()  \n  \nThe mmio_read() function makes a TDVMCALL to retrieve MMIO data for an  \naddress from the VMM.  \n  \nSean noticed that mmio_read() unintentionally exposes the value of an  \ninitialized variable (val) on the stack to the VMM.  \n  \nThis variable is only needed as an output value. It did not need to be  \npassed to the VMM in the first place.  \n  \nDo not send the original value of *val to the VMM.  \n  \n[ dhansen: clarify what 'val' is used for. ] \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"18 Sep 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-09-18T10:52:23.000000Z"}]}