{"vulnerability": "CVE-2024-4224", "sightings": [{"uuid": "0ce14a59-70ed-40a3-afe8-00d542480508", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-4224", "type": "seen", "source": "http://takeonme.org/cve/", "content": "", "creation_timestamp": "2000-12-31T23:00:00.000000Z"}, {"uuid": "056b7937-a0a8-4228-9ef4-b9b7f766a2c3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42244", "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": "63de7d64-2075-498f-8ba9-2149b41e84f7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42247", "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": "12641a9a-2a9a-44c7-ac53-0e1be9031b79", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-42244", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "1a4b5bc4-a27a-464b-8eeb-72054dc9e2f8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-4224", "type": "seen", "source": "http://takeonme.org/cves/cve-2024-4224/", "content": "", "creation_timestamp": "2024-07-15T17:34:53.000000Z"}, {"uuid": "3ae1a292-35de-4f38-b6df-f18453a9be72", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42247", "type": "seen", "source": "https://t.me/cvedetector/2700", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42247 - Wireguard Linux Kernel Unaligned Memory Access Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42247 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nwireguard: allowedips: avoid unaligned 64-bit memory accesses  \n  \nOn the parisc platform, the kernel issues kernel warnings because  \nswap_endian() tries to load a 128-bit IPv6 address from an unaligned  \nmemory location:  \n  \n Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)  \n Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)  \n  \nAvoid such unaligned memory accesses by instead using the  \nget_unaligned_be64() helper macro.  \n  \n[Jason: replace src[8] in original patch with src+8] \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:38.000000Z"}, {"uuid": "64879fdc-e830-4a6c-ab01-3da04d79a5a3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42242", "type": "seen", "source": "https://t.me/cvedetector/2706", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42242 - Linux kernel MMC SDHCI Segment Size Underflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42242 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmmc: sdhci: Fix max_seg_size for 64KiB PAGE_SIZE  \n  \nblk_queue_max_segment_size() ensured:  \n  \n if (max_size max_segment_size Severity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:47.000000Z"}, {"uuid": "e0badda3-6364-41bd-9ca7-350b2720068a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42243", "type": "published-proof-of-concept", "source": "https://t.me/cvedetector/2704", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42243 - Linux Kernel Linux Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42243 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray  \n  \nPatch series \"mm/filemap: Limit page cache size to that supported by  \nxarray\", v2.  \n  \nCurrently, xarray can't support arbitrary page cache size.  More details  \ncan be found from the WARN_ON() statement in xas_split_alloc().  In our  \ntest whose code is attached below, we hit the WARN_ON() on ARM64 system  \nwhere the base page size is 64KB and huge page size is 512MB.  The issue  \nwas reported long time ago and some discussions on it can be found here  \n[1].  \n  \n[1]   \n  \nIn order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one  \nsupported by xarray and avoid PMD-sized page cache if needed.  The code  \nchanges are suggested by David Hildenbrand.  \n  \nPATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray  \nPATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path  \nPATCH[4] avoids PMD-sized page cache for shmem files if needed  \n  \nTest program  \n============  \n# cat test.c  \n#define _GNU_SOURCE  \n#include   \n#include   \n#include   \n#include   \n#include   \n#include   \n#include   \n#include   \n  \n#define TEST_XFS_FILENAME \"/tmp/data\"  \n#define TEST_SHMEM_FILENAME \"/dev/shm/data\"  \n#define TEST_MEM_SIZE  0x20000000  \n  \nint main(int argc, char **argv)  \n{  \n const char *filename;  \n int fd = 0;  \n void *buf = (void *)-1, *p;  \n int pgsize = getpagesize();  \n int ret;  \n  \n if (pgsize != 0x10000) {  \n  fprintf(stderr, \"64KB base page size is required\\n\");  \n  return -EPERM;  \n }  \n  \n system(\"echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled\");  \n system(\"rm -fr /tmp/data\");  \n system(\"rm -fr /dev/shm/data\");  \n system(\"echo 1 > /proc/sys/vm/drop_caches\");  \n  \n /* Open xfs or shmem file */  \n filename = TEST_XFS_FILENAME;  \n if (argc > 1 && !strcmp(argv[1], \"shmem\"))  \n  filename = TEST_SHMEM_FILENAME;  \n  \n fd = open(filename, O_CREAT | O_RDWR | O_TRUNC);  \n if (fd \\n\", filename);  \n  return -EIO;  \n }  \n  \n /* Extend file size */  \n ret = ftruncate(fd, TEST_MEM_SIZE);  \n if (ret) {  \n  fprintf(stderr, \"Error %d to ftruncate()\\n\", ret);  \n  goto cleanup;  \n }  \n  \n /* Create VMA */  \n buf = mmap(NULL, TEST_MEM_SIZE,  \n     PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);  \n if (buf == (void *)-1) {  \n  fprintf(stderr, \"Unable to mmap \\n\", filename);  \n  goto cleanup;  \n }  \n  \n fprintf(stdout, \"mapped buffer at 0x%p\\n\", buf);  \n ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE);  \n        if (ret) {  \n  fprintf(stderr, \"Unable to madvise(MADV_HUGEPAGE)\\n\");  \n  goto cleanup;  \n }  \n  \n /* Populate VMA */  \n ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE);  \n if (ret) {  \n  fprintf(stderr, \"Error %d to madvise(MADV_POPULATE_WRITE)\\n\", ret);  \n  goto cleanup;  \n }  \n  \n /* Punch the file to enforce xarray split */  \n ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,  \n          TEST_MEM_SIZE - pgsize, pgsize);  \n if (ret)  \n  fprintf(stderr, \"Error %d to fallocate()\\n\", ret);  \n  \ncleanup:  \n if (buf != (void *)-1)  \n  munmap(buf, TEST_MEM_SIZE);  \n if (fd > 0)  \n  close(fd);  \n  \n return 0;  \n}  \n  \n# gcc test.c -o test  \n# cat /proc/1/smaps | grep KernelPageSize | head -n 1  \nKernelPageSize:       64 kB  \n# ./test shmem  \n   :  \n------------[ cut here ]------------  \nWARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128  \nModules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib  \\  \nnft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct    \\  \nnft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4    \\  \nip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon          \\  \ndrm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64  \\  \nvirtio_net sha1_ce net_failover failover virtio_console virtio_blk \\  \ndimlib virtio_mmi[...]", "creation_timestamp": "2024-08-07T18:38:41.000000Z"}, {"uuid": "31e4b7e7-3315-4c41-9efc-c85e399f0277", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42248", "type": "seen", "source": "https://t.me/cvedetector/2703", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42248 - Linux kernel TTY Serial NULL Pointer Dereference Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42248 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ntty: serial: ma35d1: Add a NULL check for of_node  \n  \nThe pdev->dev.of_node can be NULL if the \"serial\" node is absent.  \nAdd a NULL check to return an error in such cases. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:40.000000Z"}, {"uuid": "c05b0021-5bce-4d27-ab2c-3ce38ce8cfab", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42245", "type": "seen", "source": "https://t.me/cvedetector/2702", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42245 - Linux Kernel Sched/Fair Load Balancing Denial of Service\", \n  \"Content\": \"CVE ID : CVE-2024-42245 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nRevert \"sched/fair: Make sure to try to detach at least one movable task\"  \n  \nThis reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.  \n  \nb0defa7ae03ec changed the load balancing logic to ignore env.max_loop if  \nall tasks examined to that point were pinned. The goal of the patch was  \nto make it more likely to be able to detach a task buried in a long list  \nof pinned tasks. However, this has the unfortunate side effect of  \ncreating an O(n) iteration in detach_tasks(), as we now must fully  \niterate every task on a cpu if all or most are pinned. Since this load  \nbalance code is done with rq lock held, and often in softirq context, it  \nis very easy to trigger hard lockups. We observed such hard lockups with  \na user who affined O(10k) threads to a single cpu.  \n  \nWhen I discussed this with Vincent he initially suggested that we keep  \nthe limit on the number of tasks to detach, but increase the number of  \ntasks we can search. However, after some back and forth on the mailing  \nlist, he recommended we instead revert the original patch, as it seems  \nlikely no one was actually getting hit by the original issue. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:40.000000Z"}, {"uuid": "6a989d27-90f1-4ab5-b080-0d42b32a88fc", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42249", "type": "seen", "source": "https://t.me/cvedetector/2701", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42249 - Linux Kernel SPI Corrupting Message Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42249 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nspi: don't unoptimize message in spi_async()  \n  \nCalling spi_maybe_unoptimize_message() in spi_async() is wrong because  \nthe message is likely to be in the queue and not transferred yet. This  \ncan corrupt the message while it is being used by the controller driver.  \n  \nspi_maybe_unoptimize_message() is already called in the correct place  \nin spi_finalize_current_message() to balance the call to  \nspi_maybe_optimize_message() in spi_async(). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:39.000000Z"}, {"uuid": "7363de2b-f72e-4463-88ae-711a6c07cc87", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42241", "type": "seen", "source": "https://t.me/cvedetector/2709", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42241 - QEMU KVM Virtio Driver SHMEM Page Cache Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42241 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmm/shmem: disable PMD-sized page cache if needed  \n  \nFor shmem files, it's possible that PMD-sized page cache can't be  \nsupported by xarray.  For example, 512MB page cache on ARM64 when the base  \npage size is 64KB can't be supported by xarray.  It leads to errors as the  \nfollowing messages indicate when this sort of xarray entry is split.  \n  \nWARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128  \nModules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6   \\  \nnft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject        \\  \nnft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4  \\  \nip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs  \\  \nlibcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net \\  \nnet_failover virtio_console virtio_blk failover dimlib virtio_mmio  \nCPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9  \nHardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024  \npstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)  \npc : xas_split_alloc+0xf8/0x128  \nlr : split_huge_page_to_list_to_order+0x1c4/0x720  \nsp : ffff8000882af5f0  \nx29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768  \nx26: 0000000000000cc0 x25: 000000000000000d x24: ffff00010625b858  \nx23: ffff8000882af650 x22: ffffffdfc0900000 x21: 0000000000000000  \nx20: 0000000000000000 x19: ffffffdfc0900000 x18: 0000000000000000  \nx17: 0000000000000000 x16: 0000018000000000 x15: 52f8004000000000  \nx14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020  \nx11: 52f8000000000000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c  \nx8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00010b02ddb0  \nx5 : ffffbeb96395e378 x4 : 0000000000000000 x3 : 0000000000000cc0  \nx2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000  \nCall trace:  \n xas_split_alloc+0xf8/0x128  \n split_huge_page_to_list_to_order+0x1c4/0x720  \n truncate_inode_partial_folio+0xdc/0x160  \n shmem_undo_range+0x2bc/0x6a8  \n shmem_fallocate+0x134/0x430  \n vfs_fallocate+0x124/0x2e8  \n ksys_fallocate+0x4c/0xa0  \n __arm64_sys_fallocate+0x24/0x38  \n invoke_syscall.constprop.0+0x7c/0xd8  \n do_el0_svc+0xb4/0xd0  \n el0_svc+0x44/0x1d8  \n el0t_64_sync_handler+0x134/0x150  \n el0t_64_sync+0x17c/0x180  \n  \nFix it by disabling PMD-sized page cache when HPAGE_PMD_ORDER is larger  \nthan MAX_PAGECACHE_ORDER.  As Matthew Wilcox pointed, the page cache in a  \nshmem file isn't represented by a multi-index entry and doesn't have this  \nlimitation when the xarry entry is split until commit 6b24ca4a1a8d (\"mm:  \nUse multi-index entries in the page cache\"). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:50.000000Z"}, {"uuid": "363f3803-0678-42a4-85a1-65ca5e3cf8e0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42244", "type": "seen", "source": "https://t.me/cvedetector/2698", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42244 - Linux Kernel Mos7840 USB Serialization Suspend Resume Crash Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42244 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nUSB: serial: mos7840: fix crash on resume  \n  \nSince commit c49cfa917025 (\"USB: serial: use generic method if no  \nalternative is provided in usb serial layer\"), USB serial core calls the  \ngeneric resume implementation when the driver has not provided one.  \n  \nThis can trigger a crash on resume with mos7840 since support for  \nmultiple read URBs was added back in 2011. Specifically, both port read  \nURBs are now submitted on resume for open ports, but the context pointer  \nof the second URB is left set to the core rather than mos7840 port  \nstructure.  \n  \nFix this by implementing dedicated suspend and resume functions for  \nmos7840.  \n  \nTested with Delock 87414 USB 2.0 to 4x serial adapter.  \n  \n[ johan: analyse crash and rewrite commit message; set busy flag on  \n         resume; drop bulk-in check; drop unnecessary usb_kill_urb() ] \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:33.000000Z"}, {"uuid": "9c3504c9-6c63-4527-be02-84113a04f1b8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-42246", "type": "seen", "source": "https://t.me/cvedetector/2696", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-42246 - Linux Kernel Remote Denial of Service Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-42246 \nPublished : Aug. 7, 2024, 4:15 p.m. | 15\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket  \n  \nWhen using a BPF program on kernel_connect(), the call can return -EPERM. This  \ncauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causing  \nthe kernel to potentially freeze up.  \n  \nNeil suggested:  \n  \n  This will propagate -EPERM up into other layers which might not be ready  \n  to handle it. It might be safer to map EPERM to an error we would be more  \n  likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.  \n  \nECONNREFUSED as error seems reasonable. For programs setting a different error  \ncan be out of reach (see handling in 4fbac77d2d09) in particular on kernels  \nwhich do not have f10d05966196 (\"bpf: Make BPF_PROG_RUN_ARRAY return -err  \ninstead of allow boolean\"), thus given that it is better to simply remap for  \nconsistent behavior. UDP does handle EPERM in xs_udp_send_request(). \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"07 Aug 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-08-07T18:38:31.000000Z"}, {"uuid": "184c4666-1a74-4b9c-bacf-deb5df638ff8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-4224", "type": "seen", "source": "https://t.me/cvedetector/908", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-4224 - TP-Link TL-SG1016DE Authenticated Stored Cross-Site Scripting Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-4224 \nPublished : July 15, 2024, 9:15 p.m. | 43\u00a0minutes ago \nDescription : An authenticated stored cross-site scripting (XSS) exists in the TP-Link TL-SG1016DE affecting version TL-SG1016DE(UN) V7.6_1.0.0 Build 20230616, which could allow an adversary to run JavaScript in an administrator's browser. This issue was fixed in\u00a0TL-SG1016DE(UN) V7_1.0.1 Build 20240628. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"15 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-16T00:22:56.000000Z"}]}