{"vulnerability": "cve-2024-4493", "sightings": [{"uuid": "c963c8b5-c01d-43f8-821b-a5781e5f180f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44930", "type": "seen", "source": "https://t.me/cvedetector/4441", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44930 - Serilog Client IP Spoofing Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-44930 \nPublished : Aug. 29, 2024, 6:15 p.m. | 44\u00a0minutes ago \nDescription : Serilog before v2.1.0 was discovered to contain a Client IP Spoofing vulnerability, which allows attackers to falsify their IP addresses by specifying an arbitrary IP as a value of X-Forwarded-For or Client-Ip headers while performing HTTP requests. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"29 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-29T21:14:44.000000Z"}, {"uuid": "e20df464-c98b-4733-af0d-0145233309e9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44935", "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": "1ce74025-ed21-4a53-a39d-35aac58ccec8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-44938", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "8b08c11d-38c8-4470-82c4-1378adbe3a5e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-44939", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "39c10b11-4b75-4e0b-a514-fb0ba50c2085", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44938", "type": "seen", "source": "https://t.me/cvedetector/4136", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44938 - Linux Kernel JFS ArrayIndexOutOfBoundsException\", \n  \"Content\": \"CVE ID : CVE-2024-44938 \nPublished : Aug. 26, 2024, 12:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \njfs: Fix shift-out-of-bounds in dbDiscardAG  \n  \nWhen searching for the next smaller log2 block, BLKSTOL2() returned 0,  \ncausing shift exponent -1 to be negative.  \n  \nThis patch fixes the issue by exiting the loop directly when negative  \nshift is found. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"26 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-26T15:23:56.000000Z"}, {"uuid": "03bc6fa2-548b-4212-88c8-cb42506437ba", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44936", "type": "seen", "source": "https://t.me/cvedetector/4111", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44936 - \"Linux RT5033 Power Supply: Missing i2c Set Clientdata Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-44936 \nPublished : Aug. 26, 2024, 11:15 a.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \npower: supply: rt5033: Bring back i2c_set_clientdata  \n  \nCommit 3a93da231c12 (\"power: supply: rt5033: Use devm_power_supply_register() helper\")  \nreworked the driver to use devm. While at it, the i2c_set_clientdata  \nwas dropped along with the remove callback. Unfortunately other parts  \nof the driver also rely on i2c clientdata so this causes kernel oops.  \n  \nBring the call back to fix the driver. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"26 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-26T13:42:35.000000Z"}, {"uuid": "f0ba9473-f852-4904-a0df-9d45bb654664", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44939", "type": "seen", "source": "https://t.me/cvedetector/4134", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44939 - Linux Kernel JFS Null Pointer Dereference\", \n  \"Content\": \"CVE ID : CVE-2024-44939 \nPublished : Aug. 26, 2024, 12:15 p.m. | 42\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \njfs: fix null ptr deref in dtInsertEntry  \n  \n[syzbot reported]  \ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI  \nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]  \nCPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0  \nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024  \nRIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713  \n...  \n[Analyze]  \nIn dtInsertEntry(), when the pointer h has the same value as p, after writing  \nname in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause the  \npreviously true judgment \"p->header.flag & BT-LEAF\" to change to no after writing  \nthe name operation, this leads to entering an incorrect branch and accessing the  \nuninitialized object ih when judging this condition for the second time.  \n  \n[Fix]  \nAfter got the page, check freelist first, if freelist == 0 then exit dtInsert()  \nand return -EINVAL. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"26 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-26T15:23:52.000000Z"}, {"uuid": "8e7f5716-d639-4b01-a286-4b5612b8907e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44931", "type": "seen", "source": "https://t.me/cvedetector/4122", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44931 - Linux Kernel GPIO Spectre Information Leak\", \n  \"Content\": \"CVE ID : CVE-2024-44931 \nPublished : Aug. 26, 2024, 11:15 a.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ngpio: prevent potential speculation leaks in gpio_device_get_desc()  \n  \nUserspace may trigger a speculative read of an address outside the gpio  \ndescriptor array.  \nUsers can do that by calling gpio_ioctl() with an offset out of range.  \nOffset is copied from user and then used as an array index to get  \nthe gpio descriptor without sanitization in gpio_device_get_desc().  \n  \nThis change ensures that the offset is sanitized by using  \narray_index_nospec() to mitigate any possibility of speculative  \ninformation leaks.  \n  \nThis bug was discovered and resolved using Coverity Static Analysis  \nSecurity Testing (SAST) by Synopsys, Inc. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"26 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-26T13:42:51.000000Z"}, {"uuid": "c6b4098a-767e-4200-8e25-4385751e26d3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44932", "type": "seen", "source": "https://t.me/cvedetector/4120", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44932 - Linux Kernel idpf Use-After-Free Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-44932 \nPublished : Aug. 26, 2024, 11:15 a.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nidpf: fix UAFs when destroying the queues  \n  \nThe second tagged commit started sometimes (very rarely, but possible)  \nthrowing WARNs from  \nnet/core/page_pool.c:page_pool_disable_direct_recycling().  \nTurned out idpf frees interrupt vectors with embedded NAPIs *before*  \nfreeing the queues making page_pools' NAPI pointers lead to freed  \nmemory before these pools are destroyed by libeth.  \nIt's not clear whether there are other accesses to the freed vectors  \nwhen destroying the queues, but anyway, we usually free queue/interrupt  \nvectors only when the queues are destroyed and the NAPIs are guaranteed  \nto not be referenced anywhere.  \n  \nInvert the allocation and freeing logic making queue/interrupt vectors  \nbe allocated first and freed last. Vectors don't require queues to be  \npresent, so this is safe. Additionally, this change allows to remove  \nthat useless queue->q_vector pointer cleanup, as vectors are still  \nvalid when freeing the queues (+ both are freed within one function,  \nso it's not clear why nullify the pointers at all). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"26 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-26T13:42:50.000000Z"}, {"uuid": "1384a0d1-eb14-40bc-a252-60d539ae08bb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44933", "type": "seen", "source": "https://t.me/cvedetector/4118", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44933 - \"BNXT Linux Kernel Memory Out-of-Bounds Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-44933 \nPublished : Aug. 26, 2024, 11:15 a.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbnxt_en : Fix memory out-of-bounds in bnxt_fill_hw_rss_tbl()  \n  \nA recent commit has modified the code in __bnxt_reserve_rings() to  \nset the default RSS indirection table to default only when the number  \nof RX rings is changing.  While this works for newer firmware that  \nrequires RX ring reservations, it causes the regression on older  \nfirmware not requiring RX ring resrvations (BNXT_NEW_RM() returns  \nfalse).  \n  \nWith older firmware, RX ring reservations are not required and so  \nhw_resc->resv_rx_rings is not always set to the proper value.  The  \ncomparison:  \n  \nif (old_rx_rings != bp->hw_resc.resv_rx_rings)  \n  \nin __bnxt_reserve_rings() may be false even when the RX rings are  \nchanging.  This will cause __bnxt_reserve_rings() to skip setting  \nthe default RSS indirection table to default to match the current  \nnumber of RX rings.  This may later cause bnxt_fill_hw_rss_tbl() to  \nuse an out-of-range index.  \n  \nWe already have bnxt_check_rss_tbl_no_rmgr() to handle exactly this  \nscenario.  We just need to move it up in bnxt_need_reserve_rings()  \nto be called unconditionally when using older firmware.  Without the  \nfix, if the TX rings are changing, we'll skip the  \nbnxt_check_rss_tbl_no_rmgr() call and __bnxt_reserve_rings() may also  \nskip the bnxt_set_dflt_rss_indir_tbl() call for the reason explained  \nin the last paragraph.  Without setting the default RSS indirection  \ntable to default, it causes the regression:  \n  \nBUG: KASAN: slab-out-of-bounds in __bnxt_hwrm_vnic_set_rss+0xb79/0xe40  \nRead of size 2 at addr ffff8881c5809618 by task ethtool/31525  \nCall Trace:  \n__bnxt_hwrm_vnic_set_rss+0xb79/0xe40  \n bnxt_hwrm_vnic_rss_cfg_p5+0xf7/0x460  \n __bnxt_setup_vnic_p5+0x12e/0x270  \n __bnxt_open_nic+0x2262/0x2f30  \n bnxt_open_nic+0x5d/0xf0  \n ethnl_set_channels+0x5d4/0xb30  \n ethnl_default_set_doit+0x2f1/0x620 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"26 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-26T13:42:45.000000Z"}, {"uuid": "ba81de14-b615-4ce2-9c7d-2125beab91c5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44934", "type": "seen", "source": "https://t.me/cvedetector/4116", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44934 - \"Fortinet Linux Kernel Bridge Multicast Use-After-Free Vulnerability\"\", \n  \"Content\": \"CVE ID : CVE-2024-44934 \nPublished : Aug. 26, 2024, 11:15 a.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: bridge: mcast: wait for previous gc cycles when removing port  \n  \nsyzbot hit a use-after-free[1] which is caused because the bridge doesn't  \nmake sure that all previous garbage has been collected when removing a  \nport. What happens is:  \n      CPU 1                   CPU 2  \n start gc cycle           remove port  \n                         acquire gc lock first  \n wait for lock  \n                         call br_multicasg_gc() directly  \n acquire lock now but    free port  \n the port can be freed  \n while grp timers still  \n running  \n  \nMake sure all previous gc cycles have finished by using flush_work before  \nfreeing the port.  \n  \n[1]  \n  BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861  \n  Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699  \n  \n  CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0  \n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024  \n  Call Trace:  \n     \n   __dump_stack lib/dump_stack.c:88 [inline]  \n   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114  \n   print_address_description mm/kasan/report.c:377 [inline]  \n   print_report+0xc3/0x620 mm/kasan/report.c:488  \n   kasan_report+0xd9/0x110 mm/kasan/report.c:601  \n   br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861  \n   call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792  \n   expire_timers kernel/time/timer.c:1843 [inline]  \n   __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417  \n   __run_timer_base kernel/time/timer.c:2428 [inline]  \n   __run_timer_base kernel/time/timer.c:2421 [inline]  \n   run_timer_base+0x111/0x190 kernel/time/timer.c:2437 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"26 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-26T13:42:43.000000Z"}, {"uuid": "7a65dba7-5062-40fc-9e57-bb996144d939", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44937", "type": "seen", "source": "https://t.me/cvedetector/4115", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44937 - Dell Venue 7140 Intel Virtual Switches Linux Kernel Double Registration Remote Code Execution Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-44937 \nPublished : Aug. 26, 2024, 11:15 a.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nplatform/x86: intel-vbtn: Protect ACPI notify handler against recursion  \n  \nSince commit e2ffcda16290 (\"ACPI: OSL: Allow Notify () handlers to run on  \nall CPUs\") ACPI notify handlers like the intel-vbtn notify_handler() may  \nrun on multiple CPU cores racing with themselves.  \n  \nThis race gets hit on Dell Venue 7140 tablets when undocking from  \nthe keyboard, causing the handler to try and register priv->switches_dev  \ntwice, as can be seen from the dev_info() message getting logged twice:  \n  \n[ 83.861800] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event  \n[ 83.861858] input: Intel Virtual Switches as /devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17  \n[ 83.861865] intel-vbtn INT33D6:00: Registering Intel Virtual Switches input-dev after receiving a switch event  \n  \nAfter which things go seriously wrong:  \n[ 83.861872] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1f.0/PNP0C09:00/INT33D6:00/input/input17'  \n...  \n[ 83.861967] kobject: kobject_add_internal failed for input17 with -EEXIST, don't try to register things with the same name in the same directory.  \n[ 83.877338] BUG: kernel NULL pointer dereference, address: 0000000000000018  \n...  \n  \nProtect intel-vbtn notify_handler() from racing with itself with a mutex  \nto fix this. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"26 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-26T13:42:42.000000Z"}, {"uuid": "58dd2c0c-18ce-40c8-8090-2361d9349472", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-44935", "type": "seen", "source": "https://t.me/cvedetector/4113", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-44935 - Linux Kernel SCTP Null-Ptr-Deref Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-44935 \nPublished : Aug. 26, 2024, 11:15 a.m. | 21\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nsctp: Fix null-ptr-deref in reuseport_add_sock().  \n  \nsyzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in  \nreuseport_add_sock(). [0]  \n  \nThe repro first creates a listener with SO_REUSEPORT.  Then, it creates  \nanother listener on the same port and concurrently closes the first  \nlistener.  \n  \nThe second listen() calls reuseport_add_sock() with the first listener as  \nsk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently,  \nbut the close() does clear it by reuseport_detach_sock().  \n  \nThe problem is SCTP does not properly synchronise reuseport_alloc(),  \nreuseport_add_sock(), and reuseport_detach_sock().  \n  \nThe caller of reuseport_alloc() and reuseport_{add,detach}_sock() must  \nprovide synchronisation for sockets that are classified into the same  \nreuseport group.  \n  \nOtherwise, such sockets form multiple identical reuseport groups, and  \nall groups except one would be silently dead.  \n  \n  1. Two sockets call listen() concurrently  \n  2. No socket in the same group found in sctp_ep_hashtable[]  \n  3. Two sockets call reuseport_alloc() and form two reuseport groups  \n  4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives  \n      incoming packets  \n  \nAlso, the reported null-ptr-deref could occur.  \n  \nTCP/UDP guarantees that would not happen by holding the hash bucket lock.  \n  \nLet's apply the locking strategy to __sctp_hash_endpoint() and  \n__sctp_unhash_endpoint().  \n  \n[0]:  \nOops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI  \nKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]  \nCPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0  \nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024  \nRIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350  \nCode: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03  0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14  \nRSP: 0018:ffffc9000b947c98 EFLAGS: 00010202  \nRAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000  \nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012  \nRBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385  \nR10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0  \nR13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000  \nFS:  00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000  \nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \nCR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0  \nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  \n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  \nCall Trace:  \n   \n __sctp_hash_endpoint net/sctp/input.c:762 [inline]  \n sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790  \n sctp_listen_start net/sctp/socket.c:8570 [inline]  \n sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625  \n __sys_listen_socket net/socket.c:1883 [inline]  \n __sys_listen+0x1b7/0x230 net/socket.c:1894  \n __do_sys_listen net/socket.c:1902 [inline]  \n __se_sys_listen net/socket.c:1900 [inline]  \n __x64_sys_listen+0x5a/0x70 net/socket.c:1900  \n do_syscall_x64 arch/x86/entry/common.c:52 [inline]  \n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  \n entry_SYSCALL_64_after_hwframe+0x77/0x7f  \nRIP: 0033:0x7f24e46039b9  \nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05  3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48  \nRSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000[...]", "creation_timestamp": "2024-08-26T13:42:37.000000Z"}]}