{"vulnerability": "CVE-2024-4100", "sightings": [{"uuid": "ec6da343-b8ba-4f4c-802e-c76b2270bb58", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-41005", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "dda7e74c-4b8f-461d-8204-33e7ea12d885", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41005", "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": "59937dc1-8079-4d29-a67a-943a547ffa38", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41006", "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": "5a59cd30-23a7-4cb4-a552-7eff61bc4e66", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41004", "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": "cd47766f-5293-45eb-b1de-2e50a49758ee", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41000", "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": "34d63819-451f-4c39-87a3-542e53559181", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41007", "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": "423bd4de-6fe7-45b2-b335-896fb872a220", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41009", "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": "9200cb31-87c1-491d-9a83-6be6c82f0089", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-41008", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "6dd5f0c9-0b26-48b6-97d9-ba9ab76f5628", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-41001", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "e07492d9-b86b-40b3-9787-2be59b34d82e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "86ecb4e1-bb32-44d5-9f39-8a4673af8385", "vulnerability": "CVE-2024-41008", "type": "seen", "source": "https://www.cert.ssi.gouv.fr/avis/CERTFR-2026-AVI-0316/", "content": "", "creation_timestamp": "2026-03-19T00:00:00.000000Z"}, {"uuid": "2c273aef-907a-4b04-ac26-f5f08dbd1810", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-41001", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "3ed81cc7-5f2c-4e2e-84c4-be12de74082e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-41000", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "2dc4f62b-876e-41a8-b5c4-2eb3b2ffefa4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41001", "type": "seen", "source": "https://t.me/cvedetector/727", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41001 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-41001 \nPublished : July 12, 2024, 1:15 p.m. | 39\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nio_uring/sqpoll: work around a potential audit memory leak  \n  \nkmemleak complains that there's a memory leak related to connect  \nhandling:  \n  \nunreferenced object 0xffff0001093bdf00 (size 128):  \ncomm \"iou-sqp-455\", pid 457, jiffies 4294894164  \nhex dump (first 32 bytes):  \n02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00  ................  \n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  \nbacktrace (crc 2e481b1a):  \n[] kmemleak_alloc+0x30/0x38  \n[] kmalloc_trace+0x228/0x358  \n[] __audit_sockaddr+0xd0/0x138  \n[] move_addr_to_kernel+0x1a0/0x1f8  \n[] io_connect_prep+0x1ec/0x2d4  \n[] io_submit_sqes+0x588/0x1e48  \n[] io_sq_thread+0x8a4/0x10e4  \n[] ret_from_fork+0x10/0x20  \n  \nwhich can can happen if:  \n  \n1) The command type does something on the prep side that triggers an  \n   audit call.  \n2) The thread hasn't done any operations before this that triggered  \n   an audit call inside ->issue(), where we have audit_uring_entry()  \n   and audit_uring_exit().  \n  \nWork around this by issuing a blanket NOP operation before the SQPOLL  \ndoes anything. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"12 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-12T16:05:01.000000Z"}, {"uuid": "70c101f3-50fa-4b71-85fd-92231549e419", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41003", "type": "seen", "source": "https://t.me/cvedetector/725", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41003 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-41003 \nPublished : July 12, 2024, 1:15 p.m. | 39\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Fix reg_set_min_max corruption of fake_reg  \n  \nJuan reported that after doing some changes to buzzer [0] and implementing  \na new fuzzing strategy guided by coverage, they noticed the following in  \none of the probes:  \n  \n  [...]  \n  13: (79) r6 = *(u64 *)(r0 +0)         ; R0=map_value(ks=4,vs=8) R6_w=scalar()  \n  14: (b7) r0 = 0                       ; R0_w=0  \n  15: (b4) w0 = -1                      ; R0_w=0xffffffff  \n  16: (74) w0 >>= 1                     ; R0_w=0x7fffffff  \n  17: (5c) w6 &= w0                     ; R0_w=0x7fffffff R6_w=scalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,var_off=(0x0; 0x7fffffff))  \n  18: (44) w6 |= 2                      ; R6_w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,var_off=(0x2; 0x7ffffffd))  \n  19: (56) if w6 != 0x7ffffffd goto pc+1  \n  REG INVARIANTS VIOLATION (true_reg2): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)  \n  REG INVARIANTS VIOLATION (false_reg1): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] var_off=(0x7fffffff, 0x0)  \n  REG INVARIANTS VIOLATION (false_reg2): const tnum out of sync with range bounds u64=[0x0, 0xffffffffffffffff] s64=[0x8000000000000000, 0x7fffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7fffffff] var_off=(0x7fffffff, 0x0)  \n  19: R6_w=0x7fffffff  \n  20: (95) exit  \n  \n  from 19 to 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm  \n  21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,var_off=(0x2; 0x7ffffffd)) R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm  \n  21: (14) w6 -= 2147483632             ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,var_off=(0x2; 0xfffffffd))  \n  22: (76) if w6 s>= 0xe goto pc+1      ; R6_w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,var_off=(0x2; 0xfffffffd))  \n  23: (95) exit  \n  \n  from 22 to 24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm  \n  24: R0=0x7fffffff R6_w=14 R7=map_ptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=map_ptr(ks=4,vs=8) fp-40=mmmmmmmm  \n  24: (14) w6 -= 14                     ; R6_w=0  \n  [...]  \n  \nWhat can be seen here is a register invariant violation on line 19. After  \nthe binary-or in line 18, the verifier knows that bit 2 is set but knows  \nnothing about the rest of the content which was loaded from a map value,  \nmeaning, range is [2,0x7fffffff] with var_off=(0x2; 0x7ffffffd). When in  \nline 19 the verifier analyzes the branch, it splits the register states  \nin reg_set_min_max() into the registers of the true branch (true_reg1,  \ntrue_reg2) and the registers of the false branch (false_reg1, false_reg2).  \n  \nSince the test is w6 != 0x7ffffffd, the src_reg is a known constant.  \nInternally, the verifier creates a \"fake\" register initialized as scalar  \nto the value of 0x7ffffffd, and then passes it onto reg_set_min_max(). Now,  \nfor line 19, it is mathematically impossible to take the false branch of  \nthis program, yet the verifier analyzes it. It is impossible because the  \nsecond bit of r6 will be set due to the prior or operation and the  \nconstant in the condition has that bit unset (hex(fd) == binary(1111 1101).  \n  \nWhen the verifier first analyzes the false / fall-through branch, it will  \ncompute an intersection between the var_off of r6 and of the constant. This  \nis because the ver[...]", "creation_timestamp": "2024-07-12T16:04:59.000000Z"}, {"uuid": "7c168da9-82ed-42ba-91da-68ef426ac6a8", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41006", "type": "seen", "source": "https://t.me/cvedetector/724", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41006 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-41006 \nPublished : July 12, 2024, 1:15 p.m. | 39\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetrom: Fix a memory leak in nr_heartbeat_expiry()  \n  \nsyzbot reported a memory leak in nr_create() [0].  \n  \nCommit 409db27e3a2e (\"netrom: Fix use-after-free of a listening socket.\")  \nadded sock_hold() to the nr_heartbeat_expiry() function, where  \na) a socket has a SOCK_DESTROY flag or  \nb) a listening socket has a SOCK_DEAD flag.  \n  \nBut in the case \"a,\" when the SOCK_DESTROY flag is set, the file descriptor  \nhas already been closed and the nr_release() function has been called.  \nSo it makes no sense to hold the reference count because no one will  \ncall another nr_destroy_socket() and put it as in the case \"b.\"  \n  \nnr_connect  \n  nr_establish_data_link  \n    nr_start_heartbeat  \n  \nnr_release  \n  switch (nr->state)  \n  case NR_STATE_3  \n    nr->state = NR_STATE_2  \n    sock_set_flag(sk, SOCK_DESTROY);  \n  \n                        nr_rx_frame  \n                          nr_process_rx_frame  \n                            switch (nr->state)  \n                            case NR_STATE_2  \n                              nr_state2_machine()  \n                                nr_disconnect()  \n                                  nr_sk(sk)->state = NR_STATE_0  \n                                  sock_set_flag(sk, SOCK_DEAD)  \n  \n                        nr_heartbeat_expiry  \n                          switch (nr->state)  \n                          case NR_STATE_0  \n                            if (sock_flag(sk, SOCK_DESTROY) ||  \n                               (sk->sk_state == TCP_LISTEN  \n                                 && sock_flag(sk, SOCK_DEAD)))  \n                               sock_hold()  // ( !!! )  \n                               nr_destroy_socket()  \n  \nTo fix the memory leak, let's call sock_hold() only for a listening socket.  \n  \nFound by InfoTeCS on behalf of Linux Verification Center  \n(linuxtesting.org) with Syzkaller.  \n  \n[0]:  \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"12 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-12T16:04:58.000000Z"}, {"uuid": "da2d6564-7ed5-4a60-93b6-aa581b5fb0a9", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41005", "type": "seen", "source": "https://t.me/cvedetector/723", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41005 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-41005 \nPublished : July 12, 2024, 1:15 p.m. | 39\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetpoll: Fix race condition in netpoll_owner_active  \n  \nKCSAN detected a race condition in netpoll:  \n  \n BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb  \n write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:  \n net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)  \n  \n read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:  \n netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)  \n netpoll_send_udp (net/core/netpoll.c:?)  \n  \n value changed: 0x0000000a -> 0xffffffff  \n  \nThis happens because netpoll_owner_active() needs to check if the  \ncurrent CPU is the owner of the lock, touching napi->poll_owner  \nnon atomically. The ->poll_owner field contains the current CPU holding  \nthe lock.  \n  \nUse an atomic read to check if the poll owner is the current CPU. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"12 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-12T16:04:57.000000Z"}, {"uuid": "27130b88-4712-4f28-9ba5-825ff85d81f3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41004", "type": "seen", "source": "https://t.me/cvedetector/720", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41004 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-41004 \nPublished : July 12, 2024, 1:15 p.m. | 39\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ntracing: Build event generation tests only as modules  \n  \nThe kprobes and synth event generation test modules add events and lock  \n(get a reference) those event file reference in module init function,  \nand unlock and delete it in module exit function. This is because those  \nare designed for playing as modules.  \n  \nIf we make those modules as built-in, those events are left locked in the  \nkernel, and never be removed. This causes kprobe event self-test failure  \nas below.  \n  \n[   97.349708] ------------[ cut here ]------------  \n[   97.353453] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:2133 kprobe_trace_self_tests_init+0x3f1/0x480  \n[   97.357106] Modules linked in:  \n[   97.358488] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.9.0-g699646734ab5-dirty #14  \n[   97.361556] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014  \n[   97.363880] RIP: 0010:kprobe_trace_self_tests_init+0x3f1/0x480  \n[   97.365538] Code: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff ff 90  0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 90  \n[   97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286  \n[   97.371852] RAX: 00000000fffffff0 RBX: ffff888005919c00 RCX: 0000000000000000  \n[   97.373829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68  \n[   97.375715] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000  \n[   97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000  \n[   97.379591] R13: 0000000000000001 R14: 0000000000000015 R15: 0000000000000000  \n[   97.381536] FS:  0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000  \n[   97.383813] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \n[   97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0  \n[   97.387347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  \n[   97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  \n[   97.391196] Call Trace:  \n[   97.391967]    \n[   97.392647]  ? __warn+0xcc/0x180  \n[   97.393640]  ? kprobe_trace_self_tests_init+0x3f1/0x480  \n[   97.395181]  ? report_bug+0xbd/0x150  \n[   97.396234]  ? handle_bug+0x3e/0x60  \n[   97.397311]  ? exc_invalid_op+0x1a/0x50  \n[   97.398434]  ? asm_exc_invalid_op+0x1a/0x20  \n[   97.399652]  ? trace_kprobe_is_busy+0x20/0x20  \n[   97.400904]  ? tracing_reset_all_online_cpus+0x15/0x90  \n[   97.402304]  ? kprobe_trace_self_tests_init+0x3f1/0x480  \n[   97.403773]  ? init_kprobe_trace+0x50/0x50  \n[   97.404972]  do_one_initcall+0x112/0x240  \n[   97.406113]  do_initcall_level+0x95/0xb0  \n[   97.407286]  ? kernel_init+0x1a/0x1a0  \n[   97.408401]  do_initcalls+0x3f/0x70  \n[   97.409452]  kernel_init_freeable+0x16f/0x1e0  \n[   97.410662]  ? rest_init+0x1f0/0x1f0  \n[   97.411738]  kernel_init+0x1a/0x1a0  \n[   97.412788]  ret_from_fork+0x39/0x50  \n[   97.413817]  ? rest_init+0x1f0/0x1f0  \n[   97.414844]  ret_from_fork_asm+0x11/0x20  \n[   97.416285]    \n[   97.417134] irq event stamp: 13437323  \n[   97.418376] hardirqs last  enabled at (13437337): [] console_unlock+0x11c/0x150  \n[   97.421285] hardirqs last disabled at (13437370): [] console_unlock+0x101/0x150  \n[   97.423838] softirqs last  enabled at (13437366): [] handle_softirqs+0x23f/0x2a0  \n[   97.426450] softirqs last disabled at (13437393): [] __irq_exit_rcu+0x66/0xd0  \n[   97.428850] ---[ end trace 0000000000000000 ]---  \n  \nAnd also, since we can not cleanup dynamic_event file, ftracetest are  \nfailed too.  \n  \nTo avoid these issues, build these tests only as modules. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n [...]", "creation_timestamp": "2024-07-12T16:04:53.000000Z"}, {"uuid": "16697c1f-36be-40b8-b387-927cd690494b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41000", "type": "seen", "source": "https://t.me/cvedetector/736", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41000 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-41000 \nPublished : July 12, 2024, 1:15 p.m. | 39\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nblock/ioctl: prefer different overflow check  \n  \nRunning syzkaller with the newly reintroduced signed integer overflow  \nsanitizer shows this report:  \n  \n[   62.982337] ------------[ cut here ]------------  \n[   62.985692] cgroup: Invalid name  \n[   62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46  \n[   62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1  \n[   62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long'  \n[   62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1  \n[   62.999369] random: crng reseeded on system resumption  \n[   63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000)  \n[   63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1  \n[   63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014  \n[   63.000682] Call Trace:  \n[   63.000686]    \n[   63.000731]  dump_stack_lvl+0x93/0xd0  \n[   63.000919]  __get_user_pages+0x903/0xd30  \n[   63.001030]  __gup_longterm_locked+0x153e/0x1ba0  \n[   63.001041]  ? _raw_read_unlock_irqrestore+0x17/0x50  \n[   63.001072]  ? try_get_folio+0x29c/0x2d0  \n[   63.001083]  internal_get_user_pages_fast+0x1119/0x1530  \n[   63.001109]  iov_iter_extract_pages+0x23b/0x580  \n[   63.001206]  bio_iov_iter_get_pages+0x4de/0x1220  \n[   63.001235]  iomap_dio_bio_iter+0x9b6/0x1410  \n[   63.001297]  __iomap_dio_rw+0xab4/0x1810  \n[   63.001316]  iomap_dio_rw+0x45/0xa0  \n[   63.001328]  ext4_file_write_iter+0xdde/0x1390  \n[   63.001372]  vfs_write+0x599/0xbd0  \n[   63.001394]  ksys_write+0xc8/0x190  \n[   63.001403]  do_syscall_64+0xd4/0x1b0  \n[   63.001421]  ? arch_exit_to_user_mode_prepare+0x3a/0x60  \n[   63.001479]  entry_SYSCALL_64_after_hwframe+0x6f/0x77  \n[   63.001535] RIP: 0033:0x7f7fd3ebf539  \n[   63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 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 b8 ff ff ff f7 d8 64 89 01 48  \n[   63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001  \n[   63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539  \n[   63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004  \n[   63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000  \n[   63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000  \n[   63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8  \n...  \n[   63.018142] ---[ end trace ]---  \n  \nHistorically, the signed integer overflow sanitizer did not work in the  \nkernel due to its interaction with `-fwrapv` but this has since been  \nchanged [1] in the newest version of Clang; It was re-enabled in the  \nkernel with Commit 557f8c582a9ba8ab (\"ubsan: Reintroduce signed overflow  \nsanitizer\").  \n  \nLet's rework this overflow checking logic to not actually perform an  \noverflow during the check itself, thus avoiding the UBSAN splat.  \n  \n[1]:  \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"12 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-12T16:05:13.000000Z"}, {"uuid": "89fb4a11-6cfd-4b88-a2b2-c8e97147d95e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41002", "type": "seen", "source": "https://t.me/cvedetector/719", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41002 - In the Linux kernel, the following vulnerability h\", \n  \"Content\": \"CVE ID : CVE-2024-41002 \nPublished : July 12, 2024, 1:15 p.m. | 39\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ncrypto: hisilicon/sec - Fix memory leak for sec resource release  \n  \nThe AIV is one of the SEC resources. When releasing resources,  \nit need to release the AIV resources at the same time.  \nOtherwise, memory leakage occurs.  \n  \nThe aiv resource release is added to the sec resource release  \nfunction. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"12 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-12T16:04:52.000000Z"}, {"uuid": "fe11cf30-53f3-49bb-8524-1b4aea938a0d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41009", "type": "seen", "source": "https://t.me/cvedetector/1062", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41009 - Linux Kernel BPF RingBuf Overwrite Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-41009 \nPublished : July 17, 2024, 7:15 a.m. | 29\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Fix overrunning reservations in ringbuf  \n  \nThe BPF ring buffer internally is implemented as a power-of-2 sized circular  \nbuffer, with two logical and ever-increasing counters: consumer_pos is the  \nconsumer counter to show which logical position the consumer consumed the  \ndata, and producer_pos which is the producer counter denoting the amount of  \ndata reserved by all producers.  \n  \nEach time a record is reserved, the producer that \"owns\" the record will  \nsuccessfully advance producer counter. In user space each time a record is  \nread, the consumer of the data advanced the consumer counter once it finished  \nprocessing. Both counters are stored in separate pages so that from user  \nspace, the producer counter is read-only and the consumer counter is read-write.  \n  \nOne aspect that simplifies and thus speeds up the implementation of both  \nproducers and consumers is how the data area is mapped twice contiguously  \nback-to-back in the virtual memory, allowing to not take any special measures  \nfor samples that have to wrap around at the end of the circular buffer data  \narea, because the next page after the last data page would be first data page  \nagain, and thus the sample will still appear completely contiguous in virtual  \nmemory.  \n  \nEach record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for  \nbook-keeping the length and offset, and is inaccessible to the BPF program.  \nHelpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`  \nfor the BPF program to use. Bing-Jhong and Muhammad reported that it is however  \npossible to make a second allocated memory chunk overlapping with the first  \nchunk and as a result, the BPF program is now able to edit first chunk's  \nheader.  \n  \nFor example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size  \nof 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to  \nbpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in  \n[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets  \nallocate a chunk B with size 0x3000. This will succeed because consumer_pos  \nwas edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask`  \ncheck. Chunk B will be in range [0x3008,0x6010], and the BPF program is able  \nto edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned  \nearlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data  \npages. This means that chunk B at [0x4000,0x4008] is chunk A's header.  \nbpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then  \nlocate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk  \nB modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong  \npage and could cause a crash.  \n  \nFix it by calculating the oldest pending_pos and check whether the range  \nfrom the oldest outstanding record to the newest would span beyond the ring  \nbuffer size. If that is the case, then reject the request. We've tested with  \nthe ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)  \nbefore/after the fix and while it seems a bit slower on some benchmarks, it  \nis still not significantly enough to matter. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"17 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-17T09:51:39.000000Z"}, {"uuid": "2186d0b3-ca33-463b-a9fc-912e42849bc4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41007", "type": "seen", "source": "https://t.me/cvedetector/859", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41007 - Linux Kernel TCP Avoid Too Many Retransmit Packets Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-41007 \nPublished : July 15, 2024, 9:15 a.m. | 32\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ntcp: avoid too many retransmit packets  \n  \nIf a TCP socket is using TCP_USER_TIMEOUT, and the other peer  \nretracted its window to zero, tcp_retransmit_timer() can  \nretransmit a packet every two jiffies (2 ms for HZ=1000),  \nfor about 4 minutes after TCP_USER_TIMEOUT has 'expired'.  \n  \nThe fix is to make sure tcp_rtx_probe0_timed_out() takes  \nicsk->icsk_user_timeout into account.  \n  \nBefore blamed commit, the socket would not timeout after  \nicsk->icsk_user_timeout, but would use standard exponential  \nbackoff for the retransmits.  \n  \nAlso worth noting that before commit e89688e3e978 (\"net: tcp:  \nfix unexcepted socket die when snd_wnd is 0\"), the issue  \nwould last 2 minutes instead of 4. \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-15T11:49:50.000000Z"}, {"uuid": "d88581bc-0bf6-49eb-9fe7-d442b8e9b713", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41003", "type": "published-proof-of-concept", "source": "https://t.me/Kelvinseccommunity/573", "content": "#exploit\n1. CVE-2024-41003:\nLinux Kernel Vulnerability in the eBPF verifier register limit tracking\nhttps://github.com/google/security-research/security/advisories/GHSA-hfqc-63c7-rj9f\n\n2. CVE-2023-52251,\nCVE-2023-25194,\nCVE-2024-32030:\n3 ways to get RCE in Kafka UI\nhttps://github.blog/security/vulnerability-research/3-ways-to-get-remote-code-execution-in-kafka-ui\n\n3. CVE-2019-8805:\nApple EndpointSecurity Privilege Escalation\nhttps://blog.securelayer7.net/applied-endpointsecurity-framework-previlege-escalation\n]-> PoC: https://github.com/securelayer7/CVE-2019-8805", "creation_timestamp": "2024-07-24T14:14:49.000000Z"}, {"uuid": "e664b74c-4be5-4daf-9016-3d83613230b5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41003", "type": "published-proof-of-concept", "source": "https://t.me/CyberSecurityTechnologies/10876", "content": "#exploit\n1. CVE-2024-41003:\nLinux Kernel Vulnerability in the eBPF verifier register limit tracking\nhttps://github.com/google/security-research/security/advisories/GHSA-hfqc-63c7-rj9f\n\n2. CVE-2023-52251,\nCVE-2023-25194,\nCVE-2024-32030:\n3 ways to get RCE in Kafka UI\nhttps://github.blog/security/vulnerability-research/3-ways-to-get-remote-code-execution-in-kafka-ui\n\n3. CVE-2019-8805:\nApple EndpointSecurity Privilege Escalation\nhttps://blog.securelayer7.net/applied-endpointsecurity-framework-previlege-escalation\n]-> PoC: https://github.com/securelayer7/CVE-2019-8805", "creation_timestamp": "2024-07-24T12:51:30.000000Z"}, {"uuid": "0ac7bee0-3252-4f23-8d22-b50173e2beb1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-4100", "type": "seen", "source": "https://t.me/cvedetector/294", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-4100 - The Pricing Table plugin for WordPress is vulnerab\", \n  \"Content\": \"CVE ID : CVE-2024-4100 \nPublished : July 9, 2024, 9:15 a.m. | 31\u00a0minutes ago \nDescription : The Pricing Table plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 2.0.1. This is due to missing or incorrect nonce validation on the ajax() function. This makes it possible for unauthenticated attackers to perform a variety of actions related to managing pricing tables via a forged request granted they can trick a site administrator into performing an action such as clicking on a link. \nSeverity: 5.3 | MEDIUM \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-09T11:50:10.000000Z"}, {"uuid": "a23da33d-d244-4622-a8d5-a73fc480b205", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41008", "type": "seen", "source": "https://t.me/cvedetector/916", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-41008 - \"Amidgpu Linux Kernel Task Information Handling Overflow\"\", \n  \"Content\": \"CVE ID : CVE-2024-41008 \nPublished : July 16, 2024, 8:15 a.m. | 38\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \ndrm/amdgpu: change vm->task_info handling  \n  \nThis patch changes the handling and lifecycle of vm->task_info object.  \nThe major changes are:  \n- vm->task_info is a dynamically allocated ptr now, and its uasge is  \n  reference counted.  \n- introducing two new helper funcs for task_info lifecycle management  \n    - amdgpu_vm_get_task_info: reference counts up task_info before  \n      returning this info  \n    - amdgpu_vm_put_task_info: reference counts down task_info  \n- last put to task_info() frees task_info from the vm.  \n  \nThis patch also does logistical changes required for existing usage  \nof vm->task_info.  \n  \nV2: Do not block all the prints when task_info not found (Felix)  \n  \nV3: Fixed review comments from Felix  \n   - Fix wrong indentation  \n   - No debug message for -ENOMEM  \n   - Add NULL check for task_info  \n   - Do not duplicate the debug messages (ti vs no ti)  \n   - Get first reference of task_info in vm_init(), put last  \n     in vm_fini()  \n  \nV4: Fixed review comments from Felix  \n   - fix double reference increment in create_task_info  \n   - change amdgpu_vm_get_task_info_pasid  \n   - additional changes in amdgpu_gem.c while porting \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"16 Jul 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-07-16T11:15:10.000000Z"}, {"uuid": "630d9a83-e1f1-49cb-8086-ad1971b41087", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-41003", "type": "seen", "source": "https://t.me/proxy_bar/2168", "content": "CVE-2024-41003\n*\nLinux Kernel: Vulnerability in the eBPF verifier register limit tracking\n\n#kernel", "creation_timestamp": "2024-07-16T18:04:49.000000Z"}]}