{"vulnerability": "cve-2024-5313", "sightings": [{"uuid": "112a5005-cf3e-4430-ad39-5bb632e56b7f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53133", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113595081699257338", "content": "", "creation_timestamp": "2024-12-04T14:43:10.812224Z"}, {"uuid": "66ba1341-584b-492e-bdd2-04c5f4b761fa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53139", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113595199784191253", "content": "", "creation_timestamp": "2024-12-04T15:13:12.651781Z"}, {"uuid": "dfc3f0d0-4e0c-41fe-919b-2350c701e8c5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53139", "type": "seen", "source": "https://infosec.exchange/users/vuldb/statuses/113595327039362865", "content": "", "creation_timestamp": "2024-12-04T15:45:34.137902Z"}, {"uuid": "090d0ed5-ef2f-46f8-a6e6-3a0a5d917dbf", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53134", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113595140697373279", "content": "", "creation_timestamp": "2024-12-04T14:58:10.921496Z"}, {"uuid": "84de25fc-144e-42a3-a813-5abcd5c19b88", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53136", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113595140754180549", "content": "", "creation_timestamp": "2024-12-04T14:58:11.763178Z"}, {"uuid": "f8553a0d-2794-44bc-a3fd-2ab646662573", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53135", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113595140711344348", "content": "", "creation_timestamp": "2024-12-04T14:58:11.186316Z"}, {"uuid": "d863c3a4-f26c-4ee6-88f8-393b95fc2a27", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53130", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113595081655798635", "content": "", "creation_timestamp": "2024-12-04T14:43:10.010367Z"}, {"uuid": "0f34cfce-3959-4ac9-a35c-d4016ff006b1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53131", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113595081669502305", "content": "", "creation_timestamp": "2024-12-04T14:43:10.275198Z"}, {"uuid": "1fc9d592-9582-4930-b48a-ba1f5c365962", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53132", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113595081684672683", "content": "", "creation_timestamp": "2024-12-04T14:43:10.707116Z"}, {"uuid": "0660e17e-0351-4c00-b47e-d33280ab508d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53138", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113595199769208127", "content": "", "creation_timestamp": "2024-12-04T15:13:12.338321Z"}, {"uuid": "2f43fafb-c09a-4066-bccd-d83ca0fc9d38", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53137", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113595140768068337", "content": "", "creation_timestamp": "2024-12-04T14:58:12.084407Z"}, {"uuid": "77ae113f-e2c4-4198-aa93-21c2624dce2a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53130", "type": "seen", "source": "https://t.me/cvedetector/12004", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-53130 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-53130 \nPublished : Dec. 4, 2024, 3:15 p.m. | 18\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint  \n  \nWhen using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty()  \nmay cause a NULL pointer dereference, or a general protection fault when  \nKASAN is enabled.  \n  \nThis happens because, since the tracepoint was added in  \nmark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev  \nregardless of whether the buffer head has a pointer to a block_device  \nstructure.  \n  \nIn the current implementation, nilfs_grab_buffer(), which grabs a buffer  \nto read (or create) a block of metadata, including b-tree node blocks,  \ndoes not set the block device, but instead does so only if the buffer is  \nnot in the \"uptodate\" state for each of its caller block reading  \nfunctions.  However, if the uptodate flag is set on a folio/page, and the  \nbuffer heads are detached from it by try_to_free_buffers(), and new buffer  \nheads are then attached by create_empty_buffers(), the uptodate flag may  \nbe restored to each buffer without the block device being set to  \nbh->b_bdev, and mark_buffer_dirty() may be called later in that state,  \nresulting in the bug mentioned above.  \n  \nFix this issue by making nilfs_grab_buffer() always set the block device  \nof the super block structure to the buffer head, regardless of the state  \nof the buffer's uptodate flag. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-04T16:45:40.000000Z"}, {"uuid": "06dbfcad-ce1a-470d-80e5-72b2602f65a0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-53133", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "8f0c5920-e202-4e4c-8d85-ade745b89c67", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53138", "type": "seen", "source": "https://t.me/cvedetector/12001", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-53138 - Linux Melanox mlx5e kTLS Page Reference Counting Memory Leak\", \n  \"Content\": \"CVE ID : CVE-2024-53138 \nPublished : Dec. 4, 2024, 3:15 p.m. | 18\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet/mlx5e: kTLS, Fix incorrect page refcounting  \n  \nThe kTLS tx handling code is using a mix of get_page() and  \npage_ref_inc() APIs to increment the page reference. But on the release  \npath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.  \n  \nThis is an issue when using pages from large folios: the get_page()  \nreferences are stored on the folio page while the page_ref_inc()  \nreferences are stored directly in the given page. On release the folio  \npage will be dereferenced too many times.  \n  \nThis was found while doing kTLS testing with sendfile() + ZC when the  \nserved file was read from NFS on a kernel with NFS large folios support  \n(commit 49b29a573da8 (\"nfs: add support for large folios\")). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-04T16:45:35.000000Z"}, {"uuid": "37d8bc22-719f-4234-aec4-d10845455d13", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53137", "type": "seen", "source": "https://t.me/cvedetector/12000", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-53137 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-53137 \nPublished : Dec. 4, 2024, 3:15 p.m. | 18\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nARM: fix cacheflush with PAN  \n  \nIt seems that the cacheflush syscall got broken when PAN for LPAE was  \nimplemented. User access was not enabled around the cache maintenance  \ninstructions, causing them to fault. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-04T16:45:34.000000Z"}, {"uuid": "58e7577f-8b7f-4975-8f8b-21f6a0c39d8c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53136", "type": "seen", "source": "https://t.me/cvedetector/11999", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-53136 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-53136 \nPublished : Dec. 4, 2024, 3:15 p.m. | 18\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm: revert \"mm: shmem: fix data-race in shmem_getattr()\"  \n  \nRevert d949d1d14fa2 (\"mm: shmem: fix data-race in shmem_getattr()\") as  \nsuggested by Chuck [1].  It is causing deadlocks when accessing tmpfs over  \nNFS.  \n  \nAs Hugh commented, \"added just to silence a syzbot sanitizer splat: added  \nwhere there has never been any practical problem\". \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-04T16:45:33.000000Z"}, {"uuid": "3aed90bc-c6dd-4728-ab27-97f3a46e6a23", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53135", "type": "seen", "source": "https://t.me/cvedetector/11998", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-53135 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-53135 \nPublished : Dec. 4, 2024, 3:15 p.m. | 18\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nKVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN  \n  \nHide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support  \nfor virtualizing Intel PT via guest/host mode unless BROKEN=y.  There are  \nmyriad bugs in the implementation, some of which are fatal to the guest,  \nand others which put the stability and health of the host at risk.  \n  \nFor guest fatalities, the most glaring issue is that KVM fails to ensure  \ntracing is disabled, and *stays* disabled prior to VM-Enter, which is  \nnecessary as hardware disallows loading (the guest's) RTIT_CTL if tracing  \nis enabled (enforced via a VMX consistency check).  Per the SDM:  \n  \n  If the logical processor is operating with Intel PT enabled (if  \n  IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load  \n  IA32_RTIT_CTL\" VM-entry control must be 0.  \n  \nOn the host side, KVM doesn't validate the guest CPUID configuration  \nprovided by userspace, and even worse, uses the guest configuration to  \ndecide what MSRs to save/load at VM-Enter and VM-Exit.  E.g. configuring  \nguest CPUID to enumerate more address ranges than are supported in hardware  \nwill result in KVM trying to passthrough, save, and load non-existent MSRs,  \nwhich generates a variety of WARNs, ToPA ERRORs in the host, a potential  \ndeadlock, etc. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-04T16:45:33.000000Z"}, {"uuid": "7fb8a182-8bf5-413a-87de-7a52d6df1cfa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53133", "type": "seen", "source": "https://t.me/cvedetector/11996", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-53133 - AMD Display Double Free Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-53133 \nPublished : Dec. 4, 2024, 3:15 p.m. | 18\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/amd/display: Handle dml allocation failure to avoid crash  \n  \n[Why]  \nIn the case where a dml allocation fails for any reason, the  \ncurrent state's dml contexts would no longer be valid. Then  \nsubsequent calls dc_state_copy_internal would shallow copy  \ninvalid memory and if the new state was released, a double  \nfree would occur.  \n  \n[How]  \nReset dml pointers in new_state to NULL and avoid invalid  \npointer  \n  \n(cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c) \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-04T16:45:28.000000Z"}, {"uuid": "4362b48c-88ad-424f-9f26-348ee024b1cb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53134", "type": "seen", "source": "https://t.me/cvedetector/11997", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-53134 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-53134 \nPublished : Dec. 4, 2024, 3:15 p.m. | 18\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npmdomain: imx93-blk-ctrl: correct remove path  \n  \nThe check condition should be 'i < bc->onecell_data.num_domains', not  \n'bc->onecell_data.num_domains' which will make the look never finish  \nand cause kernel panic.  \n  \nAlso disable runtime to address  \n\"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\" \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-04T16:45:32.000000Z"}, {"uuid": "6719d7e0-2d8f-49df-aa2f-4cfad8a139de", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53132", "type": "seen", "source": "https://t.me/cvedetector/11995", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-53132 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-53132 \nPublished : Dec. 4, 2024, 3:15 p.m. | 18\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/xe/oa: Fix \"Missing outer runtime PM protection\" warning  \n  \nFix the following drm_WARN:  \n  \n[953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection  \n... <4[953.587090]  ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4[953.587208]  guc_exec_queue_add_msg+0x28/0x130 [xe] <4[953.587319]  guc_exec_queue_fini+0x3a/0x40 [xe] <4[953.587425]  xe_exec_queue_destroy+0xb3/0xf0 [xe] <4[953.587515]  xe_oa_release+0x9c/0xc0 [xe]  \n  \n(cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75) \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-04T16:45:27.000000Z"}, {"uuid": "3f0ba274-b717-4935-9a19-45514af3dae3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53131", "type": "seen", "source": "https://t.me/cvedetector/11994", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-53131 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-53131 \nPublished : Dec. 4, 2024, 3:15 p.m. | 18\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnilfs2: fix null-ptr-deref in block_touch_buffer tracepoint  \n  \nPatch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\".  \n  \nThis series fixes null pointer dereference bugs that occur when using  \nnilfs2 and two block-related tracepoints.  \n  \n  \nThis patch (of 2):  \n  \nIt has been reported that when using \"block:block_touch_buffer\"  \ntracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a  \nNULL pointer dereference, or a general protection fault when KASAN is  \nenabled.  \n  \nThis happens because since the tracepoint was added in touch_buffer(), it  \nreferences the dev_t member bh->b_bdev->bd_dev regardless of whether the  \nbuffer head has a pointer to a block_device structure.  In the current  \nimplementation, the block_device structure is set after the function  \nreturns to the caller.  \n  \nHere, touch_buffer() is used to mark the folio/page that owns the buffer  \nhead as accessed, but the common search helper for folio/page used by the  \ncaller function was optimized to mark the folio/page as accessed when it  \nwas reimplemented a long time ago, eliminating the need to call  \ntouch_buffer() here in the first place.  \n  \nSo this solves the issue by eliminating the touch_buffer() call itself. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-04T16:45:27.000000Z"}, {"uuid": "06fa41fb-fb5f-4359-a701-33fb99f5accd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-53139", "type": "seen", "source": "https://t.me/cvedetector/11993", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-53139 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-53139 \nPublished : Dec. 4, 2024, 3:15 p.m. | 18\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsctp: fix possible UAF in sctp_v6_available()  \n  \nA lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints  \nthat sctp_v6_available() is calling dev_get_by_index_rcu()  \nand ipv6_chk_addr() without holding rcu.  \n  \n[1]  \n =============================  \n WARNING: suspicious RCU usage  \n 6.12.0-rc5-virtme #1216 Tainted: G        W  \n -----------------------------  \n net/core/dev.c:876 RCU-list traversed in non-reader section!!  \n  \nother info that might help us debug this:  \n  \nrcu_scheduler_active = 2, debug_locks = 1  \n 1 lock held by sctp_hello/31495:  \n #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp  \n  \nstack backtrace:  \n CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G        W          6.12.0-rc5-virtme #1216  \n Tainted: [W]=WARN  \n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014  \n Call Trace:  \n    \n dump_stack_lvl (lib/dump_stack.c:123)  \n lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)  \n dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7))  \n sctp_v6_available (net/sctp/ipv6.c:701) sctp  \n sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp  \n sctp_bind (net/sctp/socket.c:320) sctp  \n inet6_bind_sk (net/ipv6/af_inet6.c:465)  \n ? security_socket_bind (security/security.c:4581 (discriminator 1))  \n __sys_bind (net/socket.c:1848 net/socket.c:1869)  \n ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340)  \n ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13))  \n __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1))  \n do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))  \n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)  \n RIP: 0033:0x7f59b934a1e7  \n Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <483d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48  \nAll code  \n========  \n   0: 44 00 00              add    %r8b,(%rax)  \n   3: 48 8b 15 39 8c 0c 00  mov    0xc8c39(%rip),%rdx        # 0xc8c43  \n   a: f7 d8                 neg    %eax  \n   c: 64 89 02              mov    %eax,%fs:(%rdx)  \n   f: b8 ff ff ff ff        mov    $0xffffffff,%eax  \n  14: eb bd                 jmp    0xffffffffffffffd3  \n  16: 66 2e 0f 1f 84 00 00  cs nopw 0x0(%rax,%rax,1)  \n  1d: 00 00 00  \n  20: 0f 1f 00              nopl   (%rax)  \n  23: b8 31 00 00 00        mov    $0x31,%eax  \n  28: 0f 05                 syscall  \n  2a:* 48 3d 01 f0 ff ff     cmp    $0xfffffffffffff001,%rax <--\nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"04 Dec 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-12-04T16:45:26.000000Z"}]}