{"vulnerability": "cve-2024-5025", "sightings": [{"uuid": "a2049913-3a57-4056-baa1-b7097288b5d4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50250", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453018614318747", "content": "", "creation_timestamp": "2024-11-09T12:34:40.043136Z"}, {"uuid": "994f3514-53a6-43ed-97e0-bb5ae79df62a", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50251", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453018647695403", "content": "", "creation_timestamp": "2024-11-09T12:34:40.444673Z"}, {"uuid": "2b25b1cf-ed72-4514-a1a8-84fe0726065b", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50252", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453077645644429", "content": "", "creation_timestamp": "2024-11-09T12:49:40.808713Z"}, {"uuid": "6ed96b56-7f3a-46b7-9ac8-edcf969fbb72", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50253", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453077661194194", "content": "", "creation_timestamp": "2024-11-09T12:49:41.106130Z"}, {"uuid": "52a7c5e2-e7d0-4383-8e0c-1fe35f21abe1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50254", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453077695714662", "content": "", "creation_timestamp": "2024-11-09T12:49:41.432679Z"}, {"uuid": "be331186-1f8d-4fe7-9c7e-1bac58668584", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50255", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453077709726251", "content": "", "creation_timestamp": "2024-11-09T12:49:42.020183Z"}, {"uuid": "d46a61df-87c5-4470-8fb9-93375b1e1b96", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50257", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453136723760485", "content": "", "creation_timestamp": "2024-11-09T13:04:42.622869Z"}, {"uuid": "94367ef7-ee1a-4b2e-b4c6-9ae42c22c31d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50256", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453136709352729", "content": "", "creation_timestamp": "2024-11-09T13:04:42.668705Z"}, {"uuid": "78ff17be-0085-47cb-b9fd-d7cc1803bc83", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50258", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453136737483869", "content": "", "creation_timestamp": "2024-11-09T13:04:42.700433Z"}, {"uuid": "2f1e85ad-96db-4aab-bff6-06f872084106", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50259", "type": "seen", "source": "https://infosec.exchange/users/cve/statuses/113453136752678083", "content": "", "creation_timestamp": "2024-11-09T13:04:42.900233Z"}, {"uuid": "e1fc5cf6-a1a0-451f-9846-5bfe0bc464cd", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50256", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "0626a7f5-8504-4084-8554-54ba6f138118", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50251", "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": "4d571679-7dd5-43a6-82fc-fa83f4fc51c4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50256", "type": "seen", "source": "https://t.me/cvedetector/10315", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50256 - Google Compute Engine Zero-Copy Tunnelling Ethernet Header Pointer Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50256 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()  \n  \nI got a syzbot report without a repro [1] crashing in nf_send_reset6()  \n  \nI think the issue is that dev->hard_header_len is zero, and we attempt  \nlater to push an Ethernet header.  \n  \nUse LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.  \n  \n[1]  \n  \nskbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun  \n kernel BUG at net/core/skbuff.c:206 !  \nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI  \nCPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0  \nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024  \n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]  \n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216  \nCode: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3  \nRSP: 0018:ffffc900045269b0 EFLAGS: 00010282  \nRAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800  \nRDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000  \nRBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc  \nR10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140  \nR13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c  \nFS:  00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000  \nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \nCR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0  \nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  \nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  \nCall Trace:  \n   \n  skb_push+0xe5/0x100 net/core/skbuff.c:2636  \n  eth_header+0x38/0x1f0 net/ethernet/eth.c:83  \n  dev_hard_header include/linux/netdevice.h:3208 [inline]  \n  nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358  \n  nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48  \n  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]  \n  nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288  \n  nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161  \n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]  \n  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626  \n  nf_hook include/linux/netfilter.h:269 [inline]  \n  NF_HOOK include/linux/netfilter.h:312 [inline]  \n  br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184  \n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]  \n  nf_hook_bridge_pre net/bridge/br_input.c:277 [inline]  \n  br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424  \n  __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562  \n  __netif_receive_skb_one_core net/core/dev.c:5666 [inline]  \n  __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781  \n  netif_receive_skb_internal net/core/dev.c:5867 [inline]  \n  netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926  \n  tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550  \n  tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007  \n  tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053  \n  new_sync_write fs/read_write.c:590 [inline]  \n  vfs_write+0xa6d/0xc90 fs/read_write.c:683  \n  ksys_write+0x183/0x2b0 fs/read_write.c:736  \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:0x7fdbeeb7d1ff  \nCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05[...]", "creation_timestamp": "2024-11-09T13:17:34.000000Z"}, {"uuid": "ed9d38d8-3626-4d9a-a989-2f3194daed98", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "c933734a-9be8-4142-889e-26e95c752803", "vulnerability": "CVE-2024-50258", "type": "seen", "source": "https://vulnerability.circl.lu/bundle/816dcc8e-f25a-4895-9b59-1bbd9caeccb8", "content": "", "creation_timestamp": "2025-12-03T14:14:49.267740Z"}, {"uuid": "1d775e05-cff9-495a-befd-acb25a580e8d", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50252", "type": "seen", "source": "https://t.me/cvedetector/10331", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50252 - Mellanox MLXSW IPv6 Address Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50252 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nmlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address  \n  \nThe device stores IPv6 addresses that are used for encapsulation in  \nlinear memory that is managed by the driver.  \n  \nChanging the remote address of an ip6gre net device never worked  \nproperly, but since cited commit the following reproducer [1] would  \nresult in a warning [2] and a memory leak [3]. The problem is that the  \nnew remote address is never added by the driver to its hash table (and  \ntherefore the device) and the old address is never removed from it.  \n  \nFix by programming the new address when the configuration of the ip6gre  \nnet device changes and removing the old one. If the address did not  \nchange, then the above would result in increasing the reference count of  \nthe address and then decreasing it.  \n  \n[1]  \n # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit  \n # ip link set dev bla type ip6gre remote 2001:db8:3::1  \n # ip link del dev bla  \n # devlink dev reload pci/0000:01:00.0  \n  \n[2]  \nWARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0  \nModules linked in:  \nCPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151  \nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023  \nRIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0  \n[...]  \nCall Trace:  \n   \n mlxsw_sp_router_netdevice_event+0x55f/0x1240  \n notifier_call_chain+0x5a/0xd0  \n call_netdevice_notifiers_info+0x39/0x90  \n unregister_netdevice_many_notify+0x63e/0x9d0  \n rtnl_dellink+0x16b/0x3a0  \n rtnetlink_rcv_msg+0x142/0x3f0  \n netlink_rcv_skb+0x50/0x100  \n netlink_unicast+0x242/0x390  \n netlink_sendmsg+0x1de/0x420  \n ____sys_sendmsg+0x2bd/0x320  \n ___sys_sendmsg+0x9a/0xe0  \n __sys_sendmsg+0x7a/0xd0  \n do_syscall_64+0x9e/0x1a0  \n entry_SYSCALL_64_after_hwframe+0x77/0x7f  \n  \n[3]  \nunreferenced object 0xffff898081f597a0 (size 32):  \n  comm \"ip\", pid 1626, jiffies 4294719324  \n  hex dump (first 32 bytes):  \n    20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01   ...............  \n    21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00  !Ia.............  \n  backtrace (crc fd9be911):  \n    [<00000000df89c55d] __kmalloc_cache_noprof+0x1da/0x260  \n    [<00000000ff2a1ddb] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340  \n    [<000000009ddd445d] mlxsw_sp_router_netdevice_event+0x47b/0x1240  \n    [<00000000743e7757] notifier_call_chain+0x5a/0xd0  \n    [<000000007c7b9e13] call_netdevice_notifiers_info+0x39/0x90  \n    [<000000002509645d] register_netdevice+0x5f7/0x7a0  \n    [<00000000c2e7d2a9] ip6gre_newlink_common.isra.0+0x65/0x130  \n    [<0000000087cd6d8d] ip6gre_newlink+0x72/0x120  \n    [<000000004df7c7cc] rtnl_newlink+0x471/0xa20  \n    [<0000000057ed632a] rtnetlink_rcv_msg+0x142/0x3f0  \n    [<0000000032e0d5b5] netlink_rcv_skb+0x50/0x100  \n    [<00000000908bca63] netlink_unicast+0x242/0x390  \n    [<00000000cdbe1c87] netlink_sendmsg+0x1de/0x420  \n    [<0000000011db153e] ____sys_sendmsg+0x2bd/0x320  \n    [<000000003b6d53eb] ___sys_sendmsg+0x9a/0xe0  \n    [<00000000cae27c62] __sys_sendmsg+0x7a/0xd0 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:56.000000Z"}, {"uuid": "ad0b5f99-8bbf-4a44-9dbb-f805b5a0f5bb", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50251", "type": "seen", "source": "https://t.me/cvedetector/10330", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50251 - Linux Kernel netfilter Off-By-One vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50251 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetfilter: nft_payload: sanitize offset and length before calling skb_checksum()  \n  \nIf access to offset + length is larger than the skbuff length, then  \nskb_checksum() triggers BUG_ON().  \n  \nskb_checksum() internally subtracts the length parameter while iterating  \nover skbuff, BUG_ON(len) at the end of it checks that the expected  \nlength to be included in the checksum calculation is fully consumed. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:55.000000Z"}, {"uuid": "712a589c-c5be-4db1-b79f-5eac2d0a4efe", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50250", "type": "seen", "source": "https://t.me/cvedetector/10333", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50250 - Linux Kernel Fsdax Data Integrity Corrupting Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50250 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nfsdax: dax_unshare_iter needs to copy entire blocks  \n  \nThe code that copies data from srcmap to iomap in dax_unshare_iter is  \nvery very broken, which bfoster's recent fsx changes have exposed.  \n  \nIf the pos and len passed to dax_file_unshare are not aligned to an  \nfsblock boundary, the iter pos and length in the _iter function will  \nreflect this unalignment.  \n  \ndax_iomap_direct_access always returns a pointer to the start of the  \nkmapped fsdax page, even if its pos argument is in the middle of that  \npage.  This is catastrophic for data integrity when iter->pos is not  \naligned to a page, because daddr/saddr do not point to the same byte in  \nthe file as iter->pos.  Hence we corrupt user data by copying it to the  \nwrong place.  \n  \nIf iter->pos + iomap_length() in the _iter function not aligned to a  \npage, then we fail to copy a full block, and only partially populate the  \ndestination block.  This is catastrophic for data confidentiality  \nbecause we expose stale pmem contents.  \n  \nFix both of these issues by aligning copy_pos/copy_len to a page  \nboundary (remember, this is fsdax so 1 fsblock == 1 base page) so that  \nwe always copy full blocks.  \n  \nWe're not done yet -- there's no call to invalidate_inode_pages2_range,  \nso programs that have the file range mmap'd will continue accessing the  \nold memory mapping after the file metadata updates have completed.  \n  \nBe careful with the return value -- if the unshare succeeds, we still  \nneed to return the number of bytes that the iomap iter thinks we're  \noperating on. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:18:33.000000Z"}, {"uuid": "5506c51b-2c89-49f7-93f1-7eb1810544f3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50254", "type": "seen", "source": "https://t.me/cvedetector/10320", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50254 - Linux Kernel bpf Memory Leak Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50254 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Free dynamically allocated bits in bpf_iter_bits_destroy()  \n  \nbpf_iter_bits_destroy() uses \"kit->nr_bits <=<00000000c452b4ab] kmemleak_alloc+0x4b/0x80  \n [<0000000004e09f80] __kmalloc_node_noprof+0x480/0x5c0  \n [<00000000597124d6] __alloc.isra.0+0x89/0xb0  \n [<000000004ebfffcd] alloc_bulk+0x2af/0x720  \n [<00000000d9c10145] prefill_mem_cache+0x7f/0xb0  \n [<00000000ff9738ff] bpf_mem_alloc_init+0x3e2/0x610  \n [<000000008b616eac] bpf_global_ma_init+0x19/0x30  \n [<00000000fc473efc] do_one_initcall+0xd3/0x3c0  \n [<00000000ec81498c] kernel_init_freeable+0x66a/0x940  \n [<00000000b119f72f] kernel_init+0x20/0x160  \n [<00000000f11ac9a7] ret_from_fork+0x3c/0x70  \n [<0000000004671da4] ret_from_fork_asm+0x1a/0x30  \n  \nThat is because nr_bits will be set as zero in bpf_iter_bits_next()  \nafter all bits have been iterated.  \n  \nFix the issue by setting kit->bit to kit->nr_bits instead of setting  \nkit->nr_bits to zero when the iteration completes in  \nbpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to  \ncheck whether the iteration is complete and still use \"nr_bits > 64\" to  \nindicate whether bits are dynamically allocated. The \"!nr_bits\" check is  \nnecessary because bpf_iter_bits_new() may fail before setting  \nkit->nr_bits, and this condition will stop the iteration early instead  \nof accessing the zeroed or freed kit->bits.  \n  \nConsidering the initial value of kit->bits is -1 and the type of  \nkit->nr_bits is unsigned int, change the type of kit->nr_bits to int.  \nThe potential overflow problem will be handled in the following patch. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:41.000000Z"}, {"uuid": "43b865ab-713e-4d0b-9909-fe34108b3573", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50259", "type": "seen", "source": "https://t.me/cvedetector/10318", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50259 - \"Linux Kernel Netdevsim Uninitialized String Buffer@store\"\", \n  \"Content\": \"CVE ID : CVE-2024-50259 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write()  \n  \nThis was found by a static analyzer.  \nWe should not forget the trailing zero after copy_from_user()  \nif we will further do some string operations, sscanf() in this  \ncase. Adding a trailing zero will ensure that the function  \nperforms properly. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:39.000000Z"}, {"uuid": "01da81de-c1bd-409a-b442-cbb42a9c6d9c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50258", "type": "seen", "source": "https://t.me/cvedetector/10317", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50258 - Cisco Linux Kernel Stack Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50258 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnet: fix crash when config small gso_max_size/gso_ipv4_max_size  \n  \nConfig a small gso_max_size/gso_ipv4_max_size will lead to an underflow  \nin sk_dst_gso_max_size(), which may trigger a BUG_ON crash,  \nbecause sk->sk_gso_max_size would be much bigger than device limits.  \nCall Trace:  \ntcp_write_xmit  \n    tso_segs = tcp_init_tso_segs(skb, mss_now);  \n        tcp_set_skb_tso_segs  \n            tcp_skb_pcount_set  \n                // skb->len = 524288, mss_now = 8  \n                // u16 tso_segs = 524288/8 = 65535 -> 0  \n                tso_segs = DIV_ROUND_UP(skb->len, mss_now)  \n    BUG_ON(!tso_segs)  \nAdd check for the minimum value of gso_max_size and gso_ipv4_max_size. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:36.000000Z"}, {"uuid": "490cef18-9371-4a5e-8f5f-527c12ae04d5", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50257", "type": "seen", "source": "https://t.me/cvedetector/10314", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50257 - Apache Netfilter netfilter Use-After-Free (UAF) Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50257 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nnetfilter: Fix use-after-free in get_info()  \n  \nip6table_nat module unload has refcnt warning for UAF. call trace is:  \n  \nWARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80  \nModules linked in: ip6table_nat(-)  \nCPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205  \nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),  \nBIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014  \nRIP: 0010:module_put+0x6f/0x80  \nCall Trace:  \n   \n get_info+0x128/0x180  \n do_ip6t_get_ctl+0x6a/0x430  \n nf_getsockopt+0x46/0x80  \n ipv6_getsockopt+0xb9/0x100  \n rawv6_getsockopt+0x42/0x190  \n do_sock_getsockopt+0xaa/0x180  \n __sys_getsockopt+0x70/0xc0  \n __x64_sys_getsockopt+0x20/0x30  \n do_syscall_64+0xa2/0x1a0  \n entry_SYSCALL_64_after_hwframe+0x77/0x7f  \n  \nConcurrent execution of module unload and get_info() trigered the warning.  \nThe root cause is as follows:  \n  \ncpu0          cpu1  \nmodule_exit  \n//mod->state = MODULE_STATE_GOING  \n  ip6table_nat_exit  \n    xt_unregister_template  \n kfree(t)  \n //removed from templ_list  \n          getinfo()  \n       t = xt_find_table_lock  \n      list_for_each_entry(tmpl, &xt_templates[af]...)  \n       if (strcmp(tmpl->name, name))  \n        continue;  //table not found  \n       try_module_get  \n      list_for_each_entry(t, &xt_net->tables[af]...)  \n       return t;  //not get refcnt  \n       module_put(t->me) //uaf  \n    unregister_pernet_subsys  \n    //remove table from xt_net list  \n  \nWhile xt_table module was going away and has been removed from  \nxt_templates list, we couldnt get refcnt of xt_table->me. Check  \nmodule in xt_net->tables list re-traversal to fix it. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:33.000000Z"}, {"uuid": "1814a322-151b-4593-a908-a6fb8afd39f3", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50255", "type": "seen", "source": "https://t.me/cvedetector/10313", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50255 - Apache Bluetooth null pointer dereference vulnerability in hci_read_supported_codecs.\", \n  \"Content\": \"CVE ID : CVE-2024-50255 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nBluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs  \n  \nFix __hci_cmd_sync_sk() to return not NULL for unknown opcodes.  \n  \n__hci_cmd_sync_sk() returns NULL if a command returns a status event.  \nHowever, it also returns NULL where an opcode doesn't exist in the  \nhci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0]  \nfor unknown opcodes.  \nThis leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as  \nthere is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes  \nstatus = skb->data[0].  \n  \nKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]  \nCPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10  \nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014  \nWorkqueue: hci7 hci_power_on  \nRIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138  \nCode: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0fb6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78  \nRSP: 0018:ffff888120bafac8 EFLAGS: 00010212  \nRAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040  \nRDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4  \nRBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054  \nR10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070  \nR13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000  \nFS:  0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000  \nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  \nCR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0  \nPKRU: 55555554  \nCall Trace:  \n   \n hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline]  \n hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline]  \n hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline]  \n hci_init_sync net/bluetooth/hci_sync.c:4742 [inline]  \n hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline]  \n hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994  \n hci_dev_do_open net/bluetooth/hci_core.c:483 [inline]  \n hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015  \n process_one_work kernel/workqueue.c:3267 [inline]  \n process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348  \n worker_thread+0x91f/0xe50 kernel/workqueue.c:3429  \n kthread+0x2cb/0x360 kernel/kthread.c:388  \n ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147  \n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:32.000000Z"}, {"uuid": "0763c49e-745b-449a-95d4-ad162b3a17d7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2024-50253", "type": "seen", "source": "https://t.me/cvedetector/10321", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-50253 - Linux Kernel BPF Stack Overflow Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-50253 \nPublished : Nov. 9, 2024, 11:15 a.m. | 40\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nbpf: Check the validity of nr_words in bpf_iter_bits_new()  \n  \nCheck the validity of nr_words in bpf_iter_bits_new(). Without this  \ncheck, when multiplication overflow occurs for nr_bits (e.g., when  \nnr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur  \ndue to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008).  \n  \nFix it by limiting the maximum value of nr_words to 511. The value is  \nderived from the current implementation of BPF memory allocator. To  \nensure compatibility if the BPF memory allocator's size limitation  \nchanges in the future, use the helper bpf_mem_alloc_check_size() to  \ncheck whether nr_bytes is too larger. And return -E2BIG instead of  \n-ENOMEM for oversized nr_bytes. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"09 Nov 2024\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2024-11-09T13:17:42.000000Z"}]}